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.
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.
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.
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.
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.
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.
When it's ready, the user can create the release which automatically generates the release evidence. This streamlined process helps reduce release cycle times.
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.
How to enable Auto DevOps in GitLab.
The first job in Auto DevOps is the build job, as shown below:
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.
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.
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.
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.
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.
How incremental rollout works in GitLab.
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:
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.
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.
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.
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.
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.
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.
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 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.
The environments dashboard in GitLab.
Another option is to drill down into a specific environment to see all the updates applied to the environment.
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.
Features flags in GitLab.
A project's audit events dashboard will record what user introduced a feature flag.
Screenshot shows example audit events dashboard in GitLab.
Check security and compliance-related items of the project by visiting the Security dashboard.
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.
