The Ultimate Guide to GitLab Auto DevOps

Today, businesses need fast and responsive IT teams to deliver quality new applications faster and at scale. 

GitLab Auto DevOps was made to serve this very need. This feature automatically guides code from verification to monitoring, without additional configuration. It also removes bottlenecks within the process, increasing the free flow of ideas between developers.

GitLab is already a critical part of developers‘ software delivery process around the world. With the launch of Auto DevOps, things become even better as they can focus on writing code and business value. Read on as we explore GitLab Auto DevOps in more detail below.

What is GitLab Auto DevOps Anyway?

Auto DevOps in GitLab is a set of pre-configured features and integrations that work in tandem to support and simplify the software delivery process. It auto-sets up the pipeline integration and eliminates the complexities of software delivery, allowing software development teams to focus on business productivity.

Here’s a list of features and integrations you can expect:

  • Examine code language
  • Build and test application
  • Measure good quality
  • Scan and identify vulnerabilities and security flaws
  • Inspect for licensing issues
  • Initiate real-time monitoring
  • Deploy application

Simply put, developers just have to commit their code to GitLab, after which Auto DevOps will take care of building, testing, code quality scanning, security setting, license scanning, packaging, performance testing, deploying, and monitoring their applications.

How GitLab Auto DevOps Works

After you enable Auto DevOps, it’ll detect your code language and use CI/CD templates to build and run default pipelines.

To start, Auto DevOps will build and test your application, and create the necessary jobs to deploy your apps for staging and/or production (this is based on your predefined deployment configuration). Simultaneously, it sets up Review Apps, allowing you to preview changes on a per-branch basis.

You also don’t need to set up the deployment upfront. Auto DevOps will continue building in testing your application, so you can always define deployment later.

Another thing GitLab Auto DevOps eliminates is the hassle of creating entire pipelines manually. Thanks to its simple and iterative approach, you can ship your app and then explore the customizations. Managing Auto DevOps with Apis is also possible.

Here’s a short rundown of how you can give GitLab Auto DevOps a try:

  1. After making a GitLab account, install your license and connect your server.
  2. Connect GitLab to your Kubernetes cluster. In case you don’t have a cluster, you can create one with the GitLab GKE integration.
  3. Once you install CI runners, it’ll enable Auto DevOps. 

And that’s it! Sit back and relax, and GitLab Auto DevOps will do all the work. No manual configurations are needed anymore.

How to Get Started With GitLab Auto DevOps

Luckily, getting started with GitLab Auto DevOps is easier than ever. All you need to do is enable Auto DevOps, and you can run an Auto DevOps pipeline to build and test your application.

Let’s take a look at how it works.

Enable or Disable GitLab Auto DevOps

If you have GitLab self-managed, you can enable or disable Auto DevOps at the project, group, and instance levels. But if you have GitLab SaaS, you can only do it at the project and group level.

Before enabling, we recommend preparing Auto DevOps for deployment. Otherwise, Auto DevOps can build and test your app, but won’t be able to deploy it.

With that out of the way, let’s look at how you can enable or disable Auto DevOps at every level.

At the project level

To use Auto DevOps for individual projects, you have to enable it on a project-by-project basis. Similarly, if you intend to use it for more projects, enable it for a group or an instance. 

The reason we mention this is to help save you the time of enabling it one by one. Remember, project maintainers are the only ones with the authority to enable or disable Auto DevOps at the project level.

Note: Make sure your project doesn’t have a .gitlab–ci.yml present. If it does, your CI/CD configurations will be given preference over the Auto DevOps pipeline.

The following are the steps to enable Auto DevOps for the project:

  1. Navigate to the top menu bar, and select Menu > Projects. Find and click on your project.
  2. On the left sidebar, select Settings > CI/CD.
  3. Expand Auto DevOps, followed by checking the Default to GitLab Auto DevOps pipeline checkbox.
  4. Proceed to add the base domain and choose your deployment strategy. Both the steps are optional but we recommend them.
  5. Finally, click Save changes.

GitLab will then trigger the Auto DevOps pipeline on the default branch. If you want to disable it, simply follow the same process and clear the Default to GitLab Auto DevOps checkbox.

At the group level

Enabling Auto DevOps at the group level means all subgroups and projects in that specific group will inherit the configuration. This helps save a lot of time as instead of enabling each subgroup or project individually, you simply batch enable it. 

Even when enabled for a group, you can still disable Auto DevOps for the subgroups and projects where you don’t want it. Again, only group owners and GitLab admins can enable or disable Auto DevOps at the group level.

The following are the steps to enable Auto DevOps for a group:

  1. Navigate to the top bar. From there, select Menu > Groups, and find your group.
  2. Select Settings > CI/CD on the left sidebar, and expand Auto DevOps.
  3. Check the Default to GitLab Auto DevOps pipeline checkbox.
  4. Click Save changes.

The process is the same to disable Auto DevOps on the group level, where you simply clear the Default to Auto DevOps pipeline checkbox.

After enabling Auto DevOps at the group level, you can trigger the Auto DevOps pipeline for any project belonging to that specific group. Here’s how to go about it:

  1. On the top bar, select Menu > Projects and locate your project.
  2. Check whether the project doesn’t contain the .gitlab–ci.yml file.
  3. On the left sidebar, click CI/CD > Pipelines.
  4. Select Run pipeline to trigger the Auto DevOps pipeline.

At the instance level

When you enable Auto DevOps at the instance level, all projects created in that specific instance become enabled. This is a great move when you want to run Auto DevOps by default for all your projects. Of course, you can still disable Auto DevOps individually for the projects and groups you don’t want to run it—provided you’re the GitLab admin at the instance level. 

The following are the steps to enable Auto DevOps for your instance:

  1. Go to the top menu bar, and select Menu > Projects.
  2. On the left sidebar, click Settings > CI/CD.
  3. Expand Auto DevOps, and check the Default to GitLab Auto DevOps pipeline checkbox.
  4. Although optional, you can add the Auto DevOps base domain here.
  5. Select Save changes.

Note: If a pipeline fails in a specific project, Auto DevOps will disable itself. As a GitLab admin, you can change this in the Auto DevOps settings. If a CI/CD configuration file is present, it’ll remain unchanged and Auto DevOps won’t affect it.

If you want to disable Auto DevOps at the instance level, you’ll have to follow the same process as outlined above, taking care to clear the Default to Auto DevOps pipeline checkbox.

Get a Quick Start

The next step in setting up Auto DevOps is to deploy it to a Kubernetes cluster on the Google Kubernetes Engine (GKE). This is a bit more elaborate for this blog post, so here’s a detailed guide showing you how.

Alternatively, you can follow the quick start for the general steps followed by deploying it to AWS EVS.

Quick start will be different if you’re a self-managed user. Before deploying to GKE, as a GitLab admin, you need to:

  1. Configure the Google OAuth 2.0 OmniAuth Provider.
  2. Configure a cluster on GKE.

Other Helpful Posts to Navigate GitLab

GitLab can feel fairly complicated, especially when you’re a beginner. To help you out, we’ve compiled a list of articles to give you a headstart:

Every company that uses Google Workspace should be using Nira.
Bryan Wise
Bryan Wise,
CIO of GitLab

Incredible companies use Nira