Continuous delivery (CD) is a set of processes, tools, and techniques for rapid, reliable, and continuous software development and delivery.
It means that continuous delivery goes beyond the release of software through a pipeline. The pipeline is a crucial component and the focus of this course, but continuous delivery is more.
Look at the eight principles of continuous delivery:
- The process for releasing/deploying software must be repeatable and reliable.
- Automate everything!
- If something is difficult or painful, do it more often.
- Keep everything in source control.
- Done means "released."
- Build quality in!
- Everybody has responsibility for the release process.
- Improve continuously.
- Software architecture (monoliths are hard to deploy).
- Testing strategy (manual tests don't scale well).
- Organization (separated business and IT departments don't work smoothly), and so forth.
Continuous delivery is a practice. It's being able to deliver software on demand. Not necessarily 1000 times a day. Deploying every code change to production is what we call continuous deployment.
To achieve this, we need something like Continuous Delivery.
To deploy more often, we need to reconsider our:
We need to move towards a situation where the value isn't piled up and released all at once but flows through a pipeline.
So, work must be prioritized in the right way. As you can see, the pipeline has green and red outlets. These are the feedback loops or quality gates that we want to have in place. A feedback loop can be different things:
- A unit test to validate the code.
- An automated build to validate the sources.
- An automated test on a Test environment.
- Some monitor on a server.
- Usage instrumentation in the code.
Last year around 80% of all companies claimed that they adopted Scrum as a software development practice. Using Scrum, many teams can produce a working piece of software after a sprint of maybe two or three weeks.
Comments
Post a Comment