In what was the last full working week of 2020, GitLab released GitLab 13.7 to the general public. Don’t be fooled by that minor code release status as this is not an insignificant release with several major new and much-needed features. In fact, there are 45 new features.
Gitlab is one of a number of Code Management products that aid in the life-cycle of code development. This article will concentrate on the new features of their latest release and the potential benefits that it can bring to the pipeline and workflows of your DevOps practice.
What’s new in GitLab 13.7
The first feature we will look at is what GitLab has termed “Enhanced Project Management for Cross-Collaboration”. One of the key tenets of collaborative coding is the concept of the Merge Request. These are the foundation of code change suggestions and reviews by providing a central location for said collaboration. This release added the concept of merge request reviewers, this will enable a more structured and organized hierarchy, enabling the team to quickly find out who is involved in the merge request process. The addition of this feature allows direct formal reviews with notifications. This improvement is actually useful from both a procedural point of view and an operational perspective as it formalizes responsibility. And aids in reducing manual tasks and context switching which are the enemy of efficiency. The ability to easily clone issues to branch code is key to agile planning and project management adding “merge request reviews” significantly simplifies the responsibility matrix for the Scrum masters and program management teams.
For a more in-depth overview read merge request reviewers on GibLab’s site.
The second major feature is that of ”Improved release Automation and deployment flexibility”. DevOps is all about continuous development and continuous integration/improvement (CD/CI), the key to both these tenets is automation and flexible deployment methodology. This release adds the ability of automatic role-backs on code failure. This feature will automatically fail-back any feature to the last known successful build, sending an automatic notification to alert on the failure, this alert can be used to raise a ticket for remediation. This is a massive improvement on deployment resilience as it directly affects the stability of the production product, reducing the potential for unintended downtime due to deployment overruns, by removing a potential manual task. Another improvement is reflected in the Environments page where deployment status is now displayed together with any associated alert status. Finally, in this section there is a beta of the Gitlab Runner Container which can be deployed on Redhat Openshift or GitLabs Certifed Runner Operator. Although it is currently has a beta status, it is expected that this shall soon receive the GA status.
The next set of features relate to “reliable and efficient package and dependency management”. One of the major issue with workflows is that of programming languages, binaries, interactions and artifacts that make up a deployment lead to a very complicated digital machine. Many differing cogs and levers create integration complexities. The more efficiently a workflow is managed, the greater control you have over dependencies and packages, the less time you lose on the development cycle due to a common playing field, results in a quicker return on your investment. To this effect, this version now has a Generic tab that you can easily use to sort your generic and common packages.
Improvements have been made to the operation of the GitLab Dependency proxy that was released in 13.6, using the proxy is a way of avoiding newly introduced Docker rate limits, it does this by caching the container images. However, in the original release, it could only cache the Images but not the manifest and since a manifest is needed to undertake a build, a pull request was still needed, which meant that the download of the manifest would count against your limits, therefore by adding Manifests to the proxy means that docker builds no longer count against rate-limits unless a new image or manifest needs to be downloaded. Another additional improvement is that the proxy can now integrate with private projects and finally proxy can now utilize predefined variables, instead of having to hard-code them in your yaml file.
A few other key features of the new release are that you can now import requirements from a CSV file, SAML user provisioning has been improved with the introduction of groups, Canary weights can now be changed directly from the Deploy boards allowing greater control over manual and incremental rollouts, multiple Kubernetes manifests are now supported allowing a single repository to manage different clusters from a single location.
Summary
This is just a small highlight of the 43 improvements that GitLab 13.7 bought to the table, GibLab as a product has its roots in being a code repository and it is a fairly well-featured Git repository, but these features really enhance what was its secondary focus that of a workflow and automation engine, this release seriously enhances the products CI/CD credentials validating Gartner’s visionary status.
