Continuous Delivery - Revision history

Mmusij: /* Intent */

2019-01-07T06:05:08Z

Intent

@@ Line 12: / Line 12: @@
 ==Intent==
-The intent of Continuous Delivery is to expose inefficiencies and get rapid feedback on the codebase, build scripts and the deployment pipeline so that any issues can be remedied quickly. The techniques also promote a holistic optimisation approach that considers the whole system and how it is built rather than focussing on just one part of it as with localised optimisation.
+The intent of Continuous Delivery is to expose inefficiencies and get rapid feedback on the codebase, build scripts and the deployment pipeline so that any issues can be remedied quickly. The techniques promote a holistic optimisation approach that considers the whole system and how it is built rather than focussing on just one part of it as with localised optimisation.
 ==Delivery Pipeline==

Mmusij at 05:29, 7 January 2019

2019-01-07T05:29:33Z

← Older revision		Revision as of 05:29, 7 January 2019
Line 10:		Line 10:

	From customers' perspective they experience small incremental changes that evolve the customer experience over time, and arguably with small features, there is little training or change management needed.		From customers' perspective they experience small incremental changes that evolve the customer experience over time, and arguably with small features, there is little training or change management needed.

			==Intent==
			The intent of Continuous Delivery is to expose inefficiencies and get rapid feedback on the codebase, build scripts and the deployment pipeline so that any issues can be remedied quickly. The techniques also promote a holistic optimisation approach that considers the whole system and how it is built rather than focussing on just one part of it as with localised optimisation.

	==Delivery Pipeline==		==Delivery Pipeline==

Mmusij: /* Backout */

2018-12-21T05:35:20Z

Backout

← Older revision		Revision as of 05:35, 21 December 2018
Line 42:		Line 42:
	* back out the change by redirecting traffic back to the original duplicate production environment		* back out the change by redirecting traffic back to the original duplicate production environment
	* redeploy a known stable previous version to the production environment and overwrite the change		* redeploy a known stable previous version to the production environment and overwrite the change

			==Feature Toggles==
			[[Feature Toggles]] allow for features to be turned on/off via a configuration file or similar. This approach allows for features that comprise numerous small changes to be deployed in a flow based "pull" approach without impacting production until the feature dependencies have all been deployed.

			Feature toggles then allow for the feature to be broken up into smaller more manageable work items during development that can be deployed as and when they are ready without compromising production or an agile approach.

	==See Also==		==See Also==

Mmusij: /* Delivery Pipeline */

2018-12-21T05:25:03Z

Delivery Pipeline

← Older revision		Revision as of 05:25, 21 December 2018
Line 37:		Line 37:
	===Race Conditions===		===Race Conditions===
	If several teams are working concurrently on a common code base, then there is the potential for multiple check-ins to trigger the delivery pipeline automated processes and cause a "stack" of processes to be run. To avoid complications and race conditions forming, a good CI/CD server should be able to avoid surplus executions and bypass intermediate releases and focus on the latest release instead.		If several teams are working concurrently on a common code base, then there is the potential for multiple check-ins to trigger the delivery pipeline automated processes and cause a "stack" of processes to be run. To avoid complications and race conditions forming, a good CI/CD server should be able to avoid surplus executions and bypass intermediate releases and focus on the latest release instead.

			==Backout==
			One of the main fears about deployment is if a defect in the code is also deployed and unexpected behaviour in production is experienced. Two strategies to counter this fear include:
			* back out the change by redirecting traffic back to the original duplicate production environment
			* redeploy a known stable previous version to the production environment and overwrite the change

	==See Also==		==See Also==

Mmusij: /* Guiding Principles */

2018-12-21T05:14:35Z

Guiding Principles

← Older revision		Revision as of 05:14, 21 December 2018
Line 21:		Line 21:
	* release small amounts of change more often to get more practice at releasing and constantly curating the product in production		* release small amounts of change more often to get more practice at releasing and constantly curating the product in production
	* make releasing easy and it will be done more often, allowing more frequent feedback		* make releasing easy and it will be done more often, allowing more frequent feedback
			* automated release processes allow for democratised releasing approaches were developers and testers can deploy on demand to their respective environments

	===Elimination of Problematic Release Candidates===		===Elimination of Problematic Release Candidates===

Mmusij: /* Delivery Pipeline */

2018-12-21T05:12:09Z

Delivery Pipeline

← Older revision		Revision as of 05:12, 21 December 2018
Line 15:		Line 15:
	A delivery pipeline is intended to be an automated mechanism for "...getting software from version control into the hands of your users."[1] A pipeline usually has monitoring and a push button interface to enable builds to be constructed and then deployed to environments, culminating in a deployment to production.		A delivery pipeline is intended to be an automated mechanism for "...getting software from version control into the hands of your users."[1] A pipeline usually has monitoring and a push button interface to enable builds to be constructed and then deployed to environments, culminating in a deployment to production.

	~~Here are some~~ guiding principles behind a continuous delivery pipeline:		===Guiding Principles===
			Some guiding principles behind a continuous delivery pipeline include:
	* everyone contributes to keep the release plan updated and maintained, using a collective ownership principle		* everyone contributes to keep the release plan updated and maintained, using a collective ownership principle
	* minimise the need to human intervention by automating as much as possible to provide a reliable and repeatable process		* minimise the need to human intervention by automating as much as possible to provide a reliable and repeatable process

Mmusij: /* Delivery Pipeline */

2018-12-21T05:11:17Z

Delivery Pipeline

← Older revision		Revision as of 05:11, 21 December 2018
Line 14:		Line 14:

	A delivery pipeline is intended to be an automated mechanism for "...getting software from version control into the hands of your users."[1] A pipeline usually has monitoring and a push button interface to enable builds to be constructed and then deployed to environments, culminating in a deployment to production.		A delivery pipeline is intended to be an automated mechanism for "...getting software from version control into the hands of your users."[1] A pipeline usually has monitoring and a push button interface to enable builds to be constructed and then deployed to environments, culminating in a deployment to production.

			Here are some guiding principles behind a continuous delivery pipeline:
			* everyone contributes to keep the release plan updated and maintained, using a collective ownership principle
			* minimise the need to human intervention by automating as much as possible to provide a reliable and repeatable process
			* release small amounts of change more often to get more practice at releasing and constantly curating the product in production
			* make releasing easy and it will be done more often, allowing more frequent feedback

	===Elimination of Problematic Release Candidates===		===Elimination of Problematic Release Candidates===
Line 28:		Line 34:

	===Race Conditions===		===Race Conditions===
	If several teams are working concurrently on a common code base, then there is the potential for multiple check-ins to trigger the delivery pipeline automated processes and cause a "stack" of processes to be run. To avoid complications and race conditions forming, a good CI/CD server should be able to avoid surplus executions and bypass intermediate releases and focus on the latest release instead.		If several teams are working concurrently on a common code base, then there is the potential for multiple check-ins to trigger the delivery pipeline automated processes and cause a "stack" of processes to be run. To avoid complications and race conditions forming, a good CI/CD server should be able to avoid surplus executions and bypass intermediate releases and focus on the latest release instead.

	==See Also==		==See Also==

Mmusij at 00:42, 21 December 2018

2018-12-21T00:42:18Z

← Older revision		Revision as of 00:42, 21 December 2018
Line 16:		Line 16:

	===Elimination of Problematic Release Candidates===		===Elimination of Problematic Release Candidates===
	Several stages in the pipeline may be setup such as code check in -> build and automated unit tests -> automated acceptance tests -> user acceptance test & approval -> release. If a release candidate fails at any step along they way then this is good feedback to indicate that some issues exist and need to be resolved before the candidate can be released. Those release candidates that make it to the release stage without any issues then stand a good chance of being deployed.		Several stages in the pipeline may be setup such as code check in -> build and automated unit tests -> automated acceptance tests -> user acceptance test & approval -> release. If a release candidate fails at any step along they way then this is good feedback to indicate that some issues exist and need to be resolved before the candidate can be released. In this instance a "stop the line" culture works bast to halt the pipeline for this release and go back and fix the issues. Those release candidates that make it to the release stage without any issues then stand a good chance of being deployed.

	===Duplicate Production Environments===		===Duplicate Production Environments===
Line 26:		Line 26:

	It's good to also run an automated smoke test post release to provide technical feedback that the deployment with the new feature is working as expected, and if not, then an automated rollback process can be invoked to revert to the previous state before the release was started.		It's good to also run an automated smoke test post release to provide technical feedback that the deployment with the new feature is working as expected, and if not, then an automated rollback process can be invoked to revert to the previous state before the release was started.

			===Race Conditions===
			If several teams are working concurrently on a common code base, then there is the potential for multiple check-ins to trigger the delivery pipeline automated processes and cause a "stack" of processes to be run. To avoid complications and race conditions forming, a good CI/CD server should be able to avoid surplus executions and bypass intermediate releases and focus on the latest release instead.

	==See Also==		==See Also==
	[[Release Planning]]		* [[Release Planning]]

	==References==		==References==
	# Continuous Delivery, Humble J, Farley D, 2011		# Continuous Delivery, Humble J, Farley D, 2011

Mmusij at 00:18, 21 December 2018

2018-12-21T00:18:36Z

← Older revision		Revision as of 00:18, 21 December 2018
Line 18:		Line 18:
	Several stages in the pipeline may be setup such as code check in -> build and automated unit tests -> automated acceptance tests -> user acceptance test & approval -> release. If a release candidate fails at any step along they way then this is good feedback to indicate that some issues exist and need to be resolved before the candidate can be released. Those release candidates that make it to the release stage without any issues then stand a good chance of being deployed.		Several stages in the pipeline may be setup such as code check in -> build and automated unit tests -> automated acceptance tests -> user acceptance test & approval -> release. If a release candidate fails at any step along they way then this is good feedback to indicate that some issues exist and need to be resolved before the candidate can be released. Those release candidates that make it to the release stage without any issues then stand a good chance of being deployed.

			===Duplicate Production Environments===
			Often the development and testing environments are different from the target production environment, which can present unique issues from time to time. If there is sufficient budget then it can be a good idea to have duplicate production environments that can then be used via load balancing to divert traffic to test the new release on a production environment and provide feedback and confidence that it is working as expected.

			If there are problems then the load balancing can divert traffic back to the original production environment until the issues are resolved.

			When there is sufficient confidence the release can then be deployed to the remaining production environments.

			It's good to also run an automated smoke test post release to provide technical feedback that the deployment with the new feature is working as expected, and if not, then an automated rollback process can be invoked to revert to the previous state before the release was started.

	==See Also==		==See Also==

Mmusij at 00:03, 21 December 2018

2018-12-21T00:03:17Z

← Older revision		Revision as of 00:03, 21 December 2018
Line 6:		Line 6:

	Continuous Delivery extends the feedback cycle to also include shipping the feature when it is done providing a rolling horizon of working changes into production, with a side benefit of providing rapid customer feedback as well as facilitating customer testing options such as A\|B testing for example.		Continuous Delivery extends the feedback cycle to also include shipping the feature when it is done providing a rolling horizon of working changes into production, with a side benefit of providing rapid customer feedback as well as facilitating customer testing options such as A\|B testing for example.

			For a deployment process that is fast, easy and reliable, then teams will begin to naturally release more often and with confidence.

			From customers' perspective they experience small incremental changes that evolve the customer experience over time, and arguably with small features, there is little training or change management needed.

	==Delivery Pipeline==		==Delivery Pipeline==
Line 11:		Line 15:
	A delivery pipeline is intended to be an automated mechanism for "...getting software from version control into the hands of your users."[1] A pipeline usually has monitoring and a push button interface to enable builds to be constructed and then deployed to environments, culminating in a deployment to production.		A delivery pipeline is intended to be an automated mechanism for "...getting software from version control into the hands of your users."[1] A pipeline usually has monitoring and a push button interface to enable builds to be constructed and then deployed to environments, culminating in a deployment to production.

	~~The intention~~		===Elimination of Problematic Release Candidates===
			Several stages in the pipeline may be setup such as code check in -> build and automated unit tests -> automated acceptance tests -> user acceptance test & approval -> release. If a release candidate fails at any step along they way then this is good feedback to indicate that some issues exist and need to be resolved before the candidate can be released. Those release candidates that make it to the release stage without any issues then stand a good chance of being deployed.