GitLab DevOps is a platform that enables enterprises to increase the total return on software development by delivering software more quickly and effectively while also enhancing security and compliance. A giant leap in the improvement of its’ capabilities occur when GitLab 11 introduced a new idea built on fully automated Auto DevOps processes. GitLab Auto DevOps is a vast group of integrations and features that could make your software delivery process much smoother and more efficient.

What is Auto DevOps GitLab?

Auto DevOps is a collection of twelve features in one script, that work together intuitively. It is a pipeline that starts with an automated build and then runs the application through a series of scans, including container scanning, dependency scanning, open-source license detection, and more. It also does code quality checks and unit tests. With Auto DevOps, you can build your app, test it, make a deployment, monitor your app, and finally secure it in one go. 

How does GitLab Auto DevOps work?

Fundamentally, Auto DevOps is a pre-configured CI/CD pipeline. Auto DevOps is a collection of best practices that serve as a healthy foundation for software development, and it’s free to use for anybody who uses GitHub. The major goal of Auto DevOps is to not only make CI/CD easier for everyone but also to encourage people to write higher-quality code and create better products by automating best practices. The shift left movement, which is a strategy for software testing and software development, in which testing is done earlier in the app lifecycle, influenced DevOps GitLab. Auto DevOps started as an Auto Deployment. It could only do automatic deployments to production and staging on OpenShift, as the name implied. It’s now developed into a complicated script with twelve separate tasks to complete in a single pipeline. Here we describe some of them.

Setting CI/CD pipeline? Then don’t forget about backup. Secure your code with the first professional GitLab backup.

Start 14 days free GitProtect trial

Building

If you already have a Dockerfile, Auto DevOps will only construct it. If no Dockerfile is present, the pipeline will recognize the code language and build it accordingly using Heroku buildpacks. It will produce a Docker image at the end of this section.

Testing

During tests also Heroku buildpacks are being used. It’s important to mention, that not all languages are supported in this stage. The supported buildpacks are: multi, Ruby, node.js, Clojure, Python, Java, Gradle, Scala, Play, php, Go, and NGINX.

Code Quality Analysis

This stage includes code quality analysis, based on the open-source version of code climate. Metrics will be available for you to see in form of tables and charts to help you better understand data. 

Static Application Security Testing (SAST)

SAST does static analysis of the existing code and looks for security flaws. GitLab Runner 11.5 or above is required for the Auto SAST part.

Auto Secret Detection

Secret Detection runs Secret Detection on the current code and looks for leaked secrets using the Secret Detection Docker image. GitLab Runner 11.5 or above is required for Auto Secret Detection.

Review app

In the auto review part, which is helpful when the user is creating merge requests, GitLab DevOps automatically deploys that change to a different environment for you to be able to review how it looks live. The URL for the Review App is: 

13083-review-project-branch-123456.example.com

which combines the project ID, the branch or tag name, a unique number, and the Auto DevOps base domain. For easier finding, the merging request widget includes a link to the Review App. The Review App is also erased when the branch or tag is deleted, such as after merging a merge request.

The auto-deploy-app chart in Helm is used to deploy review applications, which you may modify. The application is deployed into the environment’s Kubernetes namespace.

Dynamic Application Security Testing

After creating a review app Auto DevOps run DAST to detect security vulnerabilities and other issues in your running application. Dynamic Application Security Testing (DAST) analyzes existing code and checks for possible security flaws using the famous open-source tool OWASP ZAProxy. After DAST is completed, the app gets erased. DAST scans the review app on feature branches. Any security warnings are presented on the Security Dashboard and the merge request widget when the DAST scan is completed.

Get free trial

Deploy

After merging the branch back to the master, Auto DevOps automatically deploy that to production (by default) or to staging depending on the configuration.  

Browser Performance Testing 

When the application is in the production or staging pipeline run browser performance testing. The test simulates how the speed of your application increase or decreases from previous versions using benchmark with other versions.  

Auto Monitoring

Right out of the box, Auto Monitoring allows you to monitor your application’s server and response metrics. Auto Monitoring leverages Prometheus to receive system metrics from Kubernetes, such as CPU and memory use, as well as response metrics from the NGINX server, such as HTTP error rates, latency, and throughput.

Customizing Auto DevOps

While Auto DevOps comes with some nice defaults to get you started, practically everything can be customized to match your needs. Custom buildpacks, Dockerfiles, and Helm charts are all available using Auto DevOps. To enable staging and canary deployments, control Auto DevOps using GitLab APIs, and more, you can transfer the whole CI/CD setup into your project.

Select Expand from Settings > CI/CD > Auto DevOps. To see more choices, choose Default to Auto DevOps pipeline. Select your chosen continuous deployment strategy in the Deployment strategy field to deploy the application to production when the pipeline runs successfully on the default branch. Save any changes you’ve made.

Comments are closed.

You may also like