This chapter covers the topics in the Cloud native application delivery section of the exam. The topics account for 8% of the overall exam.
The chapter is divided as follows.
Cloud native application delivery is often referred to as code to cloud and code to production, and we usually automate it with continuous integration (CI) and continuous delivery (CD) pipelines as well as GitOps tools. We’ll talk more about all of this later in the chapter, but for now you should know the major automation steps.
Automating these steps enables fast, frequent, and high-quality releases.
Finally, release is jargon for rolling out a new version of an application or an environment. For example, updating an application from version 1.1 to version 1.2 is accomplished via a release. We often use the terms rollout, update, and release to mean the same thing.
CI/CD is an acronym for continuous integration, continuous delivery. It’s a set of tools and processes that automates the building, testing, and provisioning of software. It enables frequent reliable releases and is an integral part of the wider DevOps movement.
As the acronym suggests, CI/CD is two separate processes.
CI automates the process of building and testing software changes. It usually involves developers frequently merging code to a central repository where it’s built and subjected to extensive tests. The building and testing must be fully automated and are highly effective at identifying issues before they’re released into live environments. The whole process is automated and ensures only high-quality code is passed to the CD process.
CD automates the later process of releasing that high-quality code into live environments such as dev, test, and production. It’s often triggered...
The idea of GitOps became popular in 2017 following Alexi Richardson’s blog post on the Weaveworks website titled Operations by Pull Request.
At a high-level, it takes the battle-tested DevOps practices we’ve been using for years in software development and brings them to the world of infrastructure and Kubernetes. If you’ve just read the section on CI/CD, GitOps builds on these by adding version control and pull requests.
Keeping it high-level, you describe the desired state of your infrastructure in configuration files that you store in a Git repo for version control. Every time you make a change to your environment you check the files out of Git, update them with your changes, and submit a Pull Request (PR) to merge the changes into the repo. As soon as the PR is merged, the process of deploying the changes to your live environment kicks in.
Although there are lots of GitOps tools, such as Argo, Flux and Jenkins X, GitOps is actually a collection of...
In this chapter, you learned that CI/CD automates the building, testing, and deployment of software and infrastructure. CI deals with automating the early steps of building and testing code, and then publishing it to repositories. CD takes the built and tested artefact and automates the process of deploying it to live environments. GitOps builds on this by adding version control, pull requests, and approvals that trigger the CD process. GitOps is particularly powerful in Kubernetes environments where everything is declaratively described in YAML configuration files that are used to configure the environment. Popular GitOps tools include Argo, Flux, and Jenkins X.
See Appendix A for answers.
1. Which of the following terms refers to the process of updating an application from version 1.1 to 1.2? Choose all correct answers.
2. Which of the following is a description of continuous integration (CI)?
3. What is a goal of continuous integration (CI)?
© 2023 Packt Publishing Limited All Rights Reserved
