First, let’s look into CI/CD meaning so everyone reading this post is on the same page.
CI stands for Continuous Integration. It is a routine that implies constantly adding code into a central repository accessible to all the developers on a team. CD stands for Continuous Delivery and Continuous Deployment. These two allow us to incessantly release the stored in the repo code to production.
Combined, CI and CD create a method to serve apps to users ceaselessly. We achieve this by dividing the whole project into small chunks and applying automation to every stage of app development. CI/CD calls for development and operations teams to work together applying the agile approach.
Why do we choose CI/CD?
Obviously, the first and the most meaningful benefit of CI/CD is the ability to beat the competition and deliver your product to market faster. At the same time, rolling out new features and fixing bugs is just as fast and effective. But the beauty of the CI/CD method is the efficiency with which it eliminates the countless issues new code integration creates for development and operation teams.
Our team used the method for Kör & Launch projects. We applied GitLab CI pipelines for constant integration and delivery on these projects. This way both platforms detect potential errors before they actually occur. And perform smoother integration.
Continuous Integration (CI)
We’ve already described this above, but it never hurts to repeat. CI is a practice that implies all the developers on a team continuously uploading and merging new code with the main codebase. With CI, waiting for the end of a sprint or the whole project to unify all the developers’ work is unnecessary. This helps us eliminate, or at least lessen, the risk of getting ourselves into the “integration hell”.
The first thing you have to do to implement CI for your development process is introduce automatic testing. For every new feature you create, there has to be an automated test. Yes, at the first glance it does seem like this will hinder the development progress. But we checked, and the fact is – automated tests impressively minimise the time we spend on fixing regression and the new bugs in each new iteration. With a well-done test suit in place, you have no doubts that all the already added features work as they should. As a result you can be confident when making new changes to the main code branch.
Of course, there are a lot of test types that can be implemented. We started with unit tests and extended the coverage over time.
Automating the tests is not the end of the journey though. If your developers keep working for days on a feature without adding their modifications to the repo you’ll have to adjust the team culture. Enforcing the green build policy is also a good idea.
Involving your developers in the user stories creation from the very beginning is a brilliant decision as well. This is a great solution to establish the relationship between the developers and product managers. Meanwhile getting the whole team on the same page in understanding the business goals and requirements.
We held a 3-day workshop for the whole Kör team. As a result of that workshop we have well-documented business and project goals, stakeholder groups, user types, all the possible risks (general, tech, and management). And the actual project roadmap. We even created user flow diagrams for every user type we outlined. Here’s how the main student flow looks:
With this many details gathered at the very beginning of a project writing good tests turned out to be so much easier.
Continuous Delivery (CD)
With every new version developed, tested, and safely merged in a git-based repository platform (GitHub, GitLab, and others), the new version of your app can be deployed with just a click. But before it is released into the world you need to make sure your software is ready to be deployed. This is what we call Continuous Delivery.
Continuous delivery has many benefits. The most inspiring among them are speed, productivity, and sustainability.
Surely, you can see that in the modern world the need for speed is critical when it comes to releasing new features. After all, the ideas float around, you can’t be sure your competitors aren’t implementing them while you are still perfecting your code. With automated delivery pipelines we can respond to market changes much more efficiently.
Your team’s productivity increases when the tedious tasks are automated. Writing bug reports can be delegated to pipelines, this way your developers can focus on more important tasks and be more productive.
Finally, sustainability here translates to working smart. By reducing manual labour with automated tools you actually save money. The tools are much cheaper than people after all.
Continuous Deployment (CD)
Continuous Deployment (CD) is a release process in which automated testing is applied to review the code. The validated code is then automatically put out to production.
Continuous deployment is not easy, because it is rather hard to make sure you have implemented exhaustive tests. But if you’ve done your CI properly and your team is committed to it, then CD should not be too big of a problem.
What is a CI/CD Pipeline
The combination of ongoing automation and monitoring we described above is referred to as CI/CD pipeline.
Stages of a CI/CD pipeline
If we logically group the tasks we face when building an application we will get these typical CI/CD pipeline stages:
- build;
- test;
- release;
- deploy;
- validation and compliance.
Of course, the stages may vary depending on the ins and outs of your business and its goals.
This video has a bit more information on the elements of a CI/CD pipeline.
Why Gitlab CI/CD?
When we first decided to implement CI/CD for our projects we faced an unexpected issue. Many of the CI platforms we checked rely on integration with other tools. So to get a full CI/CD experience we’d have to pay for and maintain various separate tools for testing, deployment, security, and monitoring.
You can imagine how happy we were to find out that GitLab supports the full DevOps lifecycle in one environment. Which means that we can use GitLab CI/CD for each of the continuous practices. Without integrating any third-party applications and tools.
In this video of a GitLab CI/CD workshop, you can find all the information you need on GitLab and all of its CI/CD capacities.
GitLab CI/CD workflow
GitLab CI/CD workflow fits perfectly in the typical workflow. First, you discuss the function or a piece of the project you are going to develop and work on it locally. When you are confident in your piece, you push it to a feature repo in GitLab. This triggers the CI/CD pipeline. So GitLab CI/CD runs the automated scripts to build and test the app, the changes are then reviewed in a Review Application.
After your code is deemed working as expected it is reviewed, approved, and then merged with the central repository. GitLab CI/CD automatically deploys the changes to production. You can roll back at any time if something goes wrong.
As you can see from the major steps of GitLab workflow described below, there are absolutely no external tools involved.
What are the Benefits of Each Continuous Practice for Business
Obviously, adopting any new development method will cost you, if not money then time and effort. But the gains from CI/CD largely outweigh the losses.
Continuous integration
To seamlessly integrate CI into your processes your developers will have to merge their work as often as possible. You’ll need a CI server that will automatically supervise the central repo and run the tests. Finally, you’ll have to write the automatic tests for the server to run, for each and every new feature or bug fix.
For all this hard work and resources spent you will get a much smaller amount of bugs leaked out to production. Ideally you won’t have them at all, since regressions are captured automatically and can be fixed early. You won’t face the common integration issues, so building your release will be a lot easier. And you will cut your spending on testing costs and the QA team’s time.
Continuous delivery
Continuous delivery implies that the whole team is committed to CI, the test suit is flawless, and it covers the codebase to a tee. You will need to introduce automation into the deployments. There shouldn’t be any need for human intervention except the manual trigger. And, most likely, your developers will need to come to grips with feature flags. You’ll nee to avoid any incomplete features affecting the production.
Your gains from all of this will include the speed with which you will be able to release your software. The common complexities that usually set us back have been taken care of. The more frequent releases will, in their turn, provide better and more frequent feedback from the users. And you’ll see much less pressure for applying smaller changes.
Continuous deployment
The quality of your tests determines the quality of the releases, so your test suit has to be flawless and exhaustive. Documentation process and coordination with other departments will require more time and attention. But the automatic deployment pipelines mean that you won’t have to hinder the development for every new release. Since you deploy smaller chunks of code, fixing any issues is much easier and far less risky. Most importantly, the users get a never-ending stream of improvements. Your product’s quality gets better every day, not just every quarter.
If you want your product developed fast without compromising on quality Fulcrum Rocks is ready to help!
FAQ: CI/CD pipeline
-
What is CI/CD pipeline?CI/CD pipeline is a method of continuous delivery of applications to end users. This is achieved by dividing the project into small chunks and applying automation to every stage of app development.
-
What are CI/CD tools?The tools to implement continuous automation and continuous monitoring throughout the lifecycle of applications. Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo, Travis CI, Codeship are just a few of the CI/CD tools we can name.
-
What does CI/CD stand for?CI/CD stands for Continuous Integration, Continuous Delivery, and Continuous Deployment.
