First of all, I strongly recommend you read Continuous Delivery (Jez Humble, David Farley), he got a ton of information about it. Here is a sample chapter .
As I read this, I started implementing an assembly pipeline, where each svn commit goes through every stage in the pipeline, when the environment gradually becomes more like a production process as the assembly advances. For this we use Jenkins.
- Stage of fixation - dev sanity - compile, unit test and some indicators. This initial step also creates the binaries needed for the rest of the pipeline
- The integration stage is the same files as the previous stage (not a new check) and performs tests of db integration into memory
- Automated Acceptance Testing Phase - takes binary files from the commit phase and deploy to the server where we run selenium tests
- QA stage - this is deployed by qa, which simply presses a button to pull whatever they want, again it simply deploys the binaries from the commit phase to the QA server.
- UAT is the same as QA, but a more productive environment where we also run performance tests
- Products - takes binary files from the commit phase and deploys for production.
Each of these stages acts as a “quality shutter” - the assembly is not allowed to move on until it passes a certain threshold value - testing errors,% s metric, etc. Some stages of the flow are automatically automatically started manually. Any configuration changes necessary for each environment are performed by unpacking the source binary files, changing the settings, packing them again - ideally, I would like to separate the configuration from the application binaries, but have not yet found a way to do this.
The automatic acceptance test script simply updates the existing application on the server - the qa stage performs a complete stop, uninstall, installation and start. Each of them runs a different script - a combination of ant and python.
Here's what the pipeline looks like in jenkins with the assembly pipeline plugin.
[edit]
In fact, you do not need to complete each stage of this at a time, it’s easy enough to have place holders for each stage, which simply flow to the next, without actually doing anything. If you map your current process, you can automate parts of it and gradually move on to the pipeline.
The most successful commit step is what you would do when setting up a regular CI server, create a project, connect it to version control, compile, run tests, run some statistics from ant / maven. It takes a little over 5 minutes.
The statistics task takes too much time (> 15 minutes), so I run a subset on a commit and do a night run, which does all the work of Findbugs, PMD, Checkstyle and Cobertura. I would rather run all this while committing, but this would require some more equipment and work on setting up some kind of assembly grid.
Selenium tests are not currently in a separate project, but they are packaged as a separate jar, and it becomes available for the automated acceptance testing stage through the jenkins 'copy artifact' plugin - ant / python scripts pack the WAR file and are deployed in the container, then ant is unpacked and runs the Selenium tests (via junit). At the moment there is only a bunch of "smoke tests" and they are not dependent on the main WAR, although I can see this change. I don’t like the idea of having separate projects for code and tests - build scripts just pack the classes and libraries needed for each module from the main project - for your situation (and soon ours) you may have to do something else - how about starting a virtual machine or two with the necessary configuration and its deployment. (a lot of information in the continuous delivery book about this)
It's good that Jenkins supports this a lot through plugins - we switched from Atlassian Bamboo, because most of what we wanted was not available, and the existing plugins either did not work or were not compatible with the Bamboo version. I have not used Team City for a while, so I have no idea if this supports the idea of a “pipeline” [aparently not] . The Build Pipeline plugin is quite new and has a few rough edges, but is under active development - I think that it is possible to do this with the help of advanced Jenkins compilations and assembly of trial stones, but they did not try to do it. If you have enough resources (money!), You can look at Go