The release of GitLab 14.1 and what's coming for 14.2 version

The new release of GitLab 14.1 comes with the ability to build, publish, and share Helm charts, create escalation policies to page responders, connect GitLab Runners to your Kubernetes clusters, enforce code coverage decisions. Following are just a few highlights from the 50+ improvements in this release.

Build, publish, and share Helm charts

Helm defines a chart as a Helm package that contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. For organizations that create and manage their own Helm charts, it’s important to have a central repository to collect and share them.

Now you can use your GitLab project to publish and share packaged Helm charts. Simply add your project as a remote, authenticating with a personal access, deploy, or CI/CD job token. Once that’s done you can use the Helm client or GitLab CI/CD to manage your Helm charts.

Escalation Policies

Teams that maintain critical systems can’t afford to miss alerts for outages or service disruptions. Escalation policies are a safety net for these situations. Escalation policies contain time-boxed steps that automatically page a responder in the next escalation step if the responder in the step before didn’t respond. To protect your company from missed critical alerts, create an escalation policy in the GitLab project where you manage on-call schedules. In GitLab 14.1, users can create, view, or delete escalation policies.

CI/CD Tunnel for Kubernetes clusters

Until now, connecting Kubernetes clusters to GitLab CI/CD required users to open up their clusters towards GitLab. Some organizations do not encourage opening up their firewall externally due to security concerns. GitLab now ships with a CI/CD Tunnel that connects GitLab Runners with your Kubernetes cluster using the GitLab Kubernetes Agent. This enables versatile GitOps workflows where the deployment logic can be coded in the pipeline.

Code coverage merge request approval rule

To keep code test coverage high, you need to ensure that merge requests to your codebase never decrease test coverage. Previously, the only way to enforce this was to require approvals from users who would check for test coverage decreases as part of their reviews.

Now you can enforce this organizational policy with the new Coverage check approval rule. This is a simple way to ensure merge requests that would decrease test coverage cannot be merged.

GitLab 14.2 release

The next GitLab release is 14.2 and this page contains the list of issues that are currently planned for that release. GitLab present this during the monthly kickoff call, which is publicly streamed to the GitLab Unfiltered YouTube channel. Here is a direct link to the 14.2 Release Kickoff video.

Tools like GitLab accelerates software development by streamlining version control, CI/CD, and security in a single application. If you or your organization wants to implement this or other similar tools in your DevOps environment contact us.

Source: GitLab