Digital

How we approach continuous delivery

November 4, 2015 by craigmilligan No Comments | Category Digital Public Services, mygov.scot

This is a post by Gordon Clark, one of our Infrastructure Engineers, and Jono Ellis, our Social Media Manager.

Over the next few weeks, we have a series of blog posts coming up which cover our approach to continuous delivery. This first post is a high-level overview of our work, mostly written for our readers who work in government, the individual posts will be more detailed and will be aimed at infrastructure engineers, developers and testers. We’d love to hear your comments and questions, so let us know either at the comments section below or via Twitter.

Over the coming weeks we aim to cover:

• Zero downtime releases;
• Masterless Puppet and Declarative provisioning;
• Virtual infrastructure;
• Definitive Media Library in the cloud;
• Monitoring;
• Build pipeline;
• Test automation.

The mygov.scot site is built from the ground up around the needs of the user. To find out if we’re building the right thing we want to be able to quickly get our work in front of our users – this ensures that we receive feedback early and often, and allows us to change direction accordingly. We also want to ensure that we are delivering consistently, and with quality. The model that we have in place to control how we work is called continuous delivery.

What is continuous delivery?
In order to get, as quickly as possible, from an idea to a service that can be accessed by users, there is a process of build, deploy, test and release. This cycle should allow reliable, rapid and cost-effective software delivery. The faster we can make this process, the faster we can get great quality software in front of our users and this means that we can get feedback on our service even more quickly. The mygov.scot team have been working iteratively right from the start and continuous integration and continuous delivery are an important part of how this works for us. For us, a new feature of our service is not “done” until it has been released and users have access to it.

Modern software delivery can include a number of activities that happen continuously:

• Continuous integration is a delivery practice requiring that each time an engineer makes a code or configuration change, the entire application is built and tested;
• Continuous delivery is a delivery model (a suite of practices) that focuses on making sure that every individual change to an application or service can be released on demand, at the “push of button”;
• Continuous deployment extends the idea of continuous delivery further, automatically deploying each successful change without manual confirmation.

At this time we’re comfortable with the balance of agility and control provided by continuous delivery, but we may consider continuous deployment in the future.

The benefits to the business
We work with a continuous delivery approach because it makes good business sense – the process is visible, allows for improved feedback and isn’t as susceptible to human error as a less automated process. We are aiming for the very best quality in our work – by automating as much as we can we eliminate some risk. By moving away from the deployment team manually deploying the software, we ensure the steps needed to test and deploy happen the same way every time. The improved feedback loop means that we are taking smaller steps before a user can come back with their comments, allowing us to regularly confirm that we are heading in the right direction. No egos are involved – software passes or fails based on an automated test and the results of those tests can then be used to get the software up to scratch.

Where we are right now
After creating a new feature to meet a particular user need, our developers can submit that change (be it to source code, the environment, config files, etc.) to our version control system. These changes are then pulled through to our continuous integration server which triggers a new build on the pipeline. This new build is then subject to a range of automated tests as it progresses through the environments of our deployment pipeline, at each step increasing our confidence that it can be released to the public. The automated tests are complemented with exploratory testing performed by our test engineers.

Environment creation and deployment activities are fully automated, allowing team members to release the latest build (or a previous known good build) into an existing or new environment on demand. The basic process:

• Check-in (to a source control system i.e. GIT)
• Build (compile/package)
• Test (via our test scripts)
• Promote (manually triggered promotion to other environments)

An overview of how we approach continuous delivery

Part of the reason that continuous delivery works so well for us is because almost all of our infrastructure is virtual rather than physical. The mygov.scot team don’t have our own physical server anywhere in the office – instead we rely on virtual servers in the cloud (as described in Scotland’s Digital Future: Data Hosting and Data Centre Strategy for the Scottish Public Sector, which promotes a cloud-first approach).

The top 3 benefits of using cloud computing from our perspective are:

• Elasticity – the ability to scale horizontally (both up and down) as demand for services changes;
• Flexibility – the ability to commission and decommission environments on demand to meet the needs of our delivery team;
• Cost model – avoidance of capital expenditure, incremental cost reductions as technology and economies of scale improve.

When we talk about changing the configuration of a server it is something that can be done in minutes and hours rather than months. These things all combine to have a positive impact on our ability to test or run a new version of something without ever impacting on what is currently live.

Where we aim to be in 6 months
The main challenge that our team faces is to continue to be able to modify the environment seamlessly even though we have continually changing requirements and we don’t know where the system will need to be in the future.

Although we’ve automated a great deal of the software delivery process we think there are still many improvements to be made. If we can enhance the results and confidence that we have in our testing and error handling then the process will become even stronger. For example, by expanding our test coverage our confidence to release a new build will be increased. At the moment we have first iterations of where we’d like to be – we’re aiming to be able to repeat the process every time without fail, in order to guarantee the quality of what we are putting out (with minimal manual intervention). We’d also like to focus on measuring the delivery process so that we can better identify areas for improvement.

We feel that continuous delivery has helped us get to where we are now by letting us work quickly and ensure a high quality of work. If you want to learn more about continuous delivery then we thoroughly recommend reading Continuous Delivery by Jez Humble.

Follow the team on Twitter via @mygovscot for more updates. Want to comment? Let us know below!

Tags: Technology & Digital Architecture

Comments