5.9 KiB
| stage | group | info | description | type |
|---|---|---|---|---|
| Verify | Continuous Integration | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments | An overview of Continuous Integration, Continuous Delivery, and Continuous Deployment, as well as an introduction to GitLab CI/CD. | concepts |
Introduction to CI/CD concepts (FREE)
This document introduces the concepts of Continuous Integration, Continuous Delivery, Continuous Deployment, and GitLab CI/CD.
NOTE: Out-of-the-box management systems can decrease hours spent on maintaining toolchains by 10% or more. Watch our "Mastering continuous software development" webcast to learn about continuous methods and how the GitLab built-in CI can help you simplify and scale software development.
- Learn how to configure CI/CD.
- Make the case for CI/CD in your organization.
- Learn how Verizon reduced rebuilds from 30 days to under 8 hours with GitLab.
Introduction to CI/CD methodologies
The continuous methodologies of software development are based on automating the execution of scripts to minimize the chance of introducing errors while developing applications. They require less human intervention or even no intervention at all, from the development of new code until its deployment.
It involves continuously building, testing, and deploying code changes at every small iteration, reducing the chance of developing new code based on bugged or failed previous versions.
There are three main approaches to this methodology, each of them to be applied according to what best suits your strategy.
Continuous Integration
Consider an application that has its code stored in a Git repository in GitLab. Developers push code changes every day, multiple times a day. For every push to the repository, you can create a set of scripts to build and test your application automatically, decreasing the chance of introducing errors to your app.
This practice is known as Continuous Integration; for every change submitted to an application - even to development branches - it's built and tested automatically and continuously, ensuring the introduced changes pass all tests, guidelines, and code compliance standards you established for your app.
GitLab itself is an example of using Continuous Integration as a software development method. For every push to the project, there's a set of scripts the code is checked against.
Continuous Delivery
Continuous Delivery is a step beyond Continuous Integration. Your application is not only built and tested at every code change pushed to the codebase, but, as an additional step, it's also deployed continuously, though the deployments are triggered manually.
This method ensures the code is checked automatically but requires human intervention to manually and strategically trigger the deployment of the changes.
Continuous Deployment
Continuous Deployment is also a further step beyond Continuous Integration, similar to Continuous Delivery. The difference is that instead of deploying your application manually, you set it to be deployed automatically. It does not require human intervention at all to have your application deployed.
Introduction to GitLab CI/CD
GitLab CI/CD is a powerful tool built into GitLab that allows you to apply all the continuous methods (Continuous Integration, Delivery, and Deployment) to your software with no third-party application or integration needed.
For an overview, see Introduction to GitLab CI from a recent GitLab meetup.
Basic CI/CD workflow
Consider the following example for how GitLab CI/CD fits in a common development workflow.
Assume that you have discussed a code implementation in an issue and worked locally on your proposed changes. After you push your commits to a feature branch in a remote repository in GitLab, the CI/CD pipeline set for your project is triggered. By doing so, GitLab CI/CD:
- Runs automated scripts (sequentially or in parallel) to:
- Build and test your app.
- Preview the changes per merge request with Review Apps, as you
would see in your
localhost.
After you're happy with your implementation:
- Get your code reviewed and approved.
- Merge the feature branch into the default branch.
- GitLab CI/CD deploys your changes automatically to a production environment.
- And finally, you and your team can easily roll it back if something goes wrong.
GitLab CI/CD is capable of doing a lot more, but this workflow exemplifies the ability of GitLab to track the entire process, without the need for an external tool to deliver your software. And, most usefully, you can visualize all the steps through the GitLab UI.
A deeper look into the CI/CD workflow
If we take a deeper look into the basic workflow, we can see the features available in GitLab at each stage of the DevOps lifecycle, as shown in the illustration below.
