Working towards a better deployment (Part 1)

Since we’re in the “slow time” for the business I work for (no one cares about their natural gas bill when it’s warm and the price is right) I’ve taken some of the flexible time I’ve found to work on a pet project of mine – the overall well-being of our development process.

Let me start off by mentioning what our current setup is:

  • We use CVS as our version control repository not so much by our choice now but by the choice of someone many years back. It’s worked well for what we’ve needed it for, but we’re going to be upgrading to Subversion here pretty quickly.
  • We have separate development, QA/testing and production environments so that each developer can work in their own space and have a QA to push it to so there’s no testing on the devs.
  • Code pushes are done with rsync directly from the QA environments out to production.

That’s pretty much it – a simple process that has worked pretty well for the six years I’ve been with my current employer. Unfortunately, times change and so do development standards. When I first started there were only two of us that worked on the code for both the internal and external websites. Now that team has grown to include at least six others. Needless to say, keeping things straight has become a bit more difficult.

So, back to my “free” time – I stepped back and took a look at our process. I tried to find out what could be improved in it and what was completely missing. What we have is a good base to start from, but there were a lot of other things to consider like quality of the code being pushed, checking to be sure there’s no syntax issues, creating a standardized way for the code to flow and what tools might be best for the job.

I’ve told you what we currently have, so let me tell you where my goal is – I want a system that allows the developers to work on both the main trunk and any branches (for projects and the like) of code quickly and easily and one that, once it’s been committed and tested, is out of their hands (right now, we have a system in place that lets developers push bits of code to production – a definite bad idea). Developers would have the option to change database connection information as they see fit but still have defaults for all to use. We have multiple customer databases and the location of the test databases isn’t always the same.

Once the developer is satisfied with the code and feels it bug free (enough), they can commit it and send it on its way for testing. That’s where their job ends – from here the administrator’s role kicks in. They’re the one that has the cvs-foo (or svn-foo) to pull the code out of the branch and push it into the currently checked out code in the QA environment. This code can then be reviewed and tested by whatever group needs to without interfering with any updates the developer might be working on. Once testing is complete and everything’s good to go, that code can be commited back to the trunk, pushed to a staging area and synced out to the production site. I don’t believe that QA and the base for deployment (staging) should be the same – it’s just too confusing when you could have a merging of codesets from branches all over the place. If you’re going to sync, sync from an up-to-date version of the code.

Which leads me to my next point….the build process. (the next part of this series will cover it)



  1. Thanks, at work we’re currently looking at improving a similair setup (also CVS, also the seperate environments, but no QA dept) so it’s interesting to read others’ thoughts.
    About the development environments, do people develop on their own machines, directly or in a virtualised environment, or do they develop on a server?


  2. @Maarten: We go with a centralized setup – a single development machine (currently running both PHP4 and PHP5 web servers) with a samba drive open for those who would like to map it to their desktop machine. With our current (Oracle) database setup, it’s just easier to keep it all in one place. Virtual hosts are set up for each development and QA environment with their own DNS records.


  3. enygma: ok. Makes sense. We have an environment per developer on their own machine in VMWare running CentOS as its guest.
    I guess virtual hosts would work as well for us, might consider doing that on some point..thanks for all the food for thought


  4. We are actually trying to do this same thing. However, we all have development boxes/personal machines. they are managed by a single person for updates, configs, etc. No changes to Apache or PHP settings are changed by the dev. When prod, and test get changed our development boxes get changed. this way all our env. are in sync.


  5. We have just put git in place replacing svn and we are loving it! We have around 20 people doing development and work in teams of 2 to 5. We work locally on our MacBooks running Apache, PHP, Mysql, Memcache, and sphinx.

    We all have our own development environments and pull from one another to share code. There is no central development server. Once we are completed and have merged all of our code with our master branch they will do a push to the test server’s bare repository. At that point QA will pull that branch into to them main repository and do testing. If the testing fails the development team is notified the branch is deleted, the development team corrects the issues and goes through the same cycle. If the code passes it is merged into the master branch on test and the pushed to the production stage server.

    All of this said to say git rocks! There was a bit of a learning curve and some pain for about 2 weeks, but once we got through it we are lovin it.


  6. Ryan: not terribly related, but what are you using Sphinx too? We’re using it too, and it’s nice to see others here that do


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s