Development and Production Workflow

Question

I've seen pieces of this problem solved around the net, yet I'm still confused, so I thought I'd ask the smart folks at Stack Overflow about this.

We're a small startup and at the moment our workflow from development -> production involves ftp-ing in and just uploading the dev code.

The dev code IS under subversion control - although we haven't leveraged trunks/tags/branches since I don't have a good idea of how to best use this structure. I feel that there should be a seamless integration with the live site that doesn't require me copy-pasting folders and files.

Here's some details: - developing on CakePHP + MySQL - hosted at Media Temple (gs) - developers use both Mac OS (Coda) and Windows (Dreamweaver)

So my ask is: how do you setup a proper scalable workflow?

Answer 1

Your work-flow seems proper for a small organization which doesn't have QA. I would advice you to invest some resources into

1) Build production releases and have a version scheme so that you can track your production releases accurately. Tag every release so that you can track it.

2) Build an installer. Don't resort to manually copying folders because you could make a mistake. An installer also makes it easy to track when something goes wrong in production.

3) Do some QA on the production before deploying. Even a little QA goes a long way. Developers are not good testers since they might be biased towards the "features" of the program.

4) Don't bother with branches just yet until you actually have to use it. Only then will it become clear which structure you need. The subversion red-book has some ideas on how to structure your branches.

Answer 2

One way I've done this in the past is have the production code actually be a live subversion client, pulling out the 'production' branch.

So you do your work as usual on the development branch, and whenever you're ready, you cut a copy to the production branch. Sync the production servers, and you are live. If something goes wrong, you can always resync to the older version.

For extra points, you can add a staging branch, so you can catch all the things that changed that aren't in your code. Then you add them to a deployment script that will adjust the production systems as needed.

Answer 3

I think the key thing to consider is to include as much process and workflow that will improve the quality of the code and reduce your effort to deploy. The key thing is to start creating some of these things when your code base has settled down. In the early days when everything is changing rapidly you will be spending more time updating scripts than you will be saving with the scripts.

I would recommend the following things:

1. Create an automated build script. There are many different technologies and scripting languages that can be used (I prefer Ant) to extract your files from source control, automatically increment version numbers, add tags and create the deploy packages. This may take a large amount of effort to setup and unravel the tasks that the developers are currently doing but this will pay off enormously in the long-run. It should free your developers from the repetitive task of building and allow them to focus on solving your technical issues. As you are aware, developers get bored doing the same thing over and over and when you get bored you start making mistakes.

2. Automated install. This is a marginal advantage while things are still in a rapid development stage but in the long term it will free up resources that could be better spent elsewhere. At the very least, you should have an installation package and installation steps for deploying your code.

3. Staging Environment. You could argue that this isn't required until your user base is large enough that they start sqawking when the production system goes away when you deploy code. It is important to have a system that allows you to test your changes without discomforting your user base. But of course, this also requires some QA effort. You definitely need some testing before deployment. Developers always assume they are right and have never missed anything but they should never be believed. There is always a different code path or some new permutation of clicks that they never thought of.

4. Backup your SVN. This should go without saying but I worked for a company where our source repository wasn't backed up for over two years. You can backup by do an svndump and then copying the resulting file to another location. You can also just backup the folders where your repository exists and then restore if problems occur.