You’re reading the free preview.Unlock every conversation for €2.99
FreeFree previewChapter 10
Chapter 10 · Free preview
CI/CD: The Assembly Line
What you will understand
- Describe a CI/CD pipeline with build, test and deploy stages
- Explain the difference between continuous integration, delivery and deployment
- Compare blue-green, canary and rolling deployments
- Describe how Terraform manages infrastructure as code
- Explain why secrets don’t belong in code and how to manage them safely
Written by EduVerse for this preview; the slides below are the book’s own words.
Slides from the chapter
Each slide is a passage from the book with the figure or listing it talks about. Swipe, use the arrow keys or the buttons.
Slide 1 of 4
Continuous Integration: No More Integration Hell
10.2 · p. 216
Conversation from The Software Realm, Decoded
Chapter 10 · 10.2 Continuous Integration: No More Integration Hell · p. 216
Senior developer
Let me tell you about Integration Hell.
10.2.1 The Integration Hell Story
Senior developer
Before CI, teams worked like this:
- Developer A works on feature for 2 weeks on their branch
- Developer B works on different feature for 2 weeks on their branch
- Developer C works on another feature for 2 weeks on their branch
- Friday comes: “Let’s merge everything!”
- 500 merge conflicts
- Tests break in mysterious ways
- Nothing works together, weekend ruined trying to integrate
Peter
That sounds terrible.
Senior developer
It was. That’s Integration Hell. The longer you wait to integrate, the more painful it gets.
What the book shows with it
Figure from The Software Realm, Decoded
Chapter 10 · 10.2.2 The CI Solution · p. 216
Senior developer
Continuous Integration means: integrate constantly, not at the end.
Explore this figure
Pick one to highlight it and read what the book says about it.
Other labels in the figure (7)
Description
Comparison diagram: under 'Old Way (Big Bang)', three boxes 'Dev A', 'Dev B' and 'Dev C', each '(2 weeks)', point with red arrows into one box, 'Integration Hell!'. Below, under 'CI Way (Continuous)', a row of five 'Commit' boxes is labelled 'Small, frequent integrations'.
Description written by EduVerse; the figure itself is from the book.
The CI Pipeline: Your Assembly Line
10.2.3 · p. 217
Figure from The Software Realm, Decoded
Chapter 10 · 10.2.3 The CI Pipeline: Your Assembly Line · p. 217
Senior developer
Here’s what happens automatically every time you push code:
Explore this figure
Pick one to highlight it and read what the book says about it.
Other labels in the figure (10)
Description
Pipeline: five boxes linked left to right by arrows: '1. Commit' ('Push to Git'), '2. Build' ('Compile code'), '3. Test' ('Run tests'), '4. Package' ('Create artifact') and 'Result' ('Pass or Fail').
Description written by EduVerse; the figure itself is from the book.
The Right Balance
10.2.10 · p. 220
Conversation from The Software Realm, Decoded
Chapter 10 · 10.2.10 The Right Balance · p. 220
Peter
So fast tests should be the foundation, with just a few slow comprehensive tests on top?
Senior developer
Perfect! You want quick feedback. Most bugs should be caught by fast unit tests.
What the book shows with it
Figure from The Software Realm, Decoded
Chapter 10 · 10.2.10 The Right Balance · p. 221
Explore this table
Pick one to highlight it and read what the book says about it.
Other cells in the table (14)
Description
Table: 'Testing Strategy: The Pyramid' lists test types with their characteristics. 'E2E Tests' are few (10%), take minutes, are expensive and can be flaky; 'Integration Tests' are moderate (20%), take seconds, cost moderately and are usually stable; 'Unit Tests' are many (70%), take milliseconds, are cheap and reliable.
Description written by EduVerse; the figure itself is from the book.
Deployment Strategies
10.3.2 · p. 224
Conversation from The Software Realm, Decoded
Chapter 10 · 10.3.2 Deployment Strategies · p. 224
Peter
So you test with real users but limit the blast radius?
Senior developer
Exactly! If something breaks, only 10% of users affected (or less, since not all users trigger the broken feature). Much safer than all-or-nothing.
Peter
But how do I actually know if the canary is healthy? You said ’monitor metrics’, what metrics?
Senior developer
Good question. That’s where observability comes in. You need to track error rates, response times, and resource usage in real-time. We’ll cover that in detail next, how to actually see what’s happening in production.
What the book shows with it
Figure from The Software Realm, Decoded
Chapter 10 · 10.3.2 Deployment Strategies · p. 224
Senior developer
Test new version with small percentage of traffic.
Explore this figure
Pick one to highlight it and read what the book says about it.
Other labels in the figure (9)
Description
Flow diagram, canary deployment: 'Users' (100%) point down to a 'Load Balancer', which splits traffic with arrows marked '90%' to 'v1' ('9 instances') on the left and '10%' to 'v2 Canary' ('1 instance') on the right.
Description written by EduVerse; the figure itself is from the book.
Slide 1 of 4
Try it yourself
A simulation built by EduVerse around this chapter. It runs in your browser; nothing is sent anywhere.
The full chapter
This preview shows 7 of the chapter’s 55 passages. The full chapter has:
- 8 sections
- 31 conversations
- 18 figures and tables
- 2 What They Say boxes
- 7 knowledge-check questions
Sections in this chapter
- 10.1The Assembly Line Problem
- 10.2Continuous Integration: No More Integration Hell
- 10.3Continuous Deployment: The Final Mile
- 10.4Infrastructure as Code
- 10.5GitOps: Git as the Source of Truth
- 10.6What You've Been Learning: DevOps
- 10.7Putting It All Together
- 10.8Peter's Takeaways