During the development of software, there can be many stages until it's ready for public consumption.
You sure want to
* first test your code and then deploy it in a testing or staging environment (Continuous Delivery)
* before you release it to the public (Continuous Deployment).
That way you can prevent bugs not only in your software, but in the deployment process as well.
You sure want to first test your code and then deploy it in a testing or staging environment before you release it to the public. That way you can prevent bugs not only in your software, but in the deployment process as well.
If the deployment to production is defined strategically and triggered manually we are talking about Continuous Delivery. Continuous Deployment is a software development practice in which every code change goes through the entire pipeline and is put into production automatically ([CI vs. CD vs. CD](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/)).
| **Note:** If the deployment to production is defined strategically and triggered manually we are talking about **Continuous Delivery**.
GitLab CI is capable of not only testing or building your projects (Continuous Integration (CI)), but also delivering/deploying them in your infrastructure, with the added benefit of giving you a way to track your deliverys/deployments. In other words, you can always know what is currently being delivered/deployed or has been delivered/deployed on your servers.
GitLab CI is capable of not only testing or building your projects (Continuous Integration (CI)), but also deploying them with the strategy of Continuous Delivery or Continuous Deployment in your infrastructure. This enables a way to track your deployments. In other words, you can always know what is currently being deployed or has been deployed on your servers and you can even roll it back, if major bugs are found.
