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:
Has anyone got a system that does all of these steps?
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).
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.
@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?
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?
@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
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. :-)
@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.
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:
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.
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.
@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.
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).
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.