Continuous Delivery helps a large organization like a Police Force become as lean, agile and innovative as a start-up.
Continuous Delivery is a methodology supporting software development that is adaptable, and guided by user feedback, changes to business strategy or technological advances.
Agile
There are many benefits to agile methodologies, like scrum which we used to successfully deliver and continue to improve the Avon and Somerset Constabulary website. Agile is about responding to needs and changes quickly, meaning that a website can adapt and change fast.
Scrum gives us a project methodology that enables the ‘wants’ around software functionality to be prioritized. The agile team then works out ‘how’ to deliver these wants.
Automation
To really reap the benefits of an agile approach the tools used by the team need to support the fast change process agile promotes.
This comes down to freeing developers’ time and allowing them to develop. The rest of the testing and release pipeline can be automated.
Benefits of Automation
Automation gives can give:
- Repeatability: A process can easily be repeated exactly the same way each time
- Reliability: Closely related to repeatability, knowing a process won’t fail become of human error
- Time savings: Frees up people to do more valuable work
A continuous delivery pipeline uses automation to make the journey from the developer team having created a feature or fixed a bug through to testing and release easy, fast and repeatable.
Because the process from writing code and releasing is so easy, it enables the team to release more frequently. It’s not uncommon for teams that implement a continuous delivery pipeline to go from monthly releases to multiple daily releases.
This supports the agile process of getting feedback from users quickly about a released feature, which is then used to steer future decisions by the business.
We primarily develop on the Microsoft stack and our continuous delivery pipeline is made up of the following components.
Source control: Git
An essential component for any developer, whether you work in a team or by yourself. It allows code to be added, modified or removed with the confidence to rollback or retrieve previous changes.
We moved from Subversion to Git to take advantage of the various benefits modern distributed version control systems have.
All our developers write locally Visual Studio making use of nCrunch to enable our code to be written using TDD. Code is then pushed into a central repository.
Build server: TeamCity
Every time code is checked into Git our build server detects this and automatically compiles the code and runs all of the tests. If the code doesn’t build or any test breaks the teams top priority is to the fix the fault.
Build servers are also called continuous integration servers, because that’s exactly what they do. They continuously integration the code written by multiple developers and ensure that it works.
Having written unit, integration and UI tests means that we can be confident that any changes to the code base haven’t stopped anything from working as intended.
We use Sauce Labs to run our Selenium UI tests remotely in multiple browser and operation system configurations. Our definition of done lists which browsers we support, so it’s important that every change is regression tested in all these browsers.
Once TeamCity has successfully compiled the code and run all the tests, it then creates a NuGet package which contains the compiled and tested code.
Deployment: Octopus Deploy
The final step is to deploy the code to the web and database servers is will run on. It’s possible to use TeamCity to do this, but a better approach is to use a dedicated piece of software.
Octopus Deploy is called by TeamCity whenever a success build has taken place. Octopus then uses the NuGet package which has been created and turns it into a release, which can be deployed to different environments.
In this case the automatic deployment is made to our internal environment, which is only available to us internally to see the latest code base in action.
The release process which Octopus runs through is made up of a series of steps, which are followed for every release to any environment. One of these steps enables a maintenance website to show a friendly message to anyone visiting our website whilst a release is taking place.
Octopus has many powerful options, from sending emails at specific points to running PowerShell scripts. Each of the steps in the release process can also use variables which are defined for a specific environment. This means a release to our internal environment can behave slightly differently to a release into staging or production.
Another benefit of Octopus is that it can be configured so that only a release manager can press the button to release to production. This ensures that only a release which has been fully tested and signed off can be released.
Summary
The agile manifesto puts more value in people over processes, but in the case of having repeatable and reliable releases it make sense to implement a solid process.
Depending on your technology stack there are various choices of tools and services for creating a continuous delivery pipeline. The ultimate aim is to have a repeatable and reliable process that makes releases mundane and frequent, because you have confidence each release will be successful.