CodeIgniter: Development and Production Environment

Question

I am currently in the process of learning the CodeIgniter PHP framework. At the current moment, I am looking to have a DEV environment and a PRODUCTION environment. Coming from a purely C and JAVA background, I am used to having everything locally (with version control), but since I will have the PRODUCTION side on a website, I was wondering a couple of different things:

1. Is it better to keep the DEV environment locally?
2. What would be a good (and easy) way when making changes on the DEV side to get them up to the PRODUCTION side (assuming the DEV env is local)?
3. Is it possible (and if so, how?) to setup CodeIgniter to have a DEV & PROD environment in the same codespace (say on the server but with different databases tables)?
4. When using Version Control on an application I would create in the Framework, is it recommended to only have the files I create for my application, or add the whole Framework (to keep the code consistent with version of the Framework)?

I appreciate any thoughts or suggestions you have in advance.

Thanks!

Answer 1

I don't use CodeIgniter, so I may not be able to answer all your questions ; but, still, here a few pointers :

• Development environment : I like when each developper has it's own environment ; and it's generally easier / faster when it's on his machine
  • still, if your development machines are running windows, and you production server will be running Linux, it could bring some problems (there are a few differences between those two, like case-sensitivity in files names)
  • in this case, provided you have a powerful enough computer, using VMWare or VirtualBox to run a minimalist Virtual Machine (with Linux+Apache+PHP+MySQL on it ; the code source is on it too, exported via a samba share) might be a good solution -- that's what I've been doing few more than half a year, and it works pretty well
• Pushing changes from dev to prod :
  • one solution is to log on the production server and do an "svn update" ; but I don't really like that (if some files have been modified directly on the production server -- yes, this sometimes happens) , you may encounter conflicts and the like ; and that's definitly not fun at all, as it may break the site ^^
  • one solutioon I like more (takes more time to deploy, but if you deploy only, say, once a week, it's quite OK -- and definitly more secure) is to use "svn export" on one of the dev machines, create a tar/zip/whatever archive, and upload it to the prod server. Then, you extract it to a NEW directory ; and when it's done, you change a symbolic link to point your root directory to that new directory. Nice thing is : you keep the old sources on the production server, and if there's a catastrophic problem with what you deployed, you just have one symbolic link to change back to revert to the previous version -- and that can sometime save the day ^^
  • oh, and, as a sidenote : you should write a script to do that automatically for you : it will avoid messing with ine step one day, when doing it manually (and will help for the day when the guy that always does that is in holidays ^^ )
• About using one instance of the sources for both environments : even if you plan on doing this only for the framework, I wouldn't recommend it :
  • it means having dev and prod on the same machine, which is bad : what if some still in development script becomes mad and does bad things ? What if one developpers types some kinf of "rm -Rf" in the wrong directory ?
  • you thought about different databases tables (I'd rather go with different databases ; with different users, to avoid anyone doing any bad request on the wrong database !) , but that's not the only thing : what about temporary files ? cache, for instance ?
  • I'd really prefer having to fully separated instances ; even if it means have the sources / the framework twice on the machine -- and I'd really really recommend having two different machines !
• About having the framework on SVN :
  • The more things you have on SVN, the easiest it is to get a new development environment set up : ideally, just one "svn checkout", and there's a new environment ready for the new developper who just joined your team ; coupled with a Virtal Machine you can give him (copied from another's machine) , you can have developpers ready to work on your project in a couple of dozen minutes -- which is nice ;-)
  • Still, having the Framework in SVN is a PITA to update it : you have to delete it, replace it, re-commit it, ...
  • Using svn:externals (if you can -- depends on your setup / your framework) , pointing to the framework's SVN server itself, might be a good thing to always be up to date (don't necessarily point to HEAD ; using a tag or a branch might be good enough for you).

Hope these few notes help...
Have fun !

Answer 2

1) I agree with Pascal MARTIN - its best for everyone to have their own local dev environment; that way they can play without stepping on each others toes. It may mean, then, that you want to have some type of test or staging environment where team members (and project stakeholders) can see the integrated, in-progress code.

2, 3) More generally, it sounds like you're asking how to automate/deploy to one or more environments. There are several commercial and open source options for doing this. We've recently started to use Capistrano ( http://www.capify.org ) and have been really happy with the results. It's a ruby tool, and written using ruby-on-rails-isms. If you're not familiar with those (I wasn't) it takes a little bit of reading and Googling to figure it out. However, at its heart is simply a means to define and run scripts on remote servers. Those scripts can be used on any type of deployment (we use PHP, for example). Two great things about Capistrano that address your question:

• It knows about version control; whether you use SVN, git, or others, it knows (several ways) of pulling down the latest code from the repository and doing whatever is needed to update remote server(s).
• It does transactions, so if something goes wrong with the build/deploy process, it can automatically rollback to a previous version

4) That's probably the simplist model; simply download a codeigniter installation and write your code in the applications/ directory. This could be hassle someday if you want to upgrade CI to take advantage of some new hot feature. You should be able to get around this by defining an svn:external link to the codeigniter, so that when they update, it gets rolled into your code as well. See: http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html for more info...