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)

Category: cvs, Deployment, PHP 11 comments »

11 Responses to “Working towards a better deployment (Part 1)”

  1. Maarten

    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. enygma

    @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. blog.phpdeveloper.org » Working towards a better deployment (Part 2)

    [...] the previous part of this series, I looked at some of the current methods we use for code development and deployment [...]

  4. blog.phpdeveloper.org » Working towards a better deployment (Part 3)

    [...] on the to third part of my little series (part one, part two) on making a shiny new deployment system for our sites. What’s that? Yep, I said [...]

  5. Maarten

    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

  6. blog.phpdeveloper.org » Working towards a better deployment (Part 4)

    [...] applications to focus on the actual deployment technologies. I’ve already talked some about version control, build tools and unit testing in the previous parts of the series and this new information should [...]

  7. Shaun Farrell

    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.

  8. Ryan

    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.

  9. Maarten

    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

  10. Working towards a better deployment (Part 4) | rapid-DEV.net

    [...] applications to focus on the actual deployment technologies. I’ve already talked some about version control, build tools and unit testing in the previous parts of the series and this new information should [...]

  11. PHP/Web Developers I follow and so should you | Jakefolio.com - Jake Smith PHP Web Developer

    [...] of “PHP Frameworks”.  If you haven’t already started reading his latest series, Working Towards Better Deployment, then you’re missing out my [...]


Leave a Reply



Back to top