Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deploy little and often #462

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
38 changes: 38 additions & 0 deletions docs/principles/deploy-little-and-often.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
---
layout: principle
order: 1
title: Deploy little and often
date: 2024-09-26
tags:
- Build, release and deploy
- Ways of working
- Deployment
- CI/CD
- Quality
---
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
---
related:
sections:
- title: Related links
items:
- text: Selecting a deployment strategy
href: /patterns/selecting-a-deployment-strategy/
- text: Make small changes
href: /patterns/make-small-changes/
---


Deploying little and often is the practice of when we have a "completed" change and deploying that through
our pipeline stages all the way to production often, no matter the size of the change. This reduces risk, enables the team to fix issues faster and iterate faster, while maintaining high product quality.
ThomasWilliamsHO marked this conversation as resolved.
Show resolved Hide resolved
ThomasWilliamsHO marked this conversation as resolved.
Show resolved Hide resolved

---

## Rationale

Deploying little and often strategy will enable users to see changes faster and then provide feedback.
ThomasWilliamsHO marked this conversation as resolved.
Show resolved Hide resolved

The cost of fixing potential issues is also smaller due to the fact that the little and often approach allows us to quickly adapt and release or rollback to a stable state, also
the smaller the change being pushed out the smaller the chance of merge conflicts.
ThomasWilliamsHO marked this conversation as resolved.
Show resolved Hide resolved
ThomasWilliamsHO marked this conversation as resolved.
Show resolved Hide resolved

With this approach it builds confidence in the product to stakeholders by the means of more successful incremental builds, allowing there to be less pressure around a release.
Big sizeable releases that fail can cause a lot of pain not just for stakeholders but for others such as customers that rely on the system.
ThomasWilliamsHO marked this conversation as resolved.
Show resolved Hide resolved

---

## Applications and Implications

- This principle is reliant on good quality tests which validate the release before it gets to production, therefore tests reinforce the confidence in our builds so that we can deploy often
ThomasWilliamsHO marked this conversation as resolved.
Show resolved Hide resolved
- We have CI/CD pipelines that are quick and efficient, automating repetitive tasks so that we can deploy little and often
- We must be aware of downstream users, fixing forward is good which is what this principle implies but not every aspect of your project may be using this principle and therefore not as flexible
ThomasWilliamsHO marked this conversation as resolved.
Show resolved Hide resolved
- As we will be deploying more often there is the option to use feature flags as a way to better safeguard with new features continually coming through to production
ThomasWilliamsHO marked this conversation as resolved.
Show resolved Hide resolved
ThomasWilliamsHO marked this conversation as resolved.
Show resolved Hide resolved

---