With the continuous method of software development, you continuously build, test, and deploy iterative code changes. This iterative process helps reduce the chance that you develop new code based on buggy or failed previous versions. With this method, you strive to have less human intervention or even no intervention at all, from the development of new code until its deployment.
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. These scripts help decrease the chances that you introduce errors in your application.
This practice is known as Continuous Integration. Each change submitted to an application, even to development branches, is built and tested automatically and continuously. These tests ensure the changes pass all tests, guidelines, and code compliance standards you established for your application.
GitLab itself is an example of a project that uses Continuous Integration as a software development method. For every push to the project, a set of checks run against the code.
Continuous Delivery
Continuous Delivery is a step beyond Continuous Integration. Not only is your application built and tested each time a code change is pushed to the codebase, the application is also deployed continuously. However, with continuous delivery, you trigger the deployments manually.
Continuous Delivery checks the code automatically, but it requires human intervention to manually and strategically trigger the deployment of the changes.
Continuous Deployment
Continuous Deployment is another 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. Human intervention is not required.
GitLab CI/CD workflow
GitLab CI/CD fits in a common development workflow.
You can start by discussing a code implementation in an issue and working locally on your proposed changes. Then you can push your commits to a feature branch in a remote repository that’s hosted in GitLab. The push triggers the CI/CD pipeline for your project. Then, GitLab CI/CD:
- Runs automated scripts (sequentially or in parallel) to:
- Build and test your application.
- Preview the changes in a Review App, the same as you would see on your
localhost.
After the implementation works as expected:
- 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.
If something goes wrong, you can roll back your changes.
A deeper look into the CI/CD workflow
If you look deeper into the workflow, you can see the features available in GitLab at each stage of the DevOps lifecycle.
