GitLab Auto DevOps can build and deploy your application without you ever writing a single line of YAML.
Let’s see it in action. Imagine you have a simple Node.js app with a package.json and an index.js. No Dockerfile, no gitlab-ci.yml, nothing. You push this to a GitLab repository.
# On your local machine
mkdir my-node-app
cd my-node-app
echo '{"name": "my-node-app", "version": "1.0.0", "scripts": {"start": "node index.js"}}' > package.json
echo 'console.log("Hello from Auto DevOps!"); process.exit(0);' > index.js
git init
git add .
git commit -m "Initial commit"
# Assume you've already configured a remote to your GitLab project
git push origin main
Once that’s pushed, GitLab’s Auto DevOps kicks in automatically. It detects the package.json and infers it’s a Node.js application. It then proceeds through a series of predefined CI/CD jobs.
The first stage is build. Auto DevOps will use a Docker image that contains the necessary build tools for Node.js. It runs npm install (or yarn install if it detects yarn.lock) and then npm run build if a build script is defined in package.json. If no build script exists, it skips the build step and proceeds directly to packaging. The result is a Docker image containing your application.
Next is test. Auto DevOps looks for common test commands like npm test or yarn test. If found, it executes them within the built Docker image. If tests pass, it proceeds. If tests fail, the pipeline stops, and you’re notified.
Then comes deploy. This is where Auto DevOps shines. By default, it will attempt to deploy your application to Kubernetes. If you have a Kubernetes cluster configured in your GitLab project’s CI/CD settings, Auto DevOps will automatically create a deployment. It uses Helm charts to manage the deployment, creating a Deployment and a Service in your Kubernetes cluster. The application becomes accessible via a dynamically assigned ingress URL.
The full mental model: Auto DevOps is a set of predefined CI/CD templates and jobs that GitLab provides. When enabled on a project, it automatically configures a pipeline based on your project’s detected language and framework. It handles:
- Build: Detecting your language/framework and building a Docker image.
- Test: Running your application’s test suite.
- Container Scanning: Scanning your Docker image for vulnerabilities.
- Review Apps: Deploying your application to a temporary environment for each merge request, allowing for visual review before merging.
- Staging Deployment: Deploying to a staging environment.
- Production Deployment: Deploying to your production environment.
- Canary Deployment: Rolling out changes gradually to a small subset of users before a full production release.
- Performance Testing: Running load tests against your deployed application.
- Security Scanning: Running various security scans on your code and dependencies.
The "magic" is in the detection and the sensible defaults. For instance, if it sees package.json, it knows to use a Node.js buildpack. If it sees pom.xml, it uses a Maven buildpack. If you have a Dockerfile, it prioritizes that for building your image.
What most people don’t realize is the extent to which Auto DevOps can be customized without touching YAML. You can configure Auto DevOps to use different deployment strategies, specify custom Helm chart values, or even override specific jobs by creating a gitlab-ci.yml file that includes the Auto DevOps template and then selectively overrides jobs. For example, to deploy to a specific namespace in Kubernetes, you’d navigate to your project’s Settings > CI/CD > Auto DevOps and set the KUBE_NAMESPACE variable.
After your application is successfully deployed to production, the next logical step is often to monitor its performance and health.