Production management for a web application?
I finished developing the core of the web application I am working on. Since I was the only developer, I just developed locally (lamp stack) without using version control (silly perhaps, but anyway ..). Now that it is getting closer to production, I have a couple of other developers working with me, so I set up a repository for my code.
This is my question: I still want to be able to test all changes locally first before submitting to production. How do I manage this using a repository without having to maintain 2 versions of my code (which I have to sync manually)? First, the production code has a few differences here (e.g. database constants, etc.). I would like to be able to modify my code in my local repository, test it on my local Apache server, and then test the code directly in production (is this possible with eclipse)?
I am using eclipse and subversion (php code). I know I asked a lot of questions, but hopefully you get the idea of what I am trying to do ... and I assume it is quite common. Thank.
source to share
I would suggest a few things
- Use tags / branches in SVN. When the code is ready for production, label it with a unique name.
- Set up a staging area for integration testing. After the release is marked for staging, pull it out of your vcs and copy it to the staging area. It can be as simple as another directory tree or a second installation of your server.
- Place the constants in separate files that can be copied / merged into the staging and deployment environment directories.
- Test the phased version against dev to ensure everything works the same as it does in your dev environment. I would point out staging to production databases when I am confident that it is working and ready to go. Try it against prod as well.
- Once everything is working in the staging stage, update the production copy. I suggest you create a clean deployment directory and then copy the entire deployment to the production server after copying / merging the configuration settings.
This was my approach to working with perl / cgi many years ago, and it worked very well. SVN handles tags / forking much better, so it should be easier to deal with. We had very few production issues once we started creating files before pushing prod.
source to share
In addition to the great answers you've already received, I would like to emphasize that if there are differences between your dev and production code, you are adding risk. You should use the same, well-tested code in both places; any difference between the environments must be expressed in the configuration files. Any configuration files in the source control must be sample-only; your deploy script shouldn't call new config files for production.
This, combined with tagged releases and a staging environment that mimics production, should help you move your code smoothly into production.
source to share
It looks like you haven't created any branches or tags, and probably have a "torso" that isn't marked as such. Best practices will dictate that you have a trunk for the current stable code, the branches you are working against, and the tags that are actually used on the production site. There is a short description and diagram on Wikipedia .
Of course, this is just best practice. Your project sounds small enough that you can get away with splitting your code into a development directory and a production / directory in your code repository. Check out the code in the development directory, and once the change is fully tested, merge it into the production directory.
Whether you do it right or simply, it's important to do something to separate your development code from your production code. As you add more developers, it becomes more and more unlikely that the development code base is stable because people check code that has not been fully tested is not complete, regardless. Spending a little extra time managing two branches of code will save you a lot of headaches later.
source to share