DevOps and Continuous Delivery

From BloomWiki
Revision as of 01:49, 25 April 2026 by Wordpad (talk | contribs) (BloomWiki: DevOps and Continuous Delivery)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

How to read this page: This article maps the topic from beginner to expert across six levels � Remembering, Understanding, Applying, Analyzing, Evaluating, and Creating. Scan the headings to see the full scope, then read from wherever your knowledge starts to feel uncertain. Learn more about how BloomWiki works ?

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[edit]

  • 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[edit]

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[edit]

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[edit]

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[edit]

Evaluating DevOps:

  1. The "Burnout" Risk: Does "Deploying every hour" put too much pressure on developers?
  2. Security (DevSecOps): If we move "Fast," do we accidentally leave "Doors open" for hackers?
  3. 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").
  4. Complexity: Is a CI/CD pipeline "Too complex" for a small project? (The "Over-automation" trap).

Creating[edit]

Future Frontiers:

  1. AIOps: Using AI to "Predict" a server failure before it happens and automatically move the data to a safe location.
  2. 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).
  3. NoOps: The dream of an environment where everything is so automated that you don't need an Operations team at all.
  4. Sustainable DevOps: Algorithms that automatically "Turn off" half the internet's servers at night to save energy when users are asleep.