GitLab 12.0 brings DevSecOps in a single application

GitLab 12.0 is here!

This month’s update is a rather significant one since it brings DevSecOps in a single application with the addition of Visual Review Tools, project dependency list, and Merge Trains.

GitLab 12.0 marks a key step in our journey to create an inclusive approach to DevSecOps.

Sid Sijbrandij, CEO at GitLab

Let’s have a look at the most important updates in GitLab 12.0.

“DevSecOps is the natural next iteration of DevOps”

Before we present our standard overview of the new features, let’s first have a look at GitLab’s big announcement.

The GitLab team takes the next step in bringing “developers, operations professionals, and the security team together” in a single application for the entire DevSecOps lifecycle.

This new function builds upon the security features that have been added over the past 12 months including SAST, DAST, dependency scanning, and container scanning.

From the Gitlab blog post:

DevSecOps aims to integrate security best practices in the DevOps workflow to ensure every piece of code is tested upon commit. GitLab takes that a step further by building security capabilities into the CI/CD workflow, empowering developers to identify vulnerabilities and remove them early, and by providing the security team with their own dashboard to view items not resolved by the developers.

The figure below summarizes how GitLab integrates and automates security into the CI/CD pipeline.

Source: GitLab blog

What’s new in GitLab 12.0?

The latest release brings an impressive list of new features and improvements as well as some important deprecations.

The new features are:

Visual Reviews – Ability to insert visual review tools directly into the Review App itself.

Project dependency list – You can now easily access a project’s Dependency List (sometimes referred to as a Bill of Materials or BOM) from the left sidebar menu.

Restrict access by IP address – Ability to prohibit traffic from outside IP addresses from accessing company resources.

File syncing to Web Terminal – Changes made in the Web IDE will now be synced to the Web Terminal. User changes made in the Web IDE can now be tested within the Web Terminal before committing them to the project.

Git integration for JupyterHub – JupyterLab’s Git extension is automatically provisioned and configured when installing JupyterHub onto your Kubernetes cluster.

Other important improvements include:

• Multiple extends support in .gitlab-ci.yml
• Vulnerability database available for viewing and accepting contributions
• Prevent non-admins from deleting projects
• Improved support for passing variables to downstream pipelines
• Faster shallow clones by default for all new projects in GitLab CI/CD
• Maven template now automatically pushes to the Maven Repository
• Use GitLab Serverless with existing Knative installations
• Git object deduplication (Beta)
• Validate Kubernetes credentials provided at cluster creation
• No longer require Docker in Docker for DAST

In addition to these new features and improvements, there is a list of important deprecations coming up you should keep an eye on.

• GitLab 9.x now out of support scope – Removal date: June 22, 2019
• GitLab Geo requires Hashed Storage in GitLab 12.0 – Removal date: June 22, 2019
• GitLab Geo requires PostgreSQL Foreign Data Wrapper in GitLab 12.0 – Removal date: June 22, 2019
• Remove Kubernetes service template – Removal date: June 22, 2019
• Remove Prometheus 1.x support – Removal date: June 22, 2019
• Deprecate legacy code paths in GitLab Runner – Removal date: June 22, 2019
• Remove legacy GitLab Runner helper commands – Removal date: June 22, 2019
• Remove legacy Git clean mechanism from GitLab Runner – Removal date: June 22, 2019
• Remove support for MySQL in GitLab 12.1 – Removal date: July 22, 2019
• License Management will use Python 3 as the default in GitLab 12.2 – Removal date: August 22nd, 2019

You can find the detailed list of all new features, improvements, and deprecations here.

SEE ALSO: Turn DevOps into DevSecOps without sacrificing automation

Getting started

If you are eager to upgrade to the latest version there are a couple of things you should keep in mind.

If you are upgrading to your GitLab installation, you must first upgrade to the latest 11.11 patch release, then upgrade to 12.0.0. What’s more, GitLab 12.0 will use Hashed Storage by default but this only affects new installations.

Also, keep in mind that GitLab 12.0 will automatically upgrade the PostgreSQL version to 10.0.

• Users have the ability to skip the auto upgrade of PostreSQL 10.0 creating /etc/gitlab/disable-postgresql-upgrade.
• If you use GitLab Geo, the automatic PostgreSQL upgrade will be skipped on both the primary and all secondary nodes. An upgrade path for Geo users will be provided in 12.1.

Find out more info and upgrade recommendations here.

The post GitLab 12.0 brings DevSecOps in a single application appeared first on JAXenter.