Originally reported by SD Times. This article summarises the GitLab 11.0 release announcement from June 2018.
GitLab 11.0 and the General Availability of Auto DevOps
GitLab shipped its 11.0 release in June 2018, marking the general availability (GA) of Auto DevOps—a feature set designed to automate the entire software delivery lifecycle with minimal manual configuration. The company had previewed Auto DevOps the previous year, positioning it as a way for development teams to move ideas into production faster without needing to hand-craft CI/CD pipelines from scratch.
What Is Auto DevOps?
Auto DevOps is a collection of pre-configured GitLab CI/CD pipeline stages that automatically apply best-practice tooling to a repository when no custom .gitlab-ci.yml configuration is detected. The goal is to give teams a fully functional delivery pipeline out of the box, covering:
- Build – Automatically builds a Docker image using Heroku buildpacks if no Dockerfile is present.
- Test – Runs the project’s test suite and reports results.
- Code quality scanning – Analyses code for maintainability issues.
- Static Application Security Testing (SAST) – Scans source code for known vulnerability patterns.
- Dynamic Application Security Testing (DAST) – Runs a live scan against a deployed review environment.
- Dependency scanning – Checks third-party libraries for known CVEs.
- Container scanning – Inspects the built Docker image for OS-level vulnerabilities.
- License scanning – Identifies open-source licences in use.
- Performance testing – Runs browser-based performance benchmarks against the deployed application.
- Deploy – Deploys to a Kubernetes cluster, with support for review apps, staging, and production environments.
- Monitoring – Provides Prometheus-based metrics for deployed applications.
In practice, a developer commits code and GitLab’s pipeline handles everything downstream. Security scanning is built directly into the pipeline rather than being bolted on as an afterthought, which was a deliberate design choice to shift security left in the development process.
Kubernetes at the Core
Auto DevOps uses Kubernetes as its deployment target. GitLab 11.0 integrated with Google Kubernetes Engine (GKE), allowing teams to provision and connect a cluster directly from the GitLab interface. Once a cluster was attached, Auto DevOps could deploy review apps and production workloads without additional infrastructure scripting. Teams not using GKE could also connect their own Kubernetes clusters.
Language and Framework Support
GitLab 11.0 extended Auto DevOps language support to include .NET and Scala, in addition to languages already supported through Heroku buildpacks such as Ruby, Python, Node.js, Java, and Go.
The Enterprise Angle
GitLab positioned Auto DevOps explicitly as an on-ramp for enterprises that had not yet adopted DevOps practices. The company’s stated aim was to reduce the organisational friction of standing up a compliant, secure delivery pipeline by providing sensible defaults rather than requiring teams to research, select, and integrate individual tools.
“With the release of GitLab 11.0 and the power of Auto DevOps, we’re making it effortless for enterprises who haven’t yet transitioned to DevOps to effectively push an ‘easy button.’ This enables a fully functional delivery pipeline in just minutes.”
Sid Sijbrandij, Co-founder and CEO, GitLab
Release Cadence
GitLab 11.0 was the company’s 84th consecutive monthly product release, reflecting a disciplined release schedule that GitLab has maintained since its early days. Monthly releases allow the project to ship incremental improvements predictably, which matters for teams planning upgrade windows.
Key Takeaways for DevOps Teams
- Auto DevOps removes the need to author a CI/CD pipeline from scratch for greenfield projects or teams new to GitLab CI.
- Built-in SAST, DAST, dependency scanning, and container scanning make it easier to meet security requirements without integrating separate tools.
- Kubernetes is a prerequisite for the deployment and monitoring stages; teams without a Kubernetes cluster will need to provision one or configure an alternative deployment job.
- Auto DevOps pipelines can be customised: individual stages can be disabled or overridden by adding the relevant variables or job definitions to a
.gitlab-ci.ymlfile. - .NET and Scala support broadened the feature’s applicability for enterprise polyglot environments.
For teams evaluating GitLab as a unified DevOps platform, version 11.0 represented a meaningful step toward the company’s single-application vision—one interface covering source control, CI/CD, security, and observability rather than a collection of loosely integrated third-party tools.