The advent of continuous deployment is generally seen as a good thing, as it can both speed up development, as well as provide transparency of progress.
Agile techniques also provide faster development and better transparency, although this is achieved through process improvements rather than technical.
This post looks at how continuous deployment works within an agile framework, and whether or not sprints are still the right approach when using continuous deployment.
The two week sprint
Every development team these days claims to be doing agile development. Although you shouldn’t feel bad if you’re not. Just about every team I work with claims “We’re agile. Well, OK, we’re not strictly agile but…”.
The one thing that it seems everyone agrees on, no matter where they are on the “agile” scale, is that they work to a sprint of set length. Normally two weeks long, but I’ve also seen one week sprints, although that’s less common. I’ve never come across sprints longer than two weeks, that’s not to say they don’t exist though. Throughout this post I’ll simply refer to a two week sprint, but everything is applicable to a sprint of any size.
Whatever your sprint length, development operates the same. Start the sprint by estimating what stories/features you’re going to implement by the end of the sprint. Then, do the development work (of course). Finish the week with all your code deployed to a production environment.
Continuous X
The terms continuous integration, continuous delivery or continuous deployment are sometimes spoken in the same breath, or used interchangeably. The end-to-end chaining of these three might be referred to as a deployment pipeline.
Before going further I’ll define what the various continuous X terms mean.
Continuous integration
When code that a developer has written needs to be merged in with the rest of the team’s code, ideally, some checks should be run first. Usually linting of the code, checking that tests pass, and that merging won’t cause conflicts. In a continuous integration system, these checks and merges are able to happen automatically.
Continuous delivery
This is the next step up in terms of automation. As well as code merging automatically, a deployable artefact will also be built from it. For example, a zip file with all the code ready to be deployed on a server, or a container image ready to start up – the output type will depend on your environment. It is still a manual process to deploy the artefact somewhere. If you’re not building web or SOA apps then your process probably stops here.
Continuous deployment
The next level of automation is continuous deployment. This is when a developer can push code, it gets tested and merged, and then automatically deployed (whether to a test or production environment).
Aside: On Manual Button Pushing. Often we still want manual checks, even with continuous deployment. For example, you may only want to push into production during a certain maintenance window. Provided this takes place with a simple “button press” to activate the deployment, I would still consider this to be a “continuous” deployment.
In theory, continuous deployment is fantastic. Fixes and features can go into production quickly and reliably.
But, having continuous deployment fit in with the agile sprint, without the process being abused, can take some thought.
On the (ab)use of continuous deployment
Now that we have a CD system, how should it be used during agile development? As a team, you need to decide when deployments should happen.
In theory, with CD, we can deploy at any time, but is this something that you want to have as part of your process?
The use of deployment may be part of your “definition of done”, i.e. how you define when a story is complete. Should it be when code has been written? Or only when that code is deployed to production?
Development Done means Done
With this approach, you can consider a story complete once it has been developed. That is, the code has been written, tests and linting complete, and it’s merged to the main branch. Perhaps continuous delivery has completed and an artefact is ready to deploy.
Production deployment takes place with a “button push” at the end of sprint. All new code from the team, from the past two weeks, is deployed in one go.
Deployment Done means Done
You might choose to not consider a story done until it has been deployed to production. In this case when you push code it would automatically go out to production and then the story can be closed when that’s been verified. There is no big deployment at the end of sprint.
Either of these approaches can work well, and have their pros and cons. Having one big deployment can make it more difficult to track down which piece of code is causing issues after going live. Having many smaller deployments may cause more downtime (depending on how your system is built).
Where we need to start considering the agile/CD approach is during bug fixes, and end-of-sprint work – that is, work that it outside of the planned sprint scope.
The spanner in the works – bug fixes
Urgent bug fixes are the WORST. Of course, ideally, you’d catch bugs before they hit production. In reality you’ll probably encounter bugs in production sooner or later.
Continuous deployment makes getting fixes out a bit easier. Once a fix has been developed, going to production is very simple. Work on the fix can pre-empt other development work. There should be no reason to sit on urgent fixes until the end of the sprint. Instead they can be pushed out as soon as they’re ready.
Staying busy at sprint end
Speaking of the end of the sprint, often the question comes up of what to do if all your assigned stories have been completed before the sprint deadline. Again, in theory this shouldn’t happen because the size of the stories should align with sprint end.
The reality of estimation is that the sizes won’t be perfect, and so inevitably stories will be finished early or end up drifting to the next sprint.
If you do finish early, it can be a good time to close off some technical debt, such as code refactoring or extra tests, or updating library versions.
If you have enough time, you might want to start working on the next story. Perhaps you’ll use a kanban approach to grab the next highest priority issue to start developing.
But let’s say you’re a superstar developer and get another story closed off. Should you leave that until next sprint to release, or delight your users by pushing it out immediately, using continuous deployment? Ultimately your processes will determine this, but it’s not unfeasible that the business/product owners will be quite happy to get new features faster.
So for both bug fixes and features, we have the ability (and reasons), to deploy immediately – outside of the sprint’s planned work.
Let’s then consider the role of the two week sprint.
Has continuous deployment obsoleted the sprint?
We’ve just seen two examples of how development and deployment takes place outside of the sprint scope of work. This raises the question – could all development work take place outside of a two week sprint? Should developers simply work with a kanban style approach where stories are pulled from a prioritised list. They are developed and released as they are done without too much pre-planning.
The advantages of a set length sprint are claimed to be:
- fast iteration
- management of business expectation of when a feature will be ready
- certainty for developers on what they will be working on over the next two weeks
- providing metrics for velocity and estimation accuracy
We can consider a hybrid kanban style approach where story sizes are still estimated every week or two, and metrics can be derived for the prior weeks(s). We’ll compare this to a set-length sprint:
- fast iteration is possible, with stories being worked on in priority order, then deployed immediately when done
- we can still provide estimation of when a feature will be ready, keeping in mind that even a set-length sprint can still fall behind if the estimations aren't accurate
- the amount of certainty that a developer has depends on the accuracy of estimates, and also makes assumptions that no bugs will come in that require immediate attention
- metrics on velocity and estimation accuracy can still be calculated retrospectively
This approach can also provide a feeling of liberation to developers who are no longer locked into the two week cycle.
Missing a deadline can be a blow to the psyche.
Should a developer be concerned if their feature wasn’t completed by the sprint end, if (with the magic of CD) it can be deployed the next day anyway? Having these seemingly arbitrary and artificial lines in the sand can lead to the questioning of their usefulness by developers.
Conclusion
Continuous deployment systems are great. Once you have one in place, it’s worth considering how it can affect your approach to project management. When you can release at any time, do you need to be developing against an arbitrary deadline?
Is your team happy being stuck in a two week cycle? Or would moving towards a more ad-hoc style bring in a fresh perspective, and give your developers more freedom?