Auto DevOps is designed to make CI/CD adoption easier, with baked-in best practices and automation to take care of moving your code seamlessly through the software development lifecycle. If you or your team are new to DevOps, this is a great place to start. We're excited to share some new and upcoming improvements to Auto DevOps, but first:
There is a prerequisite for Auto DevOps, and that's a Kubernetes cluster. This may or may not be an easy step for you to complete, but your team likely has a cluster set up already. If not, read our getting started guide.
Auto DevOps should be enabled by default, but if it isn't, go to Settings > CI/CD > Auto DevOps and check Default to Auto DevOps pipeline. There are a lot of automated stages available, depending on what version and tier of GitLab you use, and which components you add to your Kubernetes cluster.
- Auto Build: Builds your code using a Dockerfile if your project has one, or a Heroku buildpack selected based on the programming language you use, but you can manually set it.
- Auto Test: Runs any tests included in your codebase, again using a Heroku buildpack.
- Auto Code Quality: Runs static analysis and other checks over your code using the code quality image.
- Auto SAST (Static Application Security Testing): Runs static analysis checks focussed on security issues using the SAST image.
- Auto Dependency Scanning: Checks for potential security issues on project dependencies using the dependency scanning image.
- Auto License Compliance: Searches project dependencies for what licenses they use, using the license compliance image.
- Auto Container Scanning: Uses Clair to run static analysis and security issue checks on any Docker images used.
- Auto Review Apps: Creates a version of an application in a temporary environment for team members to try and review.
- Auto DAST (Dynamic Application Security Testing): Runs further security checks using the OWASP ZAProxy tool.
- Auto Deploy: Deploys an application to a production environment as defined in the Kubernetes environment settings.
- Auto Browser Performance Testing: Tests the performance of application web pages using the Sitespeed.io image.
- Auto Monitoring: Uses Prometheus to monitor system metrics for a deployed application.
Recent improvement: Readiness for Kubernetes 1.16 (#32720)
We recently reworked Auto DevOps features to match changes in the Kubernetes 1.16 API. Nothing you use will change, but behind the scenes, access different API endpoints, and in different ways.
Coming soon
Several improvements are coming to Auto DevOps in our next few releases to ensure that we help your projects conform to the latest DevOps best practices, and integrate with as many of our platform features and external tools as possible.
Cloud-native buildpacks for Auto DevOps (#25954)
Since Heroku created the buildback concept in 2011 when using virtual machines was typical, others have adopted the concept, and created their own that suited containers better. This change in need resulted in the Cloud Native Computing Foundation (CNCF) accepting the Cloud Native Buildpacks project in 2018 to maintain a standard for buildpacks that suits their modern use cases. Also, in 12.10 we've added support to Cloud Native Buildpacks, and will be switching our "traditional" Heroku buildpacks to these newer ones in the coming months.
Running Auto DevOps on air-gapped networks (#25642)
While many of our users have their clusters connected to the internet, we know not all do, and want to offer these customers as many features as possible. As part of GitLab 13.0, we are researching how to give you the ability to configure the locations of dependencies for Auto DevOps stages.
Upgrade to Helm 3 (#29038)
We use Helm to deploy packages needed for various stages of the Auto DevOps process. In 13.1 we will upgrade Helm to version 3, which brought a series of significant changes, including removing Tiller as the "server" side of Helm.
NGINX alerts to auto-monitoring in Auto DevOps (#118788)
Nginx is a popular HTTP and reverse proxy server. In 13.0 we will add support for the metrics it exposes to Prometheus for providing alerts to our auto-monitoring feature.
Add Merge Train support to Auto DevOps (#121933)
Merge Trains are a GitLab feature that let you queue lists of merge requests waiting for merging into a target branch. Auto DevOps doesn't currently support merge trains, but in version 13.1, we will start adding support and helping users get the configuration they need to add their Merge Trains to Auto DevOps workflows.
You can read more about merge trains here.
Looking further ahead
These planned features aside, one other area we are looking to improve is adopting more of a Directed Acyclic Graph (DAG) approach to Auto DevOps pipelines. You will no longer have to wait for one stage to complete before another begins, and you can focus on the results of the stages important to you. Feel free to view and comment on the open issue.
We are broadly working to make Auto DevOps work seamlessly with as many other GitLab features as possible, and hope you enjoy the time and insights it gives you.
You can read more about Auto DevOps here.
