Can you imagine having Continuous Integration, Continuous Delivery, and Continuous Deployment within the same web interface? With GitLab, you can!
After a brief introduction to these topics, and a short walk through of some use-cases for these development practices, we'll present you with a video illustrating the capability of going from idea to production faster with GitLab. Check how you can easily deploy your app automatically from GitLab to Docker Cloud.
Continuous Integration is a software development practice in which you build and test software every time a developer pushes code to the application, and it happens several times a day.
Continuous Integration: TEST - BUILD
For example, our developers push code to GitLab CE and GitLab EE every day, multiple times per day. For every commit, we use GitLab CI to test and build our software. We run unit tests to make sure some change didn't break other parts of the software. Every push triggers multiple tests, making it easier to identify where the error is, when a test happens to fail. But we do not deploy to production often, making both GitLab CE and EE cases of Continuous Integration only.
Continuous Delivery is a software engineering approach in which continuous integration, automated testing, and automated deployment capabilities allow software to be developed and deployed rapidly, reliably and repeatedly with minimal human intervention. Still, the deployment to production is defined strategically and triggered manually.
Continuous Delivery: TEST - BUILD - - DEPLOY
Continuous Deployment is a software development practice in which every code change goes through the entire pipeline and is put into production automatically, resulting in many production deployments every day. It does everything that Continuous Delivery does, but the process is fully automated, there's no human intervention at all.
Continuous Deployment: TEST - BUILD - - DEPLOY
For example, our website about.GitLab.com, is continuously deployed. We commit multiple times a day to feature-branches, and every push triggers a parallel test and build. Every time we merge to the
master branch (and we do that a lot, every day), the code is tested, built, and deployed to the production environment, passing through the entire pipeline. There's no further manual action that triggers the deployment: it is an automated process, controlled by GitLab CI.
Perforce performed a study that revealed that most of the companies surveyed are using Continuous Delivery methods to ship their products:
The study indicates that Continuous Delivery has really taken off: 65% say their companies have migrated at least one project/team to Continuous Delivery practices.
80% of SaaS companies are doing Continuous Delivery, compared to 51% of non-SaaS companies (like boxed or on-premise software, embedded systems or hardware, industrial goods, etc.)
Nearly everyone agrees on the vital role of the collaboration platform (version management, build automation, code review, etc.) in achieving Continuous Delivery. 96% said it’s important and 40% said it’s critical. No argument here.
And they raised an interesting question:
What’s the hardest thing about Continuous Delivery?
The answer was:
For non-SaaS companies, it’s getting automation technologies to integrate.
Well, with GitLab, you have all of this, fully-integrated into one single UI. From GitLab 8.10 on, you can perform Manual Actions and manually deploy your application with the click of a button, making Continuous Delivery easier than ever. Take a look.
You can manually deploy to staging:
You can also manually deploy to production:
And you are free to rollback to the previous state with the click of a button:
Our Head of Product, Mark Pundsack, created a demonstration which illustrates our built-in capabilities with GitLab CI, Continuous Deployment, and Container Registry together, to develop faster from idea to production.
In his video, you can see how it's possible, within one single interface (GitLab), to do everything:
The most amazing thing is, you can track the entire process. Everything is fully-integrated with GitLab already; you don't need any other tools to deliver your software, nor jump between different applications and interfaces to track the process.
The full spectrum is clearly visible: the issue, the commits to the merge request, the reviews, the builds, the tests, the deploys, the deployment history, the container history, the environments and the pipelines.
Furthermore, for this example demo configuration, every time you push code to the repository, even if it's to feature-branches, the pipeline runs from build to deployment. But instead of deploying to production, these branches deploy to a staging environment. Production is only affected by the
For this particular case, Mark used Docker Cloud to deploy his app, but you are free to use your creativity to optimize your software development process with GitLab and its built-in development tools.
Check it out, it's awesome!
Note: we assume you know what Docker is, how to use it and how to deploy an app to Docker Cloud.
There's a complete overview on this demo in our Handbook, in case you want to reproduce Mark's steps.
The terms Continuous Delivery and Continuous Deployment are confusing, but now hopefully you understand the difference between them. The goal is pushing code frequently, and having it tested, built, and deployed. If you prefer having the human decision before deploying to production, GitLab allows you to do that with Manual Actions. If you want a fully-automated process, with GitLab you can do that too. Whatever strategy your company chooses, GitLab does the job, and does it well!
Our development team works hard to offer the best solution on modern software development tools and techniques. We ship a new version once a month, every 22nd, with more features and improvements, for making development faster and better.
GitLab is unique: we go from idea to production using one single interface that integrates all the tools we need!
Follow @GitLab on Twitter and stay tuned for updates!