Book Image

Automating DevOps with GitLab CI/CD Pipelines

By : Christopher Cowell, Nicholas Lotz, Chris Timberlake
Book Image

Automating DevOps with GitLab CI/CD Pipelines

By: Christopher Cowell, Nicholas Lotz, Chris Timberlake

Overview of this book

Developers and release engineers understand the high stakes involved in building, packaging, and deploying code correctly. Ensuring that your code is functionally correct, fast, and secure is a time-consuming and complex task. Code implementation, development, and deployment can be conducted efficiently using GitLab CI/CD pipelines. Automating DevOps with GitLab CI/CD Pipelines begins with the basics of Git and GitLab, showing how to commit and review code. You’ll learn to set up GitLab Runners for executing and autoscaling CI/CD pipelines and creating and configuring pipelines for many software development lifecycle steps. You'll also discover where to find pipeline results in GitLab, and how to interpret those results. Through the course of the book, you’ll become well-equipped with deploying code to different environments, advancing CI/CD pipeline features such as connecting GitLab to a Kubernetes cluster and using GitLab with Terraform, triggering pipelines and improving pipeline performance and using best practices and troubleshooting tips for uncooperative pipelines. In-text examples, use cases, and self-assessments will reinforce the important CI/CD, GitLab, and Git concepts, and help you prepare for interviews and certification exams related to GitLab. By the end of this book, you'll be able to use GitLab to build CI/CD pipelines that automate all the DevOps steps needed to build and deploy high-quality, secure code.
Table of Contents (18 chapters)
1
Part 1 Getting Started with DevOps, Git, and GitLab
6
Part 2 Automating DevOps Stages with GitLab CI/CD Pipelines
11
Part 3 Next Steps for Improving Your Applications with GitLab

Syncing local and remote copies of repositories

Git can be a useful tool for solo developers, but it’s most often used within a team of developers. As we’ve already discussed, Git’s distributed architecture means that every developer on the team has a complete copy of the project’s repository, including all its commits, commit messages, branches, and all the other data and metadata that is included in a repository. Keeping these repositories synced, so that they all have the same information in them, is critically important. If my copy of the repository and your copy of the repository contain different files or different edits to the same files, then I can’t see what work you’ve done and vice versa. And if my copy of the repository doesn’t contain the branches that you’re adding commits to, I can’t review and approve your work. Synchronizing repositories isn’t an automatic process: it involves active participation...