Web applications: Development to Production

Question

Here is my company's current process for moving changes from our development server to our production server:

1. Files that need updated are brought down from production, to ensure no changes were made in production only (no it shouldn't happen; but yes, it does happen). Old development files are given a ~ prefix as a sort of "backup".
2. Developer makes necessary changes.
3. Updated files in development are copied from that server and pasted into the corresponding place on the production server. Old production files are given a ~ prefix as a sort of "backup".

I know this is a horrible way of doing things, but what's the best way to do this? My initial idea was to move all of our code into subversion. Then, when something needs updated, make changes in development, commit to the repository, and then update the production server from the repository.

Anyone have any alternatives / alterations / constructive criticism? Our development team only has 6 people and our code base is a sprinkling of ASP (very old, horrible legacy), PHP (somewhat newer), and Java EE (newest code; all applications built as separate WARs).

Thanks in advance

edit: For development of our Java EE apps, each developer has Glassfish v2 running on his machine. For PHP/ASP, we have a central dev server. For production, we have a server for PHP/ASP (IIS), and another one for Java (Glassfish v2).

Answer 1

Capistrano is a great tool, but I find it to be overkill for non-Rails projects. This is a good guide for deploying PHP projects to multiple environments from a repository: http://themetricsystem.rjmetrics.com/2010/02/01/simple-deploy-script-for-php-applications/

Answer 2

As has been said, source control is a definite. It is the tool around which all coding and deployment should happen.

That being said, you might also want to employ a deployment tool like Capistrano or a build tool like Phing.

I use Capistrano to deploy our PHP applicaiton, and using a single terminal command it will:

1. Check out a copy of the project from source control
2. Put in inside versioned deployment folder
3. Run custom tasks - like writing symlinks to the public folder, running db tasks, switch environment variable from staging to production, etc.
4. Create a symlink between my app's public folder and the server doc root

If anything goes wrong, it will automatically roll back to the last good deployment. It's such a useful tool. Can't recommend it enough.

EDIT: Just realized this wasn't a PHP-only question. Depending on your platform, deployment tools will vary. Capistrano works great for Rails or PHP. Phing is a PHP version of Apache Ant. You might want to inquire as to the best tool for your chosen platform.

Answer 3

As you said, subversion would probably help, in your case : using some version control system is great, and subversion works fine -- and you probably don't need any de-centralized system (like git/mercurial/...).

The main advantages would be :

• easier to share the modifications made by each developper in your team
• one central location that "is the official version of the sources"
• probably easier deployment.

Though, I would not just use an svn checkout on my production server : OK, it can work fine in some cases, but, especially if you are sometimes modifying files directly on the production server (which you definitly shouldn't do !), you'll end up with troubles (like conflicts) on the production server one day or another...

Yes, you can use svn merge in dry-run, but it's not always enough... And there is no dry-run for svn update -- and a conflict in a PHP file generally means a parse error ; and that's bad when it happens on the production server ^^

Instead, I would :

• work normally, committing to SVN when it's OK to do so
• once in a while (the day before the deployment to production, for instance), do an svn export and deploy the extracted application to a staging server
  • which means you can test on an environment that is closer to the production than your development platform
  • and also means that nothing should go to production directly, without having been tested on the staging environment !
• if everything is OK on the staging server, then deploy the same package to the production server.

Oh, and, btw, about the deployment process, you might be interested by the answer I give on this question some time ago : Updating a web app without any downtime

As a sidenote : starting working with this kind of process is not always easy, so :

• Think as much as you can before starting ; posting on SO is a good start, but don't forget to discuss with your colleagues, who will use that system !
• Take your time : there is probably no rush, and a couple of days of thinking are always useful ;-)
  • i.e. think about the situations you can encounter, and your use-cases, to ensure that the processes you'll put into place will work for you.

Answer 4

I'd say you're on the right line of thinking. Getting source control, subversion or otherwise, is of vital importance. Then use some sort of continuous integration like CruiseControl to manage either direct deployments or creation of deployment packages. And do absolutely everything you can to make sure no changes take place in production, it really throws a wrench into the whole process.

Answer 5

Yep....definately need some kind of source control. Personally I like SVN and feel it's pretty easy to setup.

Before you jump in the deep end though I'd think through how your deployment strategy should work. How do you want to handle concurrent development? Do you want/need a QA or user testing environment that you deploy to? Sit down with the rest of your group and come up with a list of use cases and such to make sure that you're on the same page, your strategy fits, and that you're all onboard with the solution.

Answer 6

You are right, using source code management (subversion, git, mercurial, etc) will make your life much easier.

Here are the basic steps you'll need to take when making changes to the production environment:

1. Developer makes changes in a branch from the main trunk of the project
2. When all changes are made and tests pass, merge the changes back into the trunk
3. Make a tag of the trunk
4. Export that tag into your production environment. If something goes wrong, you can always revert back to a previously deployed tag.