CI/CD is a continuous method of software development, where you continuously build, test, deploy, and monitor iterative code changes.
This iterative process helps reduce the chance that you develop new code based on buggy or failed previous versions. GitLab CI/CD can catch bugs early in the development cycle, and help ensure that all the code deployed to production complies with your established code standards.
If you’re new to GitLab CI/CD, start by reviewing some of the commonly used terms.
To use GitLab CI/CD, you start with a
.gitlab-ci.yml file at the root of your project.
In this file, you specify the list of things you want to do, like test and deploy your application.
This file follows the YAML format and has its own special syntax.
You can name this file anything you want, but
.gitlab-ci.yml is the most common name.
Use the pipeline editor to edit the
.gitlab-ci.yml file and test the syntax before you commit changes.
Create your first
View all the possible keywords that you can use in the
Runners are the agents that run your jobs. These agents can run on physical machines or virtual instances.
.gitlab-ci.yml file, you can specify a container image you want to use when running the job.
The runner loads the image and runs the job either locally or in the container.
If you use GitLab.com, free shared runners are already available for you. And you can register your own runners on GitLab.com if you’d like.
If you don’t use GitLab.com, you can:
- Register runners or use runners already registered for your self-managed instance.
- Create a runner on your local machine.
Pipelines are made up of jobs and stages:
- Jobs define what you want to do. For example, test code changes, or deploy to a staging environment.
- Jobs are grouped into stages. Each stage contains at least one job.
Typical stages might be
CI/CD variables help you customize jobs by making values defined elsewhere accessible to jobs.
They can be hard-coded in your
.gitlab-ci.yml file, project settings, or dynamically generated