From 2214b8d667c712ccb2ec9156600e5dc1566343ef Mon Sep 17 00:00:00 2001 From: Thomas Williams <125026090+ThomasWilliamsHO@users.noreply.github.com> Date: Thu, 26 Sep 2024 09:19:58 +0100 Subject: [PATCH 1/8] Create deploy-little-and-often.md Initial principle submit --- docs/principles/deploy-little-and-often.md | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 docs/principles/deploy-little-and-often.md diff --git a/docs/principles/deploy-little-and-often.md b/docs/principles/deploy-little-and-often.md new file mode 100644 index 00000000..59f77eaa --- /dev/null +++ b/docs/principles/deploy-little-and-often.md @@ -0,0 +1,32 @@ +--- +layout: principle +order: 1 +title: Deploy little and often +date: 2024-09-26 +tags: +- Ways of working +- Build, release and deploy +--- + +Deploying little and often is the practice of when we have a "completed" change 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 +--- + +## Rationale + +Deploying little and often strategy will enable users to see changes faster and then provide feedback. + +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 + +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. + +--- + +## Applications and Implications + +- We have tests that reinforce the confidence in our builds so that we can deploy often, therefore we must make sure our tests are of good quality +- We have CI/CD pipelines that are quick and efficient, automating repetitive tasks so that we can deploy little and often + +--- From 1d1eb0e02b64bfdfc031884f44cd3be49565992f Mon Sep 17 00:00:00 2001 From: Thomas Williams <125026090+ThomasWilliamsHO@users.noreply.github.com> Date: Tue, 1 Oct 2024 09:44:18 +0100 Subject: [PATCH 2/8] Update deploy-little-and-often.md --- docs/principles/deploy-little-and-often.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/docs/principles/deploy-little-and-often.md b/docs/principles/deploy-little-and-often.md index 59f77eaa..c1a1d02c 100644 --- a/docs/principles/deploy-little-and-often.md +++ b/docs/principles/deploy-little-and-often.md @@ -4,12 +4,16 @@ order: 1 title: Deploy little and often date: 2024-09-26 tags: -- Ways of working - Build, release and deploy +- Ways of working +- Deployment +- CI/CD +- Quality --- -Deploying little and often is the practice of when we have a "completed" change 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 +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. + --- ## Rationale @@ -17,7 +21,7 @@ our pipeline stages all the way to production often, no matter the size of the c Deploying little and often strategy will enable users to see changes faster and then provide feedback. 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 +the smaller the change being pushed out the smaller the chance of merge conflicts. 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. @@ -26,7 +30,9 @@ Big sizeable releases that fail can cause a lot of pain not just for stakeholder ## Applications and Implications -- We have tests that reinforce the confidence in our builds so that we can deploy often, therefore we must make sure our tests are of good quality -- We have CI/CD pipelines that are quick and efficient, automating repetitive tasks so that we can deploy little and often +- 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 +- 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 prohect may be using this principle and therefore not as flexible +- 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 --- From 12e77a7e82046815b2630169624d0d943179ee4d Mon Sep 17 00:00:00 2001 From: Thomas Williams <125026090+ThomasWilliamsHO@users.noreply.github.com> Date: Wed, 9 Oct 2024 07:50:42 +0100 Subject: [PATCH 3/8] Update deploy-little-and-often.md Correct spelling --- docs/principles/deploy-little-and-often.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/principles/deploy-little-and-often.md b/docs/principles/deploy-little-and-often.md index c1a1d02c..22371083 100644 --- a/docs/principles/deploy-little-and-often.md +++ b/docs/principles/deploy-little-and-often.md @@ -32,7 +32,7 @@ Big sizeable releases that fail can cause a lot of pain not just for stakeholder - 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 - 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 prohect may be using this principle and therefore not as flexible +- 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 - 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 --- From 9e82fecd8822e7d5e9ee981aced72f25c654b7b2 Mon Sep 17 00:00:00 2001 From: Thomas Williams <125026090+ThomasWilliamsHO@users.noreply.github.com> Date: Wed, 30 Oct 2024 07:53:03 +0000 Subject: [PATCH 4/8] Update docs/principles/deploy-little-and-often.md Suggestion clean up Co-authored-by: Paul Wright --- docs/principles/deploy-little-and-often.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/principles/deploy-little-and-often.md b/docs/principles/deploy-little-and-often.md index 22371083..13689bf2 100644 --- a/docs/principles/deploy-little-and-often.md +++ b/docs/principles/deploy-little-and-often.md @@ -11,8 +11,9 @@ tags: - Quality --- -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. +Deploying little and often is the practice of regularly deploying small changes, to production if possible, to avoid long intervals between deployments. + +This reduces risk, enables teams to iterate and react faster, while maintaining product quality. --- From f439bfac037bd2cf8fcff0c2bd81d178c80a3382 Mon Sep 17 00:00:00 2001 From: Thomas Williams <125026090+ThomasWilliamsHO@users.noreply.github.com> Date: Wed, 30 Oct 2024 08:17:17 +0000 Subject: [PATCH 5/8] Apply suggestions from code review Co-authored-by: Paul Wright --- docs/principles/deploy-little-and-often.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/principles/deploy-little-and-often.md b/docs/principles/deploy-little-and-often.md index 13689bf2..363a323a 100644 --- a/docs/principles/deploy-little-and-often.md +++ b/docs/principles/deploy-little-and-often.md @@ -19,13 +19,12 @@ This reduces risk, enables teams to iterate and react faster, while maintaining ## Rationale -Deploying little and often strategy will enable users to see changes faster and then provide feedback. +Deploying little and often reduces lead time from change request to release, for both new features and bug fixes. This enables users to see changes faster and provide feedback. 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. -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. +Smaller, incremental deployments build confidence for stakeholders, creating less pressure around a release. Larger, infrequent releases that fail cause additional delays in new features and bug fixes, impacting the project team and users alike. --- @@ -34,6 +33,6 @@ Big sizeable releases that fail can cause a lot of pain not just for stakeholder - 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 - 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 -- 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 +- Deployment strategies should be considered where appropriate. For example, feature flags can be used to allow deployments to occur without releasing new functionality to all users at once. See [Selecting a deployment strategy](/patterns/selecting-a-deployment-strategy/) for more detail --- From 44dc541c18ae2ec63140cc68b3bdc6f31a178317 Mon Sep 17 00:00:00 2001 From: Thomas Williams <125026090+ThomasWilliamsHO@users.noreply.github.com> Date: Wed, 30 Oct 2024 08:19:01 +0000 Subject: [PATCH 6/8] Update deploy-little-and-often.md Code review suggestions --- docs/principles/deploy-little-and-often.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/principles/deploy-little-and-often.md b/docs/principles/deploy-little-and-often.md index 363a323a..aff1580e 100644 --- a/docs/principles/deploy-little-and-often.md +++ b/docs/principles/deploy-little-and-often.md @@ -21,8 +21,7 @@ This reduces risk, enables teams to iterate and react faster, while maintaining Deploying little and often reduces lead time from change request to release, for both new features and bug fixes. This enables users to see changes faster and provide feedback. -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. +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. The smaller the change being pushed out the smaller the chance of merge conflicts. Smaller, incremental deployments build confidence for stakeholders, creating less pressure around a release. Larger, infrequent releases that fail cause additional delays in new features and bug fixes, impacting the project team and users alike. From 74407f9010301381412a7a4ddab5ca54601b3801 Mon Sep 17 00:00:00 2001 From: Thomas Williams <125026090+ThomasWilliamsHO@users.noreply.github.com> Date: Wed, 6 Nov 2024 08:32:54 +0000 Subject: [PATCH 7/8] Apply suggestions from code review Co-authored-by: Paul Wright --- docs/principles/deploy-little-and-often.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/principles/deploy-little-and-often.md b/docs/principles/deploy-little-and-often.md index aff1580e..9c84c2bd 100644 --- a/docs/principles/deploy-little-and-often.md +++ b/docs/principles/deploy-little-and-often.md @@ -29,9 +29,9 @@ Smaller, incremental deployments build confidence for stakeholders, creating les ## 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 +- This principle is reliant on good quality tests which validate the release before it gets to production. These tests reinforce the confidence in our builds so that we can deploy often. Adding automated test coverage will greatly improve a team's likelihood of achieving this principle. - 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 +- We must be aware of how frequent releases affect users, and consider whether it is applicable in each use case. For example, where a breaking change is introduced, or an in-progress operation would be affected - Deployment strategies should be considered where appropriate. For example, feature flags can be used to allow deployments to occur without releasing new functionality to all users at once. See [Selecting a deployment strategy](/patterns/selecting-a-deployment-strategy/) for more detail --- From 85ce921c936c79dc92813886db3c8117115b377e Mon Sep 17 00:00:00 2001 From: Thomas Williams <125026090+ThomasWilliamsHO@users.noreply.github.com> Date: Wed, 6 Nov 2024 08:36:08 +0000 Subject: [PATCH 8/8] Update deploy-little-and-often.md Update wording mistake --- docs/principles/deploy-little-and-often.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/principles/deploy-little-and-often.md b/docs/principles/deploy-little-and-often.md index 9c84c2bd..77d92f0f 100644 --- a/docs/principles/deploy-little-and-often.md +++ b/docs/principles/deploy-little-and-often.md @@ -29,7 +29,7 @@ Smaller, incremental deployments build confidence for stakeholders, creating les ## Applications and Implications -- This principle is reliant on good quality tests which validate the release before it gets to production. These tests reinforce the confidence in our builds so that we can deploy often. Adding automated test coverage will greatly improve a team's likelihood of achieving this principle. +- This principle is reliant on good quality tests which validate the release before it gets to production. These tests reinforce the confidence in our builds so that we can deploy often. Adding automated test coverage for example can greatly improve a team's likelihood of achieving this principle. - 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 how frequent releases affect users, and consider whether it is applicable in each use case. For example, where a breaking change is introduced, or an in-progress operation would be affected - Deployment strategies should be considered where appropriate. For example, feature flags can be used to allow deployments to occur without releasing new functionality to all users at once. See [Selecting a deployment strategy](/patterns/selecting-a-deployment-strategy/) for more detail