php - SVN Website Development and Deployment Solution

Question

Here is the situation: we have multiple developers with varying degrees of commandline experience and we are putting together a deployment solution for our websites. The production environment is 2 SUSE Linux boxes. The development environment is a SUSE Linux box as well. Each developer has/will have a copy of the SVN tree in their home directory for development and testing.

The goal is to have a release system that is easy to use and easy to revert that will work with multiple production servers. It would be a bonus if a non-web developer (still a coder just not in the web world) could easily revert any of the websites as well. In an optimal world, release would be as simple as running a single command on the website that you want to release. This command would update the production servers and leave a revert path in it's wake.

Our current deployment solution is a bit clunky, quite difficult to revert and slow as dirt. We currently check in all files using SVN. Then a script is run that essentially creates a tag in SVN. A second script is then run that goes onto each of the 2 production servers and runs an 'svn up'.

Any suggestions?

Answer 1

I am a .net guy and therefore work with things in the windows world...having said that though the technologies that I work with on a daily basis to manage build processes came from your world! (Linux/java technologies are in parenthesis but I included their equivalent for the windows readers too) I use CruiseControl.NET (CruiseControl), VisualSVN (SVN), Tortoise, and NAnt (Ant) to take care of all of my build needs.

All of my builds are generally automatically pushed and tagged at the time of check in. This is done with CruiseControl as it monitors my source control (SVN or SubVersion). When CruiseControl (CC) sees that new code has been checked in it will execute a CC project which in turn calls out to the Ant script on the build server.

The Ant script does several things for me in a common build. It will check out a copy of the latest code and bring it down to the build server. It will then build the code to make sure that things at least compile. It then sets a clean copy of my database and executes any sql scripts to build that baseline db up to the current version. I then run all of my unit test projects. I then run integration tests which among other things test my repository layer to make sure that the code is still aligned with my back end (I generally use an ORM in my projects so they are rarely out of sync...but is a good step in the process). Once all of the tests have passed (or failed) I roll back the database to a clean state and execute scripts to bring it up to the current version (this is important as it provides the team with a clean database to develop against at the click of a button). If the build was successful then I will deploy the code out to the development server (I also have one click deployment to my staging servers and production servers). If you like to tag your code base with each check in you can do that here too.

Once all of this is complete I like to run some analysis on my code using NDepend, NDoc, and NCover. NDepend is a code analysis tool to make sure that things are architecturally correct, that naming standards are as they should be, and a WHOLE LOT MORE. NDoc extracts all of the code comments and creates MSDN style documentation for my code. NCover tells me if I have proper coverage with unit tests for my code.

I then have a custom Ant task that I wrote that parses all of my code for the various //TODO and //CodeDebt tags to generate yet another report to tell me (usually at the end of the sprint) just how much crap is building up in my code base. This can then be factored into the next sprint.

All of these reports are either included in the build email that goes out or is linked too appropriately.

Keep in mind that all of the above happens for each check in...and without anyone having to click even one button! This is true continuous integration and should be the goal of every build master.

CruiseControl has a web based console that will also allow non web dev guys (anyone really) to go in and execute this push without having to check in code...called forcing a build.

Given this framework you can easily also roll back a push as long as everything is under version control. You would need another Ant script that would perform the same process but with an additional first task in that it would have to get the last version of code rather than the most recent to perform the build process on. All of the Ant tasks can be reused with a different execution target.