“It is worth emphasizing that branching by feature is really the antithesis of continuous integration, and all of our advice on how to make it work is only about ensuring that the pain isn’t too horrible come merge time.”
― David Farley
This Thursday (21st April, 2022) we had an amazing Discord event with our community. The event was about "Getting started with CI/CD." Our community member, Cyimana Faisal, helped us understand the topic and what its needs are in organizations. Check out the slides of the session.
What is CI/CD?
CI/CD stand for Continuous Integration and Continuous Deployment. Continuous integration is responsible for running a build routine every time there is some change/feature update in the codebase. Continuous Deployments are responsible for the delivery of the latest copy of code.
The requirement for CI/CD
- Small but regular progress in the coding timeline
- More reliability in the code through testing
- Less time is needed for project release.
- Simple upkeep and upgradation
- It is easier to resist change.
How it works
Stage 1: Coding 🧑🏽💻
At this stage, developers code their business logic to make new features a reality. After this, some developers are confident about their code, but for others, only God knows how their code works. 😅😆. In either case, the code needs to be inspected before being deployed to production.
Stage 2: CI pipeline ⚒️
This stage is responsible for testing the code in view of the latest changes. When new commits are made to the codebase, this CI pipeline gets triggered.
It builds, runs unit tests and integration tests. It ensures the code is working as expected and tries to match the desired output of specific parts of the code to their present output.
After passing unit tests, it is tested for integration. While integrating applications, there are issues with compatibility of various versions of dependencies with each other. These conflicts are identified in the integration tests. After this step, our code is ready to ship.
Stage 3: CD pipeline 🚢
This pipeline gets triggered after the CI pipeline is done executing. A new compiled application is made from the newly pushed changes. Here, it is recommended to follow various staging environments for our code. Generally, there are three environments:
1) Development:- This environment is for experimenting, where you can try to test out new features with preferably dummy data. Whatever you do here won't affect your clients as these changes here won't be reflected in the final deployment.
2) Staging:- This environment is almost identical to production. You can try to integrate your actual data here and do more intense testing of new features. This environment can help clients understand how features will finally be there and what their outcome will be. This environment too has no effect on the final deployment.
3) Production:- This environment is the home to the final deployment of your project, so it's the most important one too. After ensuring proper testing in both the previous environments , only the changes that are made live in production.
These different environments give developers freedom to experiment and also ensure an efficient development approach.
Finally after all these stages , the code is shipped and new changes become live.
Get your hands dirty
To understand CI/CD, you can take the help of various platforms and tools like Jenkins, CircleCI, Teamcity, Bamboo, Gitlab, Buddy, Travis CI, and many more.
The best way is to try out and learn concepts by implementing them
I hope you liked it😊. The right time to begin is now, so get started and be a better version of yourself. Join us every Thursday for more amazing events; we'll be waiting in the lounge. Come join our Discord now!