One of the things we’re continually looking to improve on is our ‘cycle time’ – that is the time between coming up with an idea to having it online where it’s adding value to both users and the business.

The real challenge when trying to deliver products in an ever-decreasing timeframe is how to maintain the quality of the product and to ensure that we haven’t broken any of the existing functionality; particularly if this was written by someone else, some time ago.

Historically, on some of our larger projects, our test-cycles (the time it takes to run an end-to-end test of the application) have taken up to a day. In itself this is a significant barrier to delivering new functionality in a time and cost-effective way.

Continuous Delivery is both the title of a book and the term applied to a software delivery pattern that provides a number of tenets for mitigating risk when delivering products in tight-turnaround situations. Some of the things we’ve implemented so far include Behaviour Driven Development, automated testing and finally an automated build, test and deployment pipeline.

Behaviour Driven Development (BDD)
BDD allows us to define the required functionality in human readable and concise terms (typically three lines per requirement). These behaviours both provide a core part of the requirements documentation and drive our automated user acceptance tests.

Automated Testing
Every change that is made to the product launches a series of automated tests. Typically the first tests to run are low-level tests that check that the code is working as the developer expected.

Assuming these complete successfully, the behavioural tests are run which check that the product is delivering the required functionality. These tests are often run using a real web browser, to mimic as closely as possible how a user will use the product.

With automated testing, developers can expect to get feedback in less than ten minutes. This short cycle time allows issues to be identified and fixed almost as soon as they arise and serves to reduce the amount of time spent for human testers to run repeatable tests.

Automated Build, Test and Deployment Pipeline
To get a product in to production (in to the hands of end users), there are a number of steps that a product goes through:

•    Build: This step grabs the latest work that everyone who is working on the project has committed (marked as complete and shared with the team) and then compiles this in to a single product.
•    Test: This step typically invokes a number of tests in sequence, include basic code-level (unit) tests, user acceptance (behaviour) tests and if necessary performance tests and some basic cross-browser automated testing.
•    Deploy to QA environment?: Assuming the basic tests pass, the latest build of the product will be automatically deployed to the QA environment.
•    Deploy to staging environment?: The staging environment is typically used as the final point before the product is pushed in to production. Any relevant final manual testing and sign-off processes typically happen on staging.
•    Deploy to production environment: Once on production the product is now in the hands of the end users.

We’ve completely automated the process through the build, test and deploy to QA environment steps. Assuming the previous step completes successfully, the next step in the pipeline is invoked and the product gets closer to the hands of the users.

We’ve opted to keep the final two steps in the pipeline, pushing the product to the staging and finally the production environment as a manual step (or manual in the sense that someone has to at least press a button). Crucially, these steps use the same process that deployed the product on to the QA environment – this means that by the time we push to production, we’ve already tested not only the product, but we’ve also tested the way in which we move the product on to a new environment twice. This gives us a high degree of confidence when we press the final ‘go live’ button that things are going to work as expected.

We still opt to have technical staff responsible for making the final deployment to the production environment, however, our ultimate goal has to be to have a ‘go live’ button that anyone in the business is able to press.

Links:
Continuous Delivery (http://continuousdelivery.com/)
Behaviour Driven Development (http://en.wikipedia.org/wiki/Behavior_Driven_Development)
Selenium (http://seleniumhq.org/)
SauceLabs (https://saucelabs.com/)
Jenkins (http://jenkins-ci.org/)
Capistrano (https://github.com/capistrano/capistrano/wiki)
Webistrano (https://github.com/peritor/webistrano)