Deployment methodologies - Revision history

Root at 20:06, 20 October 2025

2025-10-20T20:06:16Z

← Older revision		Revision as of 21:06, 20 October 2025
Line 1:		Line 1:
	Modern deployment methodologies aim to reduce risks associated with releasing new software versions, ensuring that users have a seamless experience and any negative impact from changes is minimized. The principal deployment strategies are:		Modern deployment methodologies aim to reduce risks associated with releasing new software versions, ensuring that users have a seamless experience and any negative impact from changes is minimized. The principal deployment strategies are:<span id="ab-testing-or-split-testing"></span>

	<span id="ab-testing-or-split-testing"></span>
	= A/B Testing (or split testing) =		= A/B Testing (or split testing) =

Line 11:		Line 9:
	* '''Data-driven decisions''': Decisions about feature releases or changes are based on actual user data.		* '''Data-driven decisions''': Decisions about feature releases or changes are based on actual user data.
	* '''Risk reduction''': If version B performs poorly, only a subset of users is affected.		* '''Risk reduction''': If version B performs poorly, only a subset of users is affected.

	~~<span id="feature-flags-or-feature-toggles"></span>~~
	= Feature flags (or feature toggles) =		= Feature flags (or feature toggles) =

Line 21:		Line 17:
	* '''Gradual rollout''': Release new features gradually to specific users or environments.		* '''Gradual rollout''': Release new features gradually to specific users or environments.
	* '''Safe failover''': If an issue arises, the feature can be quickly disabled without a full rollback or redeploy.		* '''Safe failover''': If an issue arises, the feature can be quickly disabled without a full rollback or redeploy.
	* '''Environment consistency''': The same codebase runs in all environments, ensuring consistency.		* '''Environment consistency''': The same codebase runs in all environments, ensuring consistency.<span id="blue-green-deployment"></span>

	<span id="blue-green-deployment"></span>
	= Blue-Green Deployment =		= Blue-Green Deployment =

Line 33:		Line 27:
	* '''Instant rollback''': If issues are detected, traffic can be immediately routed back to the old environment.		* '''Instant rollback''': If issues are detected, traffic can be immediately routed back to the old environment.
	* '''Isolated testing''': The non-live environment provides an exact replica for testing before going live.		* '''Isolated testing''': The non-live environment provides an exact replica for testing before going live.

	~~<span id="canary-deployment"></span>~~
	= Canary deployment =		= Canary deployment =

Line 43:		Line 35:
	* '''Risk minimization''': Initial exposure to a limited user group reduces potential widespread impact.		* '''Risk minimization''': Initial exposure to a limited user group reduces potential widespread impact.
	* '''Real-world feedback''': Gaining insights from actual users can help identify issues that might not appear in staging environments.		* '''Real-world feedback''': Gaining insights from actual users can help identify issues that might not appear in staging environments.
	* '''Gradual scale''': If the canary group doesn't report issues, the release is gradually scaled to more users.		* '''Gradual scale''': If the canary group doesn't report issues, the release is gradually scaled to more users.<span id="rollup-deployment"></span>
			= Rollup deployment =
	<span id="rollup-deployment"></span>
	= Rollup ~~Deployment~~ =

	Rollup deployment refers to the aggregation of multiple changes or patches into a single release. Instead of deploying every small change, they are bundled together and released as one comprehensive update.		Rollup deployment refers to the aggregation of multiple changes or patches into a single release. Instead of deploying every small change, they are bundled together and released as one comprehensive update.
Line 57:		Line 47:

	Choosing the right deployment strategy depends on the nature of the application, the infrastructure, the team's capabilities, and the risk appetite of the business. Each method has its merits, and some teams might even employ a combination of these strategies to harness the collective benefits. Regardless of the approach, the primary goal remains consistent: delivering high-quality software changes to users with minimal disruption and risk.		Choosing the right deployment strategy depends on the nature of the application, the infrastructure, the team's capabilities, and the risk appetite of the business. Each method has its merits, and some teams might even employ a combination of these strategies to harness the collective benefits. Regardless of the approach, the primary goal remains consistent: delivering high-quality software changes to users with minimal disruption and risk.
	~~<!-- From bodyContent 1543219.mraw -->~~

	[[Category:Devops definitions]]		[[Category:Devops definitions]]

Maintenance script: Added category Devops definitions

2025-10-19T17:51:08Z

Added category Devops definitions

← Older revision		Revision as of 18:51, 19 October 2025
Line 59:		Line 59:
	<!-- From bodyContent 1543219.mraw -->		<!-- From bodyContent 1543219.mraw -->

			[[Category:Devops definitions]]

Maintenance script: Maintenance script moved page UserDocumentation:Knowledge Central/KC IT/Devops definitions/deployment methodologies to Deployment methodologies: Cleaned title and categorized

2025-10-19T17:51:08Z

Maintenance script moved page UserDocumentation:Knowledge Central/KC IT/Devops definitions/deployment methodologies to Deployment methodologies: Cleaned title and categorized

← Older revision	Revision as of 18:51, 19 October 2025
(No difference)

imported>Unknown user at 06:47, 21 April 2025

2025-04-21T06:47:30Z

← Older revision		Revision as of 07:47, 21 April 2025
Line 1:		Line 1:
			Modern deployment methodologies aim to reduce risks associated with releasing new software versions, ensuring that users have a seamless experience and any negative impact from changes is minimized. The principal deployment strategies are:

			<span id="ab-testing-or-split-testing"></span>
			= A/B Testing (or split testing) =

			A/B testing involves deploying two different versions of an application feature to compare their performance directly. Typically, one version (A) represents the current iteration, while the other (B) embodies the new change. Users are randomly assigned to one of the versions, and their interaction is monitored to determine which version performs better in terms of user experience, conversion rates, or other KPIs.

			Benefits:

			* '''Direct comparison''': You can compare two variations head-to-head in a real-world environment.
			* '''Data-driven decisions''': Decisions about feature releases or changes are based on actual user data.
			* '''Risk reduction''': If version B performs poorly, only a subset of users is affected.

			<span id="feature-flags-or-feature-toggles"></span>
			= Feature flags (or feature toggles) =

			Feature flags allow developers to toggle a feature on or off without having to redeploy the code. They provide granular control over feature releases, letting teams release a feature to specific user groups or environments.

			Benefits:

			* '''Gradual rollout''': Release new features gradually to specific users or environments.
			* '''Safe failover''': If an issue arises, the feature can be quickly disabled without a full rollback or redeploy.
			* '''Environment consistency''': The same codebase runs in all environments, ensuring consistency.

			<span id="blue-green-deployment"></span>
			= Blue-Green Deployment =

			In Blue-Green Deployment, two environments (Blue and Green) are maintained. At any given time, one environment (say Blue) is live and serving all production traffic. When a new version needs deployment, it's released to the other environment (Green). Once everything is tested and confirmed to work, the traffic is switched to Green, making it the new live environment.

			Benefits:

			* '''Zero downtime''': As one environment is always live, users experience no downtime during deployments.
			* '''Instant rollback''': If issues are detected, traffic can be immediately routed back to the old environment.
			* '''Isolated testing''': The non-live environment provides an exact replica for testing before going live.

			<span id="canary-deployment"></span>
			= Canary deployment =

			Named after the "canary in a coal mine" analogy, this strategy involves releasing the new version to a small subset of users before rolling it out to everyone. Feedback from this 'canary' group determines whether the new release is stable enough for a broader audience.

			Benefits:

			* '''Risk minimization''': Initial exposure to a limited user group reduces potential widespread impact.
			* '''Real-world feedback''': Gaining insights from actual users can help identify issues that might not appear in staging environments.
			* '''Gradual scale''': If the canary group doesn't report issues, the release is gradually scaled to more users.

			<span id="rollup-deployment"></span>
			= Rollup Deployment =

			Rollup deployment refers to the aggregation of multiple changes or patches into a single release. Instead of deploying every small change, they are bundled together and released as one comprehensive update.

			Benefits:

			* '''Reduced deployment frequency''': By aggregating changes, there are fewer deployments, reducing potential disruptions.
			* '''Consolidated testing''': Testing efforts can focus on a single, larger release instead of multiple smaller ones.
			* '''Predictability''': Scheduling and managing releases can be more predictable as they're done in larger, less frequent batches.

			Choosing the right deployment strategy depends on the nature of the application, the infrastructure, the team's capabilities, and the risk appetite of the business. Each method has its merits, and some teams might even employ a combination of these strategies to harness the collective benefits. Regardless of the approach, the primary goal remains consistent: delivering high-quality software changes to users with minimal disruption and risk.
	<!-- From bodyContent 1543219.mraw -->		<!-- From bodyContent 1543219.mraw -->

imported>Unknown user at 06:47, 21 April 2025

2025-04-21T06:47:30Z

← Older revision	Revision as of 07:47, 21 April 2025
(No difference)

imported>Unknown user at 06:47, 21 April 2025

2025-04-21T06:47:30Z

New page