Getting started with CI/CD

Getting started with CI/CD

Getting started with CI/CD

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.

Image1-97.webp

The requirement for CI/CD

Continuous integration is a coding philosophy and set of practices that drive development teams to frequently implement small code changes and check them in to a version control repository. Most modern applications require developing code using a variety of platforms and tools, so teams need a consistent mechanism to integrate and validate changes. Continuous integration establishes an automated way to build, package, and test their applications. Having a consistent integration process encourages developers to commit code changes more frequently, which leads to better collaboration and code quality.

wsi-imageoptim-Screen-Shot-2021-04-19-at-11.webp

Continuous delivery picks up where continuous integration ends, and automates application delivery to selected environments, including production, development, and testing environments. Continuous delivery is an automated way to push code changes to these environments.

a-world-with-ci.cd-meme.jpg

How continuous integration improves collaboration and code quality

Continuous integration is a development philosophy backed by process mechanics and automation. When practicing continuous integration, developers commit their code into the version control repository frequently; most teams have a standard of committing code at least daily. The rationale is that it’s easier to identify defects and other software quality issues on smaller code differentials than on larger ones developed over an extensive period. In addition, when developers work on shorter commit cycles, it is less likely that multiple developers will edit the same code and require a merge when committing.

Teams implementing continuous integration often start with the version control configuration and practice definitions. Although checking in code is done frequently, agile teams develop features and fixes on shorter and longer timeframes. Development teams practicing continuous integration use different techniques to control what features and code are ready for production.

ci-cd-tools.webp

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.

meeseks.webp

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.

0_b66VkqYd8clNNNhh.jfif

Thanku My Profiles Connect with me on

Github

Linkedin

Twitter