Scrum, Sprints, and CI/CD
My company has been talking a lot about CI/CD recently, so as the Agile Coach I've been reading up on it a bit. I understand the concepts, but I'm confused about how it fits in with Sprints. Are Scrum Teams supposed to be releasing to Production all throughout a sprint with CI/CD? What is the point of the sprint then? Right now we release to production at the end of every sprint. I'm not connecting the dots on how to switch to every day. Can someone help?
Hi Jessica, with CI/CD you may be releasing along the way throughout the Sprint, it of course depends on how you are applying CI/CD. The idea of the Sprint is for reviews, feedback and adjustments. If for example, you are releasing daily, you don't want to have stakeholders, etc. doing a Sprint Review daily and there may not even be enough value and lots of Work in Progress happening on a daily basis to make sense to review. The Sprint helps you to limit the WIP, get feedback on the increment which can be made up of many releases, work toward a common goal and adjust as you go to improve how you work and implement ongoing feedback.
There are several articles and blog about Scrum with CI/CD found here: https://www.scrum.org/resources?search=Continuous%20Delivery
There are significant differences between Continuous Integration, Continuous Delivery, and Continuous Deployment.
In Continuous Integration, the work of developers is integrated (merged) frequently and automated tests are run. As you get more advanced tooling, the automated execution of tests can also trigger rolling back code that fails tests. The idea is that issues around integrating the work of multiple developers or multiple teams of developers does not become an issue and conflicts that need to be resolved are minimized.
The use of Continuous Integration helps to enable agile software development. It reduces feedback cycles from the act of writing code to getting confirmation that the code has left the system in a stable state. It requires a high level of automated test coverage and tooling to support test cycles on every commit and/or pull request. The foundation of Continuous Integration is automated test coverage (preferably at all levels of testing). Since manual testing doesn't scale, you need automated testing in order to ensure that your team and organization maintains responsiveness and adaptability. If you're going to have good automated test coverage, you might as well work toward Continuous Integration and get rapid feedback to developers.
Continuous Delivery takes this a step further. It ensures that the software can be released at any moment in time. The idea is that after a successful integration, build, and test cycle from Continuous Integration, the decision can be made to release the software and it can automatically be released to the appropriate environment(s).
The step to Continuous Delivery isn't that far, once you have robust automated test coverage. If you have high confidence that the system works as expected, it becomes easy for your Product Owner to evaluate the changes made and determine if it's worth deploying those changes. Your entire team should have confidence in the stability and reliability and correctness of the system.
Continuous Deployment takes this yet another step further. Instead of needing to make a decision to release the software, it is automatically deployed after every successful integration, build, and test cycle.
The step to Continuous Deployment is really a Product Owner decision - do you need to frequently get changes to users or do you just need the ability to? You can also consider deployment to different environments - continuously deploy to test environments or demonstration environments to be able to get feedback from stakeholders without actually deploying to your live production environment.
Scrum supports all three of these. The requirement in Scrum is that a Development Team ends each Sprint with a done Increment that is potentially releasable. It does not say that the only time a done Increment can be made available for the Product Owner to release is at the end of the Sprint - multiple Increments can be made in the course of the Sprint and the Product Owner may choose to release any number of those. Regardless of what you do, the Sprint timebox exists to ensure that you are giving appropriate time to planning your work, making progress visible to stakeholders, and inspecting the product as well as the team's process for making the product and improving both with feedback from the correct stakeholders.
What is the point of the sprint then?
The purpose of a Sprint is to meet a Sprint Goal. Can you see how CI/CD might help with this, particularly with regard to obtaining rapid empirical feedback?