1f708ebb66
The 'master' branch name is confusing as it indicates some special branch name, where it is actually just a 'ref'. 'branches' _is_ a special name as it indicates 'all' branches. Lets clarify the example a little to indicate this. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> |
||
|---|---|---|
| .. | ||
| autodeploy | ||
| build_artifacts | ||
| caching | ||
| chatops | ||
| docker | ||
| examples | ||
| img | ||
| interactive_web_terminal | ||
| introduction | ||
| merge_request_pipelines | ||
| permissions | ||
| quick_start | ||
| review_apps | ||
| runners | ||
| services | ||
| ssh_keys | ||
| triggers | ||
| variables | ||
| yaml | ||
| enable_or_disable_ci.md | ||
| environments.md | ||
| git_submodules.md | ||
| junit_test_reports.md | ||
| pipelines.md | ||
| README.md | ||
| comments | description |
|---|---|
| false | Learn how to use GitLab CI/CD, the GitLab built-in Continuous Integration, Continuous Deployment, and Continuous Delivery toolset to build, test, and deploy your application. |
GitLab Continuous Integration (GitLab CI/CD)
GitLab CI/CD is GitLab's built-in tool for software development using continuous methodology:
- Continuous integration (CI).
- Continuous delivery and deployment (CD).
Within the DevOps lifecycle, GitLab CI/CD spans the Verify (CI) and Release (CD) stages.
Overview
CI/CD is a vast area, so GitLab provides documentation for all levels of expertise. Consult the following table to find the right documentation for you:
| Level of expertise | Resource |
|---|---|
| New to the concepts of CI and CD | For a high-level overview, read an introduction to CI/CD with GitLab. |
| Familiar with GitLab CI/CD concepts | After getting familiar with GitLab CI/CD, let us walk you through a simple example in our getting started guide. |
| A GitLab CI/CD expert | Jump straight to our .gitlab.yml reference. |
Familiarity with GitLab Runner is also useful because it is responsible for running the jobs in your CI/CD pipeline. On GitLab.com, shared Runners are enabled by default so you won't need to set this up to get started.
CI/CD with Auto DevOps
Auto DevOps is the default minimum-configuration method for implementing CI/CD. Auto DevOps:
- Provides simplified setup and execution of CI/CD.
- Allows GitLab to automatically detect, build, test, deploy, and monitor your applications.
Manually configured CI/CD
For complete control, you can manually configure GitLab CI/CD.
Usage
With basic knowledge of how GitLab CI/CD works, the following documentation extends your knowledge into more features:
| Topic | Description |
|---|---|
| Introduction to pipelines and jobs | Provides an overview of GitLab CI/CD and jobs. |
| CI/CD Variables | How environment variables can be configured and made available in pipelines. |
| Where variables can be used | A deeper look into where and how CI/CD variables can be used. |
| User and job permissions | Learn about the access levels a user can have for performing certain CI actions. |
| Configuring GitLab Runners | Documentation for configuring GitLab Runner. |
| Introduction to environments and deployments | Learn how to separate your jobs into environments and use them for different purposes like testing, building and, deploying. |
| Job artifacts | Learn about the output of jobs. |
| Cache dependencies in GitLab CI/CD | Discover how to speed up pipelines using caching. |
| Using Git submodules with GitLab CI | How to run your CI jobs when using Git submodules. |
| Pipelines for merge requests | Create pipelines specifically for merge requests. |
| Using SSH keys with GitLab CI/CD | Use SSH keys in your build environment. |
| Triggering pipelines through the API | Use the GitLab API to trigger a pipeline. |
| Pipeline schedules | Trigger pipelines on a schedule. |
| Connecting GitLab with a Kubernetes cluster | Integrate one or more Kubernetes clusters to your project. |
| ChatOps | Trigger CI jobs from chat, with results sent back to the channel. |
| Interactive web terminals | Open an interactive web terminal to debug the running jobs. |
GitLab Pages
GitLab CI/CD can be used to build and host static websites. For more information, see the documentation on GitLab Pages, or dive right into the CI/CD step-by-step guide for Pages.
Examples
GitLab provides examples of configuring GitLab CI/CD in the form of:
- A collection of examples and other resources.
- Example projects that are available at the
gitlab-examplesgroup. For example, see:multi-project-pipelinesfor examples of implementing multi-project pipelines.review-apps-nginxprovides an example of using Review Apps.
Administration
As a GitLab administrator, you can change the default behavior of GitLab CI/CD for:
- An entire GitLab instance.
- Specific projects, using pipelines settings.
See also:
Using Docker
Docker is commonly used with GitLab CI/CD. Learn more about how to to accomplish this with the following documentation:
| Topic | Description |
|---|---|
| Using Docker images | Use GitLab and GitLab Runner with Docker to build and test applications. |
| Building Docker images with GitLab CI/CD | Maintain Docker-based projects using GitLab CI/CD. |
Related topics include:
Why GitLab CI/CD?
The following articles explain reasons to use GitLab CI/CD for your CI/CD infrastructure:
See also the Why CI/CD? presentation.
Breaking changes
As GitLab CI/CD has evolved, certain breaking changes have been necessary. These are:
- CI variables renaming for GitLab 9.0. Read about the deprecated CI variables and what you should use for GitLab 9.0+.
- New CI job permissions model. See what changed in GitLab 8.12 and how that affects your jobs. There's a new way to access your Git submodules and LFS objects in jobs.