27 lines
1.7 KiB
Markdown
27 lines
1.7 KiB
Markdown
|
---
|
||
|
|
title: >
|
||
|
|
Are sprints incompatible with Continuous Deployment?
|
||
|
|
pubDate: 2022-11-08
|
||
|
|
permalink: >-
|
||
|
|
archive/2022/11/08/are-sprints-incompatible-with-continuous-deployment
|
||
|
|
# tags:
|
||
|
|
# - a
|
||
|
|
# - b
|
||
|
|
---
|
||
|
|
|
||
|
|
It's been common for me whilst working on software projects to have work organised into sprints or cycles - a period, usually between 1 and 3 weeks, where the team is working on stories and tasks for that project.
|
||
|
|
|
||
|
|
In my experience, those changes are usually released at the end of that cycle. But it seems that's not always the case; see [release sprints](https://scrumdictionary.com/term/release-sprint):
|
||
|
|
|
||
|
|
> A specialised sprint whose purpose is to release deliverable results; it contains stories specific to release activities and finishing undone work. A release sprint usually contains no additional development.
|
||
|
|
|
||
|
|
If we worked in two-week cycles and released at the end of each one, it would be at least two weeks before a change could be deployed to production. But what if we wanted to follow continuous deployment and release more frequently? Maybe daily or hourly?
|
||
|
|
|
||
|
|
Instead of waiting for a release sprint, if we released multiple times within a single sprint, how would this fit into or affect the process?
|
||
|
|
|
||
|
|
Does the release cycle need to be tightly coupled to the sprint cycle or can they be separate and independent of each other?
|
||
|
|
|
||
|
|
I've worked on projects - including a current one - where I've done multiple releases in a sprint, so of course, it can be done from a technical perspective, but how do we get the best from both processes - whether they work together or separately?
|
||
|
|
|
||
|
|
This is something that I'm going to continue to experiment with, iterate on, and learn more about going forward.
|