views:

1092

answers:

12

And what is your system of choice?

Off the top of my head I would say that for a real one step web 'build' the following steps would have take place:

  1. Take a source snapshot
  2. Change any config files for release
  3. Compress CSS and JS
  4. Run Tests
  5. Take a database snapshot [without test data]
  6. Move the source to the server
  7. Import a clean, current version of the database into the server
  8. Automatically confirm the 'build' was successful

Has anyone got a system that does all of these steps?

+2  A: 

I know ant build scripts are rather ugly, but you can do it all in ant. Basically, anything you can do in Java you can do in ant (since you can build custom tasks written in Java, which is pretty much anything programmable).

At my company, I set up cruise control to do essentially that, and cruise control is then set to email whoever checked in broken code if the build fails. We don't have all those exact steps in our build, but I have thought of using some kind of JS compressor in the build.

I would say you might want to not deal with moving the stuff to the server, but rather run the build with some kind of deployment target on the actual server. Also, consider adding in an "execute all tests" to that list (or execute some portion of all tests).

Mike Stone
+1  A: 

I know ant build scripts are rather ugly, but you can do it all in ant. Basically, anything you can do in Java you can do in ant (since you can build custom tasks written in Java, which is pretty much anything programmable).

The same thing goes for nAnt/.Net - I've done plenty of one-step web builds like that.

Greg Hurlman
A: 

@Mike said:
I would say you might want to not deal with moving the stuff to the server, but rather run the build with some kind of deployment target on the actual server

Do you use a build process to deploy your website releases, or are they built and then manually deployed? I would say that any manual deployment, although possibly unavoidable, would be a weak spot in the process. The whole reason to automate the build is to eliminate the user error, right?

Peter Coulton
A: 

You may want to add generating a release number and tagging source control with it. I have done that using CVS and Ant before - don't know how easy it is to do with other systems.

I don't get what you are doing with the database - where/what are you importing it into in step 7?

Darren Greaves
A: 

@boncey said:
I don't get what you are doing with the database - where/what are you importing it into in step 7?

Importing a clean, current version of the database onto the server

Peter Coulton
A: 

Importing a clean, current version of the database onto the server

Yes, but which server? Do you mean the production server? If so, what about the data your users may have entered into it? You do have users right? :-)

In my experience the final step (updating a production site) would not usually form part of an automated build. Quite often the developer would not even have a login to the production server and would hand over code and database update scripts (ones that don't wipe existing data) to a systems team and let them do the work.

So, in answer to your original question: everything but the last bit. :-)

Darren Greaves
A: 

@boncey
hand over code and database update scripts (ones that don't wipe existing data) to a systems team and let them do the work.

This is part of the reason for starting the question, the database is the most awkward part of the process. I liked the way Symfony (inspired by RoR?) uses what seems like a command pattern to allow multi-level undo/redos for all database modifications. It also means that the database schema is automatically in source control.

@boncey
...which server? Do you mean the production server? If so, what about the data your users may have entered into it?

I meant the production server, the staging server, or the development server. The build process should automate as much as possible, thereby removing the possibility of manually screwing something up.

Peter Coulton
+11  A: 

Yes, in Ruby land we have Capistrano, which has "recipes" for executing shell scripts on your servers.

A typical recipe for deployment could to the following:

  • check out the latest version of the source code on your production server
  • have the web server direct all requests to a "upgrade in process" page
  • take the app server offline
  • point the current version to the latest version that you just checked out
  • update the database
  • restart the app server
  • "ping" the app server to make sure the cache is primed
  • point the web server at the app server

If anything goes wrong, it knows how to rollback to the previous version.

It's aimed at Ruby developers, but you could use it for any kind of Unix based deployment.

Also, whenever I check in source code to the server, the server automatically runs my tests, and sends me an email if any of them fail.

The Ruby/Rails community is fanatical about automating things. E.g. there are also recipes for turning a clean Ubuntu install into a Rails server with Apache, Mysql, source control, etc.

Michiel de Mare
+2  A: 

We recently started using Visual Build Pro on a central server in the office. You maintain the script on the build box and term serve in to publish a build.

The steps we have the script do so far are: - clear local file folder - download everything from source control - build project using MSBuild - FTP to server (either test, or live) - send succees email to relevant people.

The time and headaches this has saved are enumerable. Making the above script took less than 20 minutes and another 15 or so to test.

You can have Visual Build Pro call either Sql Compare or generated scripts (see Database Publishing Wizard) to push your DB.

Rob Allen
A: 

@Peter

Do you use a build process to deploy your website releases, or are they built and then manually deployed? I would say that any manual deployment, although possibly unavoidable, would be a weak spot in the process. The whole reason to automate the build is to eliminate the user error, right?

I completely agree, though the current purpose of our cruise control setup is to ensure that any new checkins did not break the build (which includes Java compilation errors, JSP compilation errors, and test failures).

Cruise control can be set up to capture build artifacts, such as test results and build binaries, but we currently only keep the test results. I haven't yet had to do a deploy myself (I'm still fairly new to this company), but I'm pretty sure the same ant build script is used to deploy, but with specific targets to do the deploy.

I have considered keeping the binaries as a separate artifact, which might make deploying a particular build for testing or production use easier... but it may end up that these binaries just sit on a server and are never actually put to use.

You are absolutely correct that these build scripts should remove any potential for user error, otherwise they aren't being used to their fullest potential.

Mike Stone
A: 

I would recommend to try TeamCity (commercial CI that is free for small teams). I rely on NAnt (for builds), NUnit (for unit tests), NCover (for coverage) and Doxygen (for source code documentation).

David Pokluda
A: 

Finalbuilder does this and does it well.

It's a standard windows app that you can program with any kind of instruction or job (so many are built in). It knows how to talk to basically anything.

And once you've built it, you can run its webserver which allows you to start the build from anywhere and see the results.

Michael Pryor