Grokking Continuous Delivery

Description

Grokking Continuous Delivery MEAP V06 Copyright Welcome Brief contents Chapter 1: Welcome 1.1 Do you need Continuous Delivery? 1.2 Why Continuous Delivery? 1.3 Continuous Word Soup 1.4 Continuous Delivery (CD) 1.5 Integration 1.6 Continuous Integration 1.7 What do we deliver? 1.8 Delivery 1.9 Continuous Delivery/Deployment 1.10 Elements of Continuous Delivery 1.11 Conclusion 1.12 Summary 1.13 Up next . . . Chapter 2: A basic pipeline 2.1 Cat Picture Website 2.2 Cat Picture Website Source Code 2.3 Cat Picture Website Pipelines 2.4 What’s a pipeline? What’s a task? 2.5 The basic tasks in a CD pipeline 2.6 Gates and Transformations 2.7 CD: Gates and Transformations 2.8 Cat Picture Website Service Pipeline 2.9 Running the pipeline 2.10 Running once a day 2.11 Trying Continuous Integration 2.12 Using notifications 2.13 Scaling manual effort 2.14 Automation with webhooks 2.15 Automation with webhooks 2.16 Don’t push changes when broken 2.17 Cat Picture Website CD 2.18 What’s in a name? 2.19 Conclusion 2.20 Summary 2.21 Up next . . . Chapter 3: Version control is the only way to roll 3.1 Sasha and Sarah’s start-up 3.2 All kinds of data 3.3 Source and software 3.4 Repositories and versions 3.5 Continuous Delivery and version control 3.6 Git and GitHub 3.7 An initial commit - with a bug! 3.8 Breaking main 3.9 Are we doing Continuous Delivery? 3.10 Keep version control releasable 3.11 Trigger on changes to version control 3.12 Triggering the User Service Pipeline 3.13 Building the User Service 3.14 The User Service in the cloud 3.15 Connecting to the RandomCloud database 3.16 Managing the User Service 3.17 The User Service outage 3.18 Outsmarted by automation 3.19 What’s the source of truth? 3.20 Version Control and sensitive data 3.21 User Service config as code 3.22 Hard-coded data 3.23 Configuring Deployaker 3.24 Config as code 3.25 Rolling out software and config changes 3.26 Conclusion 3.27 Summary 3.28 Up next . . . Chapter 4: Use linting effectively 4.1 Becky and Super Game Console 4.2 Linting to the rescue! 4.3 The lowdown on linting 4.4 The tale of pylint and many many issues 4.5 Legacy code: using a systematic approach 4.6 Step 1: Configure against coding standards 4.7 Step 2: Establish a baseline 4.8 Step 3: Enforce at submission time 4.9 Step 3: Enforce at submission time 4.10 Step 4: Divide and conquer 4.11 Isolation: Not everything should be fixed 4.12 Enforcing isolation 4.13 Not all problems are created equal 4.14 Types of linting issues 4.15 Bugs first, style later 4.16 Jumping through the hoops 4.17 Legacy code vs the ideal 4.18 Conclusion 4.19 Summary 4.20 Up next . . . Chapter 5: Dealing with noisy tests 5.1 Continuous Delivery and tests 5.2 Ice Cream for All outage 5.3 Signal vs. noise 5.4 Noisy successes 5.5 How failures become noise 5.6 Going from noise to signal 5.7 Getting to green 5.8 Another outage! 5.9 Passing tests can be noisy 5.10 Fixing test failures 5.11 Ways of failing: flakes 5.12 Reacting to failures 5.13 Fixing the test: change the code or the test? 5.14 The dangers of retries 5.15 Retrying revisited 5.16 Why do we retry? 5.17 Get to green and stay green 5.18 Conclusion 5.19 Summary 5.20 Up next . . . Chapter 6: Speeding up slow test suites 6.1 Dog Picture Website 6.2 When simple is too simple 6.3 New engineer tries to submit code 6.4 Tests and Continuous Delivery 6.5 Diagnosis: too slow 6.6 The test pyramid 6.7 Fast tests first 6.8 Two pipelines 6.9 Getting the right balance 6.10 Changing the pyramid 6.11 Safely adjusting tests 6.12 Test Coverage 6.13 Enforcing test coverage 6.14 Test coverage in the pipeline 6.15 Moving tests in the pyramid with coverage 6.16 What to move down the pyramid? 6.17 Legacy tests and FUD 6.18 Running tests in parallel 6.19 When can tests run in parallel? 6.20 Updating the pipelines 6.21 Still too slow! 6.22 Test sharding aka parallel++ 6.23 How to shard 6.24 More complex sharding 6.25 Sharded pipeline 6.26 Sharding the browser tests 6.27 Sharding in the pipeline 6.28 Dog Picture Website’s pipelines 6.29 Conclusion 6.30 Summary 6.31 Up next . . . Chapter 7: Give the right signals at the right times 7.1 CoinExCompare 7.2 Lifecycle of a change 7.3 CI before and after merge 7.4 Timeline of a change’s bugs 7.5 CI only before merging misses bugs 7.6 A tale of two graphs: default to seven days 7.7 A tale of two graphs: default to thirty days 7.8 Conflicts aren’t always caught 7.9 What about the unit tests? 7.10 Pull request triggering still lets bugs sneak in 7.11 CI before AND after merge 7.12 Option 1: Run CI periodically 7.13 Setting up periodic CI 7.14 Option 2: Require branch to be up to date 7.15 Option 2: At what cost? 7.16 Option 3: Automated merge CI 7.17 Running CI with the latest main 7.18 Merge Events 7.19 Merge queues 7.20 Merge queue for CoinExCompare 7.21 Where can bugs still happen? 7.22 Flakes and pull request triggered CI 7.23 Catching flakes with periodic tests 7.24 Bugs and building 7.25 CI vs. build and deploy 7.26 Build and deploy with the same logic 7.27 Improved CI pipeline with building 7.28 Timeline of a change revisited 7.29 Conclusion 7.30 Summary 7.31 Up next . . . Chapter 8: Easy delivery starts with version control 8.1 Meanwhile at Watch Me Watch 8.2 The DORA metrics 8.3 Velocity at Watch Me Watch 8.4 Lead time for changes 8.5 Watch Me Watch and elite perfomers 8.6 Increasing velocity at Watch Me Watch 8.7 Integrating with AllCatsAllTheTime 8.8 Incremental feature delivery 8.9 Commiting skipped tests 8.10 Code review and “incomplete” code 8.11 Keeping up the momentum 8.12 Committing work in progress code 8.13 Reviewing work in progress code 8.14 Meanwhile, back at the end to end tests 8.15 Seeing the benefits 8.16 Decreasing lead time for changes 8.17 Continuing AllCatsAllTheTime 8.18 Deployment windows and code freezes 8.19 Increased velocity 8.20 Conclusion 8.21 Summary 8.22 Up next . . .