Blog Engineering How to use GitLab tools for continuous delivery
December 17, 2020
11 min read

How to use GitLab tools for continuous delivery

Learn how to use GitLab technology to release software faster and with less risk.

CD-continuous-nature-cover-880x586.jpg

This blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2021-04-01.

Each organization is unique in how they adopt continuous delivery (CD) principles, but the journey to modernize and enhance your software release process can be conducted in phases. In this blog post, we unpack some of the tools companies can use to adopt continuous delivery (CD), and explain how companies can reach continuous delivery in three key stages. The good news is, regardless of how you get there, GitLab offers a solution that allows companies to modernize their release process at their own pace and in their own way.

Consolidate disparate tools into a single platform

The first step to reaching continuous delivery is to consolidate the number of disparate tools in your pipeline by using the tools and capabilities baked into the GitLab product. In this section, we summarize some of the fundamental components of GitLab and give examples of how they work.

GitLab users can track issues and merge requests using milestones, which also help with setting time-bound goals. Milestones can be used as Agile sprints and releases, and allow you to organize issues and merge requests into a one group, with an optional start date and an optional due date.

Example of GitLab milestone from demo project Screenshot shows example milestone in GitLab.

Issues are a fundamental tool in GitLab, and include many components to help users communication information about product problems, new features, and more.

Merge requests (MRs) are created to merge one branch into another. MRs are also where solutions are developed and is a key input to the release planning process.

Both issues and MRs are core components of a release and allow for the audit and tracking of application changes created by a large group of DevOps engineers, system administrators, and developers. We often use Epics in the release planning process. Epics are used to track groups of issues with the same theme. In the example below, an Epic was created for all the UI-related issues in a project.

Example of GitLab epic for frontend work An example of an Epic for frontend work in GitLab.

Iterations are a relatively new tool that allows users to track issues over time and helps to track velocity and volatility metrics. Iterations can also be used with milestones and can track a project's sprints using the detailed iterations pages, which include many progress metrics.

Example iteration from demo project This screenshot shows an example of how iterations work in GitLab.

The Roadmap tool assembles epics, milestones, and iterations in a timeline format, which makes it easier to visually track all progress toward a release and helps the user streamline the release process.

Example of roadmap from demo project This screenshot shows an example of roadmap in GitLab.

GitLab offers many approval gates for your release. Set a deploy freeze window to temporarily suspend automated deployments to production. The deploy freeze window prevents unintended production releases during a particular time frame to help reduce uncertainty and risk of unscheduled outages.

Example of deploy freeze window from demo project This screenshow shows an example deploy freeze window in GitLab.

Related to the deploy freeze window, users can protect the production environment for a release to prevent unintentional releases. Deploy freeze windows protect the production environment by specifying who is allowed to deploy to the environment. Assigning specific roles and responsibilities streamlines the approval gates and release process.

protected-env

When it's ready, the user can create the release which automatically generates the release evidence. This streamlined process helps reduce release cycle times.

Example of release evidence from demo project Here is an example of release evidence from a demo project in GitLab.

Implement continuous delivery

The capabilities described above help to establish some best practices for software continuous delivery. In this next phase of the CD cycle, every change is automatically deployed to the User Acceptance Testing env/Staging (with a manual deployment to production). In this scenario, there is no need for a deploy freeze, and the release manager can cut a release from staging at any point in time.

GitLab Auto DevOps helps users automatically create the release pipeline and relieves them from manually creating a pipeline. With Auto DevOps, users can automatically deploy to the staging environment and manually deploy to production and enable canary deployments. Auto DevOps, which is based on DevOps best practices, helps you streamline the release process.

Example of enabling Auto DevOps from demo project How to enable Auto DevOps in GitLab.

The first job in Auto DevOps is the build job, as shown below:

build-job The build job in GitLab Auto DevOps.

The build job applies the appropriate build strategy to create a Docker image of the application and stores it in the built-in Docker Registry.

Example of container registry from demo project See the example of a container registry in GitLab.

Faster and more reliable releases happen when you have build components like Docker images that are consistent, uniform, and readily available throughout the release process. GitLab also includes a built-in Package Registry that supports many packaging technologies.

Example of package registry from demo project Here's what the package registry looks like in GitLab.

Review Apps allow the user to visualize what features will go into production. As updates are made to the application via MRs, the MRs kick off Review Apps, which streamlines the review process, including the automatic creation and destruction of an ephemeral review environment. Using Review Apps, stakeholders can verify the updates to the application before the changes are merged to the main line. Review Apps help increase code quality reducing the risk of unexpected production outages.

Example Review Apps from demo project An example of Review Apps in GitLab from a demo project.

Once an application is built and passes many automated tests, checks and verifications, the Auto DevOps pipeline automatically stands up a staging environment and deploys the application to staging.

Example staging environment from demo project An example staging environment in GitLab.

At this point, a user can manually deploy the updated application as a canary deployment to the production environment. In doing so, a user ships features to only a portion of the pods fleet and watches their behavior as users visit the temporarily deployed feature. If everything checks out, the next step is to deploy the feature to production. After deploying to production, roll out the Canary deployment to 50% of the production pods. Incremental rollouts lower the risk of production outages and delivers a better user experience and customer satisfaction. Advanced deployment techniques, like canary, incremental, and Blue-Green also improve development and delivery efficiency, and streamlines the release process.

Example incremental rollout from demo project How incremental rollout works in GitLab.

live-env-button To check the running application for integrity, you can click on the "Open live environment" button.

Clicking this button will open up the application in a different browser tab. But what if you run into an application error? As shown below:

Example application error from demo project This is what an application error will look like in GitLab.

If you encounter an app error, you could decide to perform a rollback by drilling down into the production environment page and identifying the release that had been running before the last deployment. This page is an auditable sequence of changes that have been applied to the production environment. The rollback process starts with the click of a button. Rollbacks speed up recovery of production in case of failures and lowers outage times, which improves the user experience.

Example rollback from demo project Rollback in GitLab to speed up production recovery.

Pipelines usually run automatically, but to schedule a pipeline once a day at midnight, for example, so staging can have the most recent version of the application each day, go to CI/CD->Schedules. Scheduling pipelines can improve the efficiency of the development life cycle and release processes.

Example of pipeline scheduling from demo project How to schedule a pipeline to run in the future.

While the application is running in production, track how the release is performing and quickly identify and troubleshoot any production issues. There are a few ways to do this. One way is to access the "Monitoring" feature for a specific environment to track system and application metrics, such as system and pod memory usage, and the number of cores used. The monitoring tracking includes markers (small rocket icon) when updates were introduced to the environment, so that fluctuations in the metrics can be correlated to a specific update.

Example monitoring capabilities from demo project Explore monitoring capabilities in GitLab.

Monitoring reduces the time to identify, resolve and preempt production problems, which lowers the risk of unscheduled outages. It also provides an opportunity for monitoring business activity and optimizes cloud costs. This type of monitoring is not only useful to release managers but also to DevOps engineers, application operators, and platform engineers.

Another way to monitor the release is by creating alerts to detect out-of-range metrics, which are visible on the overall operations metrics dashboard as well as on each specific environment window. Alerts can also automatically trigger ChatOps and email messages to appropriate individuals or groups.

![Example alerts from demo project](https://about.gitlab.com/images/blogimages/cd-solution-overview/alerts.png Example alerts in GitLab.

You can manage alerts from the Operations Alerts window, a single location from which you can assess and handle alerts, which may include the manual or automatic rollback of a release.

Example alerts dashboard from demo project What the he alerts dashboard looks like on GitLab.

Users can track and monitor the release progress through Value Stream Analytics, where you can check your project or group statistics over time and see how your team improves in the number of new issues, commits, deploys, and deployment frequency. Value Stream Analytics is useful to quickly determine the velocity of a given project. It points to bottlenecks in the development process, allowing management to uncover, triage, and identify the root cause of slowdowns in the software development life cycle.

Example value stream analytics from demo project Value stream analytics in GitLab.

Lastly, another way to track and monitor the release is through Pipeline analytics. Pipeline analytics shows the history of your pipeline successes and failures, as well as how long each pipeline runs. This helps explain the health of your projects and their continuous delivery.

Example pipeline analytics from demo project Screenshot shows example pipeline analytics in GitLab.

The Operations dashboard can contain more than one project, and allows users to oversee more than one release. This dashboard provides a summary of each project's operational health, including pipeline and alert status.

Example operations dashboard from demo project Example of operations dashboard in GitLab.

Release managers can also access the environments dashboard to provide a cross-project, environment-based view that lets you see the big picture of what is happening in each environment.

Example environments dashboard from demo project The environments dashboard in GitLab.

Another option is to drill down into a specific environment to see all the updates applied to the environment.

Example production environment dashboard from demo project The production environment dashboards shows all updates applied to the environment.

All these dashboards offer operations insights that are necessary to understand how a release is performing in production and quickly identify and troubleshoot any production issues.

Implement continuous deployment

The third phase in the journey is continuous deployment, where users can send updates directly to production. Instead of manually triggering deplyments, continuous deployment sends changes to production production auomatically (no human intervention is required). Teams can only achieve continuous deployment once continuous delivery is already in place.

To introduce a feature to a segment of end-users in a controlled manner in production, create feature flags. Feature flags help reduce risk and let the user conduct controlled tests and separate feature delivery from customer launch.

Example feature flag from demo project Features flags in GitLab.

A project's audit events dashboard will record what user introduced a feature flag.

Example audit events dashboard from demo project Screenshot shows example audit events dashboard in GitLab.

Check security and compliance-related items of the project by visiting the Security dashboard.

Example security dashboard from demo project The security dashboard in GitLab.

These dashboards help you preempt out-of-compliance scenarios to avoid penalties. They also streamline audits, provide an opportunity to optimize cost, and lower risk of unscheduled production outages.

We have reviewed how GitLab can help you make your releases safe, low risk, worry-free, consistent, and repeatable.

Whether you are just starting your journey into DevOps, or already in the midst of implementing DevOps processes, GitLab's continuous delivery can help you every step of the way with capabilities built on DevOps and CD best practices.

Watch and learn

More of a video person? Tune in below to see GitLab’s continuous delivery solution in action.

https://www.youtube-nocookie.com/embed/L0OFbZXs99U

For more information, visit LEARN@GITLAB.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert