fix numbers

chapters/04-cicd-best-practices.md

@@ -48,9 +48,9 @@ Today a service like Semaphore provides features like:
 
 There is no longer a reason not to automate the entire software delivery process.
 
-## 3.1 General Principles
+## 3.2 General Principles
 
-### 3.1.1 Architect the System in a Way That Supports Iterative Releases
+### 3.2.1 Architect the System in a Way That Supports Iterative Releases
 
 The most common reason why a system is unable to sustain frequent iterative releases is tight coupling between components.
 
@@ -66,7 +66,7 @@ A loosely coupled system is conservative in the design of communication between
 
 Metrics and monitoring are also an essential enabler of iterative development. Being able to detect issues in real-time gives us the confidence to make changes, knowing that we can quickly recover from any error.
 
-### 3.1.2 You Build It, You Run It
+### 3.2.2 You Build It, You Run It
 
 In the seminal 2006 interview to ACM[^vogels-acm], Werner Vogels, Amazon CTO, pioneered the mindset of *you build it, you run it*. The idea is that developers should be in direct contact with the operation of their software, which, in turn, puts them in close contact with customers.
 
@@ -83,7 +83,7 @@ It’s not rare that in newly formed teams there is no dedicated operations pers
 [^vogels-acm]: A Conversation with Werner Vogels, ACMQueue
   _[https://queue.acm.org/detail.cfm?id=1142065](https://www.youtube.com/watch?v=wW9CAH9nSLs)_
 
-### 3.1.3 Use Ephemeral Resources
+### 3.2.3 Use Ephemeral Resources
 
 There are three main reasons for using ephemeral resources to run your CI/CD pipeline.
 
@@ -93,7 +93,7 @@ Ephemeral resources help ensure that your tests run consistently. Cloud-based CI
 
 As we’ve seen in chapter 1, containers allow us to use one environment in development, CI/CD, and production. There’s no need to set up and maintain infrastructure or sacrifice environmental fidelity.
 
-### 3.1.4 Automate Everything
+### 3.2.4 Automate Everything
 
 It’s worth repeating: automate everything you can.
 
@@ -103,11 +103,11 @@ But if these conditions do not apply and you still think that your pipeline can
 
 Take a good look at your end-to-end process and uncover where you’re doing things manually out of habit. Make a plan to make any changes that may be needed, are automate it.
 
-## 3.2 Continuous Integration Best Practices
+## 3.3 Continuous Integration Best Practices
 
 Getting the continuous integration process right is a prerequisite for successful continuous delivery. Usually, when the CI process is fast and reliable, the leap to full CI/CD is not hard to make.
 
-### 3.2.1 Treat Master Build as If You’re Going to Make a Release at Any Time
+### 3.3.1 Treat Master Build as If You’re Going to Make a Release at Any Time
 
 Small, simple, frequent changes are a less risky way of building software in a team than making big, complex, rare changes. This implies that the team will make fewer mistakes by always being ready for release, not more.
 
@@ -123,7 +123,7 @@ Every test failure is a bug. It needs to be logged, investigated, and fixed. Ass
 
 The process of cleaning up the master build usually starts as being frustrating. But if you’re committed and stick to the process, over time, the pain goes away. One day you reach a stage when a failed test means there is a real bug. You don’t have to re-run the CI build to move on with your work. No one has to impose a code freeze. Days become productive again.
 
-### 3.2.2 Keep the Build Fast: Up to 10 Minutes
+### 3.3.2 Keep the Build Fast: Up to 10 Minutes
 
 Let’s take two development teams, both writing tests, as an example. Team A has a CI build that runs for about 3 minutes. Team B has a build that clocks at 45 minutes. They both use a CI service that runs tests on all branches. They both release reliable software in predictable cycles. But team A has the potential to build and release over 100 times in a day, while team B can do that up to 7 times. Are they both doing *continuous* integration?
 
@@ -158,7 +158,7 @@ There are a couple of tactics which you can employ to reduce CI build time:
 - **Test parallelization**: A large test suite is the most common reason why CI is slow. The solution is to distribute tests across as many parallel jobs as needed.
 - **Change detection**: Large test suites can be dramatically sped up by only testing code that has changed since the last commit.
 
-### 3.2.3 Build Only Once and Promote the Result Through the Pipeline
+### 3.3.3 Build Only Once and Promote the Result Through the Pipeline
 
 In the context of container-based services, this principle means building containers only once and then reusing the images throughout the pipeline.
 
@@ -179,7 +179,7 @@ To support such workflows, your CI system should be able to:
 
 These steps ensure that the build doesn’t change as it progresses through the system.
 
-### 3.2.4 Run Fast and Fundamental Tests First
+### 3.3.4 Run Fast and Fundamental Tests First
 
 On many occasions, you can get all the feedback from CI that you need without running the entire test suite.
 
@@ -223,7 +223,7 @@ In the pipeline above, backend and frontend tests run if code changed in the cor
 
 **Automatic cancelation of queued builds** can help in situations when you push some changes, only to realize that you have made a mistake. So you push a new revision immediately but would then need to wait for twice as long for feedback. Using automatic cancelations, you can get feedback on revisions that matter while skipping the intermediate ones.
 
-### 3.2.5 Minimize Feature Branches, Embrace Feature Flags
+### 3.3.5 Minimize Feature Branches, Embrace Feature Flags
 
 One of the reasons why Git overshadowed earlier version control systems like Subversion is that it made branching easy. This motivated developers to create and merge branches many times per day.
 
@@ -245,7 +245,7 @@ end
 
 So you don’t even load the related code unless the user is a developer working on it, or a small group of beta testers. No matter how unfinished the code is, nobody will be affected. So you can work on it in short iterations and make sure each iteration is well integrated with the system as a whole. Such integrations are much easier to deal with than a big-bang merge.
 
-### 3.2.6 Use CI to Maintain Your Code
+### 3.3.6 Use CI to Maintain Your Code
 
 If you’re used to working on monolithic applications, building microservices leads to an unfamiliar situation. Services often reach a stage of being done, as in no further work is necessary for the time being.
 
@@ -261,9 +261,9 @@ You can further support the quality of your code by incorporating in your CI pip
 
 And running them first, before unit tests.
 
-## 3.3 Continuous Delivery Best Practices
+## 3.4 Continuous Delivery Best Practices
 
-### 3.3.1 The CI/CD Pipeline is the Only Way to Deploy to Production
+### 3.4.1 The CI/CD Pipeline is the Only Way to Deploy to Production
 
 A CI/CD pipeline is a codified standard of quality and procedure for making a release. By rejecting any change that breaks any of the rules, the pipeline acts as a gatekeeper of quality. It protects the production environment from unverified code. It pushes the team to work in the spirit of continuous improvement.
 
@@ -273,7 +273,7 @@ It can be tempting to break this rule in cases of seemingly exceptional circumst
 
 Once it happens that the configuration and history of the CI/CD pipeline diverge from what teams do in reality, it’s difficult to re-establish the automation and the culture of quality. For this reason, it’s important to invest time in making the pipeline fast so that no one feels encouraged to skip it.
 
-### 3.3.2 Developers Can Deploy to Production-Like Staging Environments at a Push of a Button
+### 3.4.2 Developers Can Deploy to Production-Like Staging Environments at a Push of a Button
 
 An ideal CI/CD pipeline is almost invisible. Developers get feedback from tests without losing focus and deploy with a single command or button press. There’s no delay between intent and actualization. Anything that gets in the way of that ideal state is undesirable.
 
@@ -285,7 +285,7 @@ Developers who build containerized microservices need to have a staging Kubernet
 
 The deployment operation needs to be streamlined to a single command that is trivial to run and very unlikely to fail. A more complicated deployment sequence invites human and infrastructure errors that slow down the progress.
 
-### 3.3.3 Always Use the Same Environment
+### 3.4.3 Always Use the Same Environment
 
 Before containers, the realistic advice would be to make the pipeline, staging, and production as similar as possible. The goal is to ensure that the automated tests which we run in the CI/CD pipeline accurately reflect how the change would behave in production. The bigger the differences between staging and production, the higher is the chance of introducing bugs.
 

chapters/06-tutorial-semaphore.md

@@ -26,7 +26,7 @@ We'll learn about Semaphore's features as we go hands-on in this chapter.
 
 [^roi]: Whitepaper: The 41:1 ROI of Moving CI/CD to Semaphore (_[https://semaphoreci.com/resources/roi](https://semaphoreci.com/resources/roi?utm_source=ebook&utm_medium=pdf&utm_campaign=cicd-docker-kubernetes-semaphore)_)
 
-### 4.4.1 Creating a Semaphore Account
+### 4.4.2 Creating a Semaphore Account
 
 To get started with Semaphore:
 
@@ -36,7 +36,7 @@ To get started with Semaphore:
 - Semaphore will ask you to choose between a time-limited free trial with unlimited capacity, a free plan, and an open-source plan. This chapter will demonstrate a workflow using Semaphore's Docker Registry, which is available within a free trial or a paid account. However you can easily replace it with a free public registry like Docker Hub and implement the same workflow with an open source account.
 - Finally, you'll be greeted with a quick product tour.
 
-### 4.4.2 Creating a Semaphore Project For The Demo Repository
+### 4.4.3 Creating a Semaphore Project For The Demo Repository
 
 We assume that you have previously forked the demo project from _[https://github.com/semaphoreci-demos/semaphore-demo-cicd-kubernetes](https://github.com/semaphoreci-demos/semaphore-demo-cicd-kubernetes)_ to your GitHub account.
 
@@ -56,7 +56,7 @@ Click on *Continue to Workflow Setup*. Semaphore will ask you if you want to use
 
 Click on the option to configure the project from scratch.
 
-### 4.4.3 The Semaphore Workflow Builder
+### 4.4.4 The Semaphore Workflow Builder
 
 To make the process of creating projects easier, Semaphore provides starter workflows for popular frameworks and languages. Choose the "Build Docker" workflow and click on *Run this workflow*.
 
@@ -94,7 +94,7 @@ Jobs inherit their configuration from their parent block. All the jobs in a bloc
 
 Blocks run sequentially, once all the jobs in the block complete, the next block starts.
 
-### 4.4.4 The Continous Integration Pipeline
+### 4.4.5 The Continous Integration Pipeline
 
 We talked about the benefits of CI/CD in chapter 3. In the previous section, we created our very first pipeline. In this section, we’ll extend it with tests and a place to store the images.
 
@@ -232,7 +232,7 @@ docker push \
 
 This completes the setup of the CI pipeline.
 
-### 4.4.5 Your First Build
+### 4.4.6 Your First Build
 
 We’ve covered a lot of things in a few pages; here, we have the chance to pause for a little bit and try the CI pipeline. Click on the *Run the workflow* button on the top-right corner and then click on *Start*.