In today’s DevOps-dominated world, robust CI/CD pipelines are critical for every stage in your Software Delivery pipeline. The right tools for your developer teams are essential to make this happen. A lot of companies use Gitlab to streamline their DevOps operations. About a year ago, I highlighted the most relevant security improvements of Gitlab 13. Last month, Gitlab 14 was released with a lot of new features and improvements. Its formal release date was June 22th. In this article we will take a look at the latest and greatest features as well as other improvements which you can use to benefit from it.
GUI Improvements
Developers might not care so much about a slick User Interface, but Gitlab is used by much more people than just developers. It’s a central CI/CD tool for nearly everyone involved in the various stages of software development. Therefore, an intuitive GUI is as important as it’s underlying features.
Some of the the most important changes are:
- The top navigation menu has been streamlined. Frequently visited pages are grouped on top and also the most important project related pages are put together. Responsive views help to support smaller screens since not all links and options are displayed at once.
- Gitlab supports more features with every release and it only gets bigger in the future. The new redesign of the navigation sidebar is cleaned up and some links are moved to separate menus. It’s important to align the navigation with the mental model of the DevOps related lifecycle of software packages. Developers are already aware of it, this makes working with the GUI a bit more intuitive.
- Wiki pages can now be written using Markdown since there is a visual editing tool for the most common Markdown content types. Hopefully this makes writing documentation more fun fun 🙂
CI/CD related improvements
Various improvements are made for CI/CD related aspects as well as IaC.
Initial CI/CD pipeline template
Automation efforts will speed up even more with the new initial CI/CD template when you create a new CI/CD pipeline. Prior to release 14, you would just get an empty template. Now Gitlab presents you with a a fully working example pipeline based on three stages. Inline comments help to understand the syntax and the ways to customize it. This really lowers the barrier to start creating pipelines right away.
Slack notifications
Slack notifications help to keep track of changes to wiki pages. Besides the project, page name and commit message, you can view the actual changes to the wiki page as well. A simple link leads you to a comparison window to highlight the textual changes. This new feature is available for the free, premium and ultimate version of Gitlab.
Downstream pipelines
CI/CD pipeline jobs can trigger downstream pipelines to run when they are finished themselves. This makes it possible to chain pipelines that need to run in sequence. As of now, the downstream pipeline shows the “parent pipeline” which triggered it. When using this feature, developers can review their entire workflow much easier compared to previous versions of Gitlab.
Support for Terraform modules
Lot’s of work has been done in the past to support Helm charts to be stored in it’s own repository. Helm helps to package software applications to deploy them to Kubernetes clusters. But what about the other infrastructure resources?
Luckily, this gets a big boost since Terraform modules are now supported as well. Gitlab enables you to store Terraform modules in a dedicated Terraform module repository. It is no longer needed to install a third party module registry or to use Git based registry. The new solution helps to support versioning control and to distribute modules in an easier fashion. Developers can leverage the CI/CD functionality of Gitlab to deploy Terraform based templates more easily.
Security
One of my favorite new security features is the aggregation and normalization of security issues. From a security teams’ perspective, this really helps to streamline their efforts to analyze security risks.
Gitlab already supports a wide range of security tools which scan your source code in various stages of the SDLC. The default container scanner changed from Clair to Trivy. It provides more accurate results and supports more Operating Systems for container images. Organizations which already used other container scanning solutions should check out the migration guide of Gitlab.
Different security tools in Gitlab produce reports in various formats and structures. Custom output is transformed to standard JSON reports which Gitlab processes and transforms to build up the GUI or downloadable report. Gitlab now aggregates those results and presents them to the end-user in a consistent way.
Aggregation of vulnerabilities
Besides these changes, Gitlab also aggregates identical DAST related vulnerabilities into a single vulnerability. Every vulnerability would get it’s own, unique URL. Basically every URL needed to be analyzed. Whether the DevOps team itself or the security team managed the vulnerabilities, valuable time was lost if multiple of the same vulnerabilities were presented. As of now identical vulnerabilities are aggregated into a single view. You can drill deeper into the found vulnerability to see the occurrences across the code-base. This improvement really helps to speed up the assessment processes. Furthermore, organizations can learn from the number of identical vulnerabilities and provide extra training and support to the teams which own them. It also boosts (common) security awareness.
Another level of protection for secrets: it is now possible to hide variable values in job logs. Besides several special characters, the ~ character is also supported now. External secrets providers might use this character for their variable names. Less information about secrets which are logged helps to limit the exposure of sensitive information, so this feature is a welcome addition to enhance the security of your CI/CD pipelines.
Business related improvements
Both the SaaS version as well as the Self-Management version of Gitlab (Ultimate) can now report on the lead time of merge requests at group level. From a business perspective it’s interesting to report how fast a merge request travels through the stages of the entire SDLC and makes it up to production. This gives you an indication how fast new features are developed, tested and released. Based on this, business representatives can make decisions on how many (new) features to expect given a release cadence. Projections of future features are more reliable now since they are based with actual data.
Metrics
This new feature is part of the larger set of key metrics which are developed by the DevOps Research and Assessment (DORA) team. This is a dedicated team that focuses exclusively on the support for four major KPIs:
- Change failure rate: percentage of deployments which cause a failure in production.
- Time to restore a service: how much time it takes to recover from a failure in production.
- Lead time for changes: how much time it takes for code to deployed to production.
- Deployment frequency: how often an organization successfully deploys to production.
Code owners
Business owners are end responsible for the source code of their projects. In the Ultimate version of Gitlab 14, it is possible to track existing (or absent) code owners. Using this new feature helps to handle merge requests which are pointed to the code owner. In case of an absent code owner, you can easily find them by filtering the DevOps Adoption table. Both features really enhance the code review process, thus improving the desired speed and quality of code reviews and merge requests.
Breaking changes
Almost every major release comes with breaking changes. Gitlab 14 is no exception to the rule. Since the number of new features and improvements is quite large, there are some breaking changes you need to take into account:
- Several APIs have changed: limit the number of projects which can be retrieved, a complete removal of the “segments” concept. Only groups and projects remain. Besides this, the maximum file size of project API uploads is enforced.
- Terraform templates are shifted from latest to major, thus this creates an incompatibility with each other. You need to adjust your Terraform pipelines to make sure they work after the upgrade to version 14.
- Merge requests which are still in progress are marked “draft merge requests”. This makes it more clear that the merge request is not ready yet to be merged. The default branch in Git is now called “main” instead of “master”. It’s according to the global Git project.
From a security perspective, these are notable changes:
- The WAF (Web Application Firewall) feature is removed. Users are advised to implement the standalone ModSecurity project as an alternative.
- Clair as a container scanning solution is replaced by Trivy. You need to adjust your CI pipeline jobs to make sure these remain working correctly.
- Administrators now need to explicitly enable newly created SSH keys. These keys are disabled by default to further improve the security related aspects of these sensitive secrets.
- Several environment variables for SAST, DAST and Secret detection are changed. Think of SAST_ANALYZER_IMAGE_TAG, secret_detection_default_branch. Gitlab advises to use their managed CI templates which you can inherit and override in favor of creating your own templates from scratch. By doing so, you need to adjust fewer environment variables.
Other changes
It is impossible to list all the changes and improvements. Some last ones to conclude this article:
- You can now use the database load balance in the free version of Gitlab. Given this, more users can benefit from heavy loads as they scale their projects.
- Administrators can now see how much memory is used by looking at a performance bar.
- Change issue types when you edit them. It helps to make sure the team in charge handles the issue with the right priority. No need to delete and recreate the issue so less data is lost and time is saved.
Conclusion
Gitlab 14 is a major upgraded compared to 13.x. There are tons of new features ranging from GUI related improvements to changes which work “under the hood”. Special care for security related features underscores the importance of developing secure software. Various CI/CD and DevOps related features helps teams to speed up their DevSecOps journeys. If you haven’t done so, try out Gitlab 14 and evaluate the features yourself. Good luck.
