DevOps and Continuous Delivery - Revision history

Wordpad: BloomWiki: DevOps and Continuous Delivery

2026-04-25T01:49:57Z

BloomWiki: DevOps and Continuous Delivery

← Older revision		Revision as of 01:49, 25 April 2026
Line 1:		Line 1:
			<div style="background-color: #4B0082; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
	{{BloomIntro}}		{{BloomIntro}}
	DevOps and Continuous Delivery (CD) are the cultural and technical practices that allow software companies to release updates "Every Day" rather than "Every Year." In the old world, the "Developers" (who build the code) and the "Operations" (who run the servers) were enemies. Developers wanted to change things; Operations wanted to keep things stable. DevOps "Bridges the gap" by automating the entire process—from writing code to testing it, to deploying it to millions of users. It is the "End of the Big Release"—the transition from software as a "Boxed Product" to software as a "Living, Breathing Service."		DevOps and Continuous Delivery (CD) are the cultural and technical practices that allow software companies to release updates "Every Day" rather than "Every Year." In the old world, the "Developers" (who build the code) and the "Operations" (who run the servers) were enemies. Developers wanted to change things; Operations wanted to keep things stable. DevOps "Bridges the gap" by automating the entire process—from writing code to testing it, to deploying it to millions of users. It is the "End of the Big Release"—the transition from software as a "Boxed Product" to software as a "Living, Breathing Service."
			</div>

	== Remembering ==		__TOC__

			<div style="background-color: #000080; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
			== <span style="color: #FFFFFF;">Remembering</span> ==
	* '''DevOps''' — A set of practices that combines software development (Dev) and IT operations (Ops) to shorten the systems development life cycle.		* '''DevOps''' — A set of practices that combines software development (Dev) and IT operations (Ops) to shorten the systems development life cycle.
	* '''CI/CD (Continuous Integration / Continuous Delivery)''' — The automated pipeline that builds, tests, and deploys code every time a change is made.		* '''CI/CD (Continuous Integration / Continuous Delivery)''' — The automated pipeline that builds, tests, and deploys code every time a change is made.
Line 13:		Line 18:
	* '''Blue-Green Deployment''' — A technique where you have two identical environments; you update the "Green" one and then instantly switch the traffic to it.		* '''Blue-Green Deployment''' — A technique where you have two identical environments; you update the "Green" one and then instantly switch the traffic to it.
	* '''Site Reliability Engineering (SRE)''' — The Google-founded practice of using software engineers to manage IT operations.		* '''Site Reliability Engineering (SRE)''' — The Google-founded practice of using software engineers to manage IT operations.
			</div>

	== Understanding ==		<div style="background-color: #006400; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
			== <span style="color: #FFFFFF;">Understanding</span> ==
	DevOps is understood through '''Automation''' and '''Feedback Loops'''.		DevOps is understood through '''Automation''' and '''Feedback Loops'''.

Line 36:		Line 43:

	'''The 'Shift Left' Principle''': The practice of moving testing and security "Left" in the timeline (earlier in the process) so that bugs are caught while the developer is still writing the code.		'''The 'Shift Left' Principle''': The practice of moving testing and security "Left" in the timeline (earlier in the process) so that bugs are caught while the developer is still writing the code.
			</div>

	== Applying ==		<div style="background-color: #8B0000; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
			== <span style="color: #FFFFFF;">Applying</span> ==
	'''Modeling 'The CI/CD Pipeline' (The path of a single line of code):'''		'''Modeling 'The CI/CD Pipeline' (The path of a single line of code):'''
	<syntaxhighlight lang="python">		<syntaxhighlight lang="python">
Line 64:		Line 73:
	: '''The DORA Metrics''' → The four key measurements (Deployment Frequency, Lead Time, Change Failure Rate, Time to Restore) used to tell if a company is "Elite" at DevOps.		: '''The DORA Metrics''' → The four key measurements (Deployment Frequency, Lead Time, Change Failure Rate, Time to Restore) used to tell if a company is "Elite" at DevOps.
	: '''Chaos Engineering''' → The practice of "Intentionally breaking things" (like unplugging a server) to make sure the system is resilient enough to handle it.		: '''Chaos Engineering''' → The practice of "Intentionally breaking things" (like unplugging a server) to make sure the system is resilient enough to handle it.
			</div>

	== Analyzing ==		<div style="background-color: #8B4500; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
			== <span style="color: #FFFFFF;">Analyzing</span> ==
	{\| class="wikitable"		{\| class="wikitable"
	\|+ Old Ops vs. DevOps		\|+ Old Ops vs. DevOps
Line 80:		Line 91:

	'''The Concept of "Immutable Infrastructure"''': Analyzing why we don't "Fix" servers anymore. In DevOps, if a server has a problem, you don't log in and fix it. You "Kill" the server and spawn a brand new one from the "Code Template." This ensures that every server in your network is exactly the same.		'''The Concept of "Immutable Infrastructure"''': Analyzing why we don't "Fix" servers anymore. In DevOps, if a server has a problem, you don't log in and fix it. You "Kill" the server and spawn a brand new one from the "Code Template." This ensures that every server in your network is exactly the same.
			</div>

	== Evaluating ==		<div style="background-color: #483D8B; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
			== <span style="color: #FFFFFF;">Evaluating</span> ==
	Evaluating DevOps:		Evaluating DevOps:
	# '''The "Burnout" Risk''': Does "Deploying every hour" put too much pressure on developers?		# '''The "Burnout" Risk''': Does "Deploying every hour" put too much pressure on developers?
Line 87:		Line 100:
	# '''Human Skill''': Is DevOps "Replacing" IT jobs with code? (It is shifting them—the job is no longer "Fixing a server," but "Writing the code that fixes the server").		# '''Human Skill''': Is DevOps "Replacing" IT jobs with code? (It is shifting them—the job is no longer "Fixing a server," but "Writing the code that fixes the server").
	# '''Complexity''': Is a CI/CD pipeline "Too complex" for a small project? (The "Over-automation" trap).		# '''Complexity''': Is a CI/CD pipeline "Too complex" for a small project? (The "Over-automation" trap).
			</div>

	== Creating ==		<div style="background-color: #2F4F4F; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">
			== <span style="color: #FFFFFF;">Creating</span> ==
	Future Frontiers:		Future Frontiers:
	# '''AIOps''': Using AI to "Predict" a server failure before it happens and automatically move the data to a safe location.		# '''AIOps''': Using AI to "Predict" a server failure before it happens and automatically move the data to a safe location.
Line 98:		Line 113:
	[[Category:Software Engineering]]		[[Category:Software Engineering]]
	[[Category:Technology]]		[[Category:Technology]]
			</div>

Wordpad: BloomWiki: DevOps and Continuous Delivery

2026-04-23T15:02:12Z

BloomWiki: DevOps and Continuous Delivery

New page

{{BloomIntro}}
DevOps and Continuous Delivery (CD) are the cultural and technical practices that allow software companies to release updates "Every Day" rather than "Every Year." In the old world, the "Developers" (who build the code) and the "Operations" (who run the servers) were enemies. Developers wanted to change things; Operations wanted to keep things stable. DevOps "Bridges the gap" by automating the entire process—from writing code to testing it, to deploying it to millions of users. It is the "End of the Big Release"—the transition from software as a "Boxed Product" to software as a "Living, Breathing Service."

== Remembering ==
* '''DevOps''' — A set of practices that combines software development (Dev) and IT operations (Ops) to shorten the systems development life cycle.
* '''CI/CD (Continuous Integration / Continuous Delivery)''' — The automated pipeline that builds, tests, and deploys code every time a change is made.
* '''Infrastructure as Code (IaC)''' — The practice of managing servers and networks using "Code" rather than clicking buttons in a dashboard.
* '''Deployment Pipeline''' — The automated sequence of steps a piece of code must pass through to reach the user.
* '''Microservices''' — Small, independent pieces of an app that can be updated separately (a key enabler of DevOps).
* '''Containerization (Docker)''' — Packaging an app with everything it needs to run, so it works exactly the same on a developer's laptop as it does in the cloud.
* '''Orchestration (Kubernetes)''' — The software that "Manages" thousands of containers, automatically fixing them if they crash.
* '''Monitoring / Observability''' — The "Dashboard" that tells developers exactly how their app is performing for real users.
* '''Blue-Green Deployment''' — A technique where you have two identical environments; you update the "Green" one and then instantly switch the traffic to it.
* '''Site Reliability Engineering (SRE)''' — The Google-founded practice of using software engineers to manage IT operations.

== Understanding ==
DevOps is understood through '''Automation''' and '''Feedback Loops'''.

'''1. The "Wall of Confusion"''':
In traditional companies, developers "Toss their code over the wall" to the operations team and say: "It worked on my machine; good luck!"
* DevOps breaks this wall.
* Developers are now responsible for how their code "Runs" in the real world.
* This forces them to write code that is easy to monitor and fix.

'''2. The Pipeline (Automation)''':
The goal of DevOps is to "Automate everything that can be automated."
* **Commit**: Developer saves code.
* **Build**: The computer automatically compiles the code.
* **Test**: Thousands of automated tests run in seconds.
* **Deploy**: If tests pass, the code is automatically sent to the servers.
* This removes "Human Error" from the release process.

'''3. The Feedback Loop''':
Instead of waiting for users to "Call and complain," DevOps uses "Real-time Monitoring."
* If the app gets 1% slower after an update, the DevOps system sees it instantly and can "Roll back" to the old version automatically.

'''The 'Shift Left' Principle''': The practice of moving testing and security "Left" in the timeline (earlier in the process) so that bugs are caught while the developer is still writing the code.

== Applying ==
'''Modeling 'The CI/CD Pipeline' (The path of a single line of code):'''
<syntaxhighlight lang="python">
def run_pipeline(code_change):
"""
Simulates the stages of a DevOps pipeline.
"""
stages = ["BUILD", "UNIT_TEST", "SECURITY_SCAN", "DEPLOY_TO_STAGING", "DEPLOY_TO_PROD"]

for stage in stages:
# Simulate a 95% success rate for each stage
import random
if random.random() > 0.05:
print(f"STAGE: {stage} ... [PASSED]")
else:
return f"FAILURE at {stage}: Rolling back changes!"

return "SUCCESS: Update is live for 100% of users."

print(run_pipeline("Fix for Login Button"))
</syntaxhighlight>

; DevOps Landmarks
: '''The 'Phoenix Project'''' → The famous novel that explains DevOps principles through a story about a failing IT department.
: '''Amazon's 'Every 11.6 Seconds' (2011)''' → The moment the world realized the power of DevOps: Amazon announced they were deploying new code on average every 11 seconds.
: '''The DORA Metrics''' → The four key measurements (Deployment Frequency, Lead Time, Change Failure Rate, Time to Restore) used to tell if a company is "Elite" at DevOps.
: '''Chaos Engineering''' → The practice of "Intentionally breaking things" (like unplugging a server) to make sure the system is resilient enough to handle it.

== Analyzing ==
{| class="wikitable"
|+ Old Ops vs. DevOps
! Feature !! Traditional Ops !! DevOps / SRE
|-
| Update Frequency || Every few months || Every few hours / minutes
|-
| Goal || Stability (Don't change anything) || Velocity (Change everything safely)
|-
| Scaling || Manual (Buy a new server) || Automated (Scaling groups)
|-
| Reliability || High-cost hardware || High-quality software
|}

'''The Concept of "Immutable Infrastructure"''': Analyzing why we don't "Fix" servers anymore. In DevOps, if a server has a problem, you don't log in and fix it. You "Kill" the server and spawn a brand new one from the "Code Template." This ensures that every server in your network is exactly the same.

== Evaluating ==
Evaluating DevOps:
# '''The "Burnout" Risk''': Does "Deploying every hour" put too much pressure on developers?
# '''Security (DevSecOps)''': If we move "Fast," do we accidentally leave "Doors open" for hackers?
# '''Human Skill''': Is DevOps "Replacing" IT jobs with code? (It is shifting them—the job is no longer "Fixing a server," but "Writing the code that fixes the server").
# '''Complexity''': Is a CI/CD pipeline "Too complex" for a small project? (The "Over-automation" trap).

== Creating ==
Future Frontiers:
# '''AIOps''': Using AI to "Predict" a server failure before it happens and automatically move the data to a safe location.
# '''GitOps''': Using your code repository (Git) as the "Source of Truth" for your entire infrastructure (e.g., if you change the 'ServerCount' in a text file, the servers appear instantly).
# '''NoOps''': The dream of an environment where everything is so automated that you don't need an Operations team at all.
# '''Sustainable DevOps''': Algorithms that automatically "Turn off" half the internet's servers at night to save energy when users are asleep.

[[Category:Computer Science]]
[[Category:Software Engineering]]
[[Category:Technology]]