Packaging and Deploying Code

In the previous chapters, you learned how to use GitLab for source code management, as well as to set up CI/CD pipelines that build, test, and perform security scanning against the code you’ve checked in. You have hopefully now developed a confident understanding of both the infrastructure around GitLab CI/CD and the syntax used to author pipelines.

In this chapter, we will continue our journey through the stages of software development, focusing now on packaging and deploying code. We will use a combination of GitLab’s built-in features and common industry tools to deploy our code to an endpoint or environment. The goal is to answer the question, how do we make the application we have built and tested available to our users?

This chapter will introduce new vocabulary, adding to our knowledge of GitLab CI/CD syntax. It will also mention, and the examples will use, third-party tools such as Docker, as well as cloud service providers such...

Technical requirements

Like the previous chapters, you’ll get the most out of this chapter if you have an account on a GitLab instance (SaaS or self-managed). Moreover, the topics and examples in this chapter will increasingly focus on deploying to environments that live outside GitLab. The infrastructure tools that are referenced include the following:

• A server hosting GitLab (or GitLab.com)
• Self-hosted runners (or SaaS runners hosted on GitLab.com)
• Docker (also available on SaaS runners hosted on Gitlab.com)
• Kubernetes
• Cloud platform services (such as Amazon Web Services, Google Cloud Platform, or Heroku)

If you wish to minimize the amount of tooling you need to install and maintain yourself, we recommend using GitLab.com with SaaS runners. We also recommend creating an account on a cloud service platform if you wish to practice deploying to live or complex infrastructure. Just be aware of the potential charges when using these services.

...

Storing code in GitLab’s package registry for later re-use

As part of the goal of serving as a complete DevOps platform, GitLab includes the option to enable package and container registries in each project. The package registry supports hosting software packages and language packs in a variety of formats, and the container registry serves as a repository of purpose-built container images. These features allow teams to conveniently host, organize, and version-control completed builds alongside their source code. We will discuss the package and container registries in turn.

Locating GitLab’s container and package registries

GitLab projects technically support three types of built-in registries. They are package, container, and infrastructure registries that can be used to store completed code, whether for use by end users or other software projects. This book will focus on the package and container registries; the infrastructure registry is a recent addition to GitLab...

Storing code in GitLab’s container and package registries for later deployment

GitLab’s package and container registries are useful not only for making software available for users to download but also for storing packages and libraries for use in CI/CD pipelines, or for deployment to an environment. In this section, we will discuss how to programmatically interact with the registries via CI/CD jobs.

Using images from the container registry

In the previous section, we built a containerized version of our app and pushed the image to GitLab’s container registry. Recall that the CI/CD jobs we used to build the container image themselves run in containers, hence the reference to terms such as docker:stable and docker:dnd. In this example, we are pulling from a public container registry, that is, Docker Hub.

However, we can also pull container images we have pushed to GitLab’s container registry and use them as the basis for running our CI/CD jobs. We...

Deploying to different environments using GitLab Flow

We have so far discussed how to store and use our completed code by publishing to and pulling from GitLab’s package and container registries. Now, we will learn about some of GitLab’s features for organizing deployments of code to particular environments.

GitLab has two terms, environments and deployments, that are used to describe and categorize the location and version of a deployed application. An environment is represented by a name and a URL, which serve as organizational labels inside GitLab. Whenever an application is deployed to that environment via CI/CD, GitLab creates and categorizes it as a new deployment.

Environments are created via the environment keyword in a CI/CD job. That prompts GitLab CI/CD to associate the job and resulting deployment with that environment, along with the specified name and URL. In the following example, we’ve modified two of our previously created jobs to deploy...

Deploying to a review app for testing

GitLab has a feature called a review app that allows developers to preview their changes directly within a merge request. Review apps use a special kind of environment called dynamic environments, whose names and URLs are set and changed based on the value of CI/CD variables. If you look back at Figure 8.18, you will notice a button that says Enable review app on the top right of the Environments page. Figure 8.19 shows that selecting the button provides a block of code you can paste into your .gitlab-ci.yml file that creates a job that deploys to a review app environment.

Figure 8.19 – Enable Review App

There are two key items to note in the job content. The first is the use of predefined CI/CD variables to specify the environment name and URL. The name of the review environment will be dynamically updated based on the triggering branch, and the URL will be updated based on the dynamic environment name. This...

Deploying to real-world production environments

In the examples presented so far, we have shown that environments are simply organizational categories in GitLab with associated names and URLs. In the real world, however, environments represent actual infrastructure, be it your computer’s or someone else’s. That means recognizing the constraints on the available resources and the importance of proper security and access control.

In this day and age, it is increasingly common to use cloud service providers such as AWS, Microsoft Azure, and Google Cloud Platform for application hosting. These services not only outsource the need for infrastructure management but they also provide programmatic interfaces for managing your environments.

Moreover, suites of developer tools for managing these resources have accompanied the rise of cloud service providers, apart from the cloud vendor-provided tools. Software such as Terraform, Ansible, and Chef is available to declaratively...

Deploying to a Kubernetes cluster

We previously discussed the ubiquity of cloud services as alternatives to self-hosted infrastructure. In a similar vein, container orchestration systems such as Kubernetes have become increasingly popular as alternatives to the manual management of bare-metal servers or container hosts.

Deploying to Kubernetes with GitLab CI/CD can be conceptually similar to the workflows we have covered thus far. You can set up a GitLab runner with a Kubernetes executor, which communicates to the clusters using the Kubernetes API. Alternatively, GitLab optionally offers an additional approach called the GitOps workflow, which is not wholly reliant on CI/CD pipelines. We will summarize each of them in turn.

The CI/CD workflow

Using the concepts so far, you can use a normal CI/CD setup to deploy containerized applications to Kubernetes. This requires a runner registered with the Kubernetes executor. During runner registration, information such as cluster host...

Summary

In this chapter, we described various ways of packaging and deploying our code. This included making use of GitLab’s package and container registries, CI/CD environments, and methods for interacting with cloud-native infrastructure.

Even if you may not use all of the discussed features or services in your day-to-day work, we hope this chapter provided a useful bridge to more practical, real-world use cases of GitLab’s features.

The next chapter will build upon what we’ve learned already. It will also introduce advanced features for improving CI/CD speed and performance, increasing developer productivity, and optimizing your ability to quickly build and ship software.