Okay so what the hell is CI/CD anyways ??

My Promise to you guys

Look i promise you that each blog i write will be simple to understand because my language in each of these blogs will be exactly like how we all speak in real life. I won't even try to impress you with jargon that no one can keep in mind, so stay with me guys! i understand the pain developers and coders go through when they start learning something new, but they give up because every blog is just bunch of jargon and very abstractive.

This blog is a part of my hashnode blog series CI/CD in Github Actions. So if you are eager to learn CI/CD specifically in github-actions this is the best series for you. You will master CI/CD in github actions blog by blog.

So just keep in touch with my github-actions series here -> CI/CD in Github Actions

Life before CI/CD

So before developers (who code application) and operations people (the people who deploy application on cloud and maintain its smooth working) had these automated CI/CD and devops pipelines, they used to :

• Write code for application (still do it),
• Then write test cases for their written code manually (still do it),
• After this they would push this code to their github repository manually (still do it).
• Then they would take their complete github repository code and build it manually (still do it).
• Then they would take this "build" code and deploy it on cloud platforms like either aws, azure, gcp or digital ocean etc.

Not to mention these are just small list of steps they went through, in real life it is very more complex. This was all manual work. Then after this if anything went wrong they would again spend hours and hours doing manual work to fix everything up. Like checking if testing was wrong or setting up the project on aws, azure etc. was wrong or code had a bug or whatever.

Automation was 0, social coding was 0, culture and mindset required to reduce this pain was 0. Everything was a mess. Developers and operations people in company and other teams in a company has no or nearly 0 zero discussion with each other about how to come together and reduce all of this workload. Developers had no idea what the hell operations people or other teams in the company are doing, operations people had no idea what the hell developers are coding or making and so on. So cultural lack and wrong mindset was what keeping thing slow and messy in mostly every company.

This was a tip of the iceberg of problems that developers and IT operations people and other teams had in their day in the life of coding and maintaining a application in their organization.

Introduction to CI/CD

Okay so in simple words explain what is ci/cd ?

"CI/CD means automation of pre-existing repetitive tasks while coding a application/software/website/framework/library/package etc. (no matter how complex it is). It automates most of the operations team's tasks."

Example of why CI/CD is very important

Let's say you and your other 4 friends are making a application named "Taxi-Anywhere". This app can be used by people to book a cab anywhere they want. Now you have a github repository where all of you 5 people are pushing your code to.

You 5 guys plan a new feature to add in your app, You 5 guys write your code to make some new feature or whatever, You guys already have your testing scripts that tests your written code, you guys push your new code to github, you guys have scripts to "build" your code, you guys have a subscription of some cloud provider like AWS or AZURE where you deploy this build code. Now users are using your application now with the new features. It takes months and months to do all of this because here is 0 automation.

Here are the most common repetitive tasks that you guys face literally every single day:

• You guys have to run the testing scripts 'manually'. It is very time consuming.
• You guys have to run the build scripts 'manually'. It is very time consuming.
• You guys have to deploy the code to AWS or AZURE 'manually'. It is really very time consuming.
• All of this increases your workload and decreases your speed to make your new features available to the users. You know these repetitive tasks hinder your development process and make you slow. The time wasted in running these scripts and deploying code etc. can be utilized in planning the new features and coding and other important stuff.

This is why you need devops and specifically CI/CD.

How exactly CI (Continuous Integration) and CD (Continuous Delivery) look in practice and code?

Before understanding any thing else, just keep in mind CI/CD is just multiple files in our project folder in which we code using (YAML, groovy etc.) languages. These files then run and automatically do whatever we have defined in them.

So these CI/CD code files run automatically and reduce our workload, letting developers and operations team focus on important tasks and new features rather than fixing the mess that doesn't contribute to company's growth and financial state.

So one very simple example can be that imagine we have one CI/CD file (in complex project we have multiple ci/cd files) in which we have written some code that does these 3 things:

• First the code is tested automatically.
• Then the code is build automatically.
• Then the code is deployed automatically to cloud providers like aws, gcp, azure etc.

We didn't need to manually do these tasks as CI/CD tools automatically handles all of this. We will discuss popular CI/CD tools later in this blog.

Continuous Integration (CI)

• Continuous Integration means continuously integrating (pushing) your code to the main branch of your github repository (or it can be any other online repository provider like GitLab). We write small and functional code and make several pushes to the project repository on github or other platforms.
• CI is a automation process in which these steps : plan, code, built, test are automated. So, a new feature is planned, its solution is coded, code is build, then testing is performed. Remember that planning a feature and coding the feature are manual steps but still they are considered part of CI. Automated steps are testing the code and building the code.
• CI allows various teams to collaborate on the project where each team can frequently integrate their code to the repository.
• CI allows to find integration bugs sooner. As code is deeply tested in CI we find bugs way earlier rather than finding bugs when the code is deployed to cloud.

CI is a development practice where developers regularly merge their code changes into a shared repository on github or other platforms. Each code integration (push) is automatically verified by running automated tests and builds in CI/CD files, ensuring that new code changes do not break the existing code in repository. This approach leads to early detection of bugs and issues and facilitates collaboration between all team members.

Continuous Delivery (CD)

• Continuous delivery means deploying your integrated build code somewhere, you may deploy your code everytime you integrate it or you may not deploy your code everytime you integrate it.
• CD is a automation process that comes after CI and in CD these steps : release, deploy, operate are automated. So solution is released, binaries (build code, artifacts etc.) are deployed to production-like environment, then application is operating live.
• CD doesn’t always deploy the code to main production environment for safety, CD deploy the code to “production like” environment. Like it can be pre-production environment, testing environment, development environment etc.
• If you don't know production environment means the code here is being server to real users who are using our app or website, this is the code that people are using, this is why before deploying the code straight away to production environment, teams deploy their code to the production-like environment where no real world users are using it but only company members or small set of test users are using it.

Continuous Delivery (CD) takes the concept of CI a step further by automatically deploying every change that passes the automated tests to a "production-like" environment. This means that any change that successfully passes through the CI pipeline can be immediately available to some test users like team members.

Continuous Deployment (the less known CD)

• I know this second CD might have confused you because it is CI/CD not CI/CD/CD. But actually it is. We have continuous delivery and continuous deployment also. It makes confusion but remember we have one more CD this C-Deployment is for serving application to the end-users.
• Continuous deployment is a automation process in which code is always deployed to the real production environment and now end-user the real people in world are using our app.
• Continuous Deployment is actually different from Continuous Delivery because in Continuous Delivery code is deployed to either testing environment or dev environment or pre-production environment. But in Continuous Deployment code is actually always being deployed to the real production environment which is being served to end users.
• Before Continuous Deployment.. comes Continuous Delivery and before Continuous Delivery.. comes Continuous Integration. So in step wise fashion we do CI first then CD (D: Delivery) then CD (D: Deployment).

CI/CD pipeline in code

• Just to help you imagine what the CI/CD looks to eyes in code here is the real code example i wrote. Please dont be scared when you watch this lengthy code. It might look scary now but after completing my blog series on hashnode -> CI/CD in Github Actions you will not be scared anymore.
• So here is the CI/CD code in github-actions, just taste it don't be scared, this is what CI/CD people write :

name: Deployment
  
on:
    push:
      branches:
        - main
        - dev
  
env: # globally available to every job
    MONGODB_DB_NAME: ga-sixth-workflow-env-secrets-database
  
jobs:
    test: # job 1
      environment: testing
      env:
        MONGODB_CLUSTER_ADDRESS: ${{ secrets.MONGODB_CLUSTER_ADDRESS }}
        MONGODB_USERNAME: ${{ secrets.MONGODB_USERNAME }}
        MONGODB_PASSWORD: ${{ secrets.MONGODB_PASSWORD }}
        PORT: 8080
      runs-on: ubuntu-latest
      steps:
        - name: Get Code
          uses: actions/checkout@v4
        - name: Cache dependencies
          uses: actions/cache@v4
          with:
            path: ~/.npm
            key: npm-deps-${{ hashFiles('**/package-lock.json') }}
        - name: Install dependencies
          run: npm ci
        - name: Run server
          run: npm start & npx wait-on https://127.0.0.1:$PORT
        - name: Run tests
          run: npm test
        - name: Output information
          run: echo "MONGODB_USERNAME:${{ env.MONGODB_USERNAME }}"
    deploy: # job 2
      needs: test
      runs-on: ubuntu-latest
      steps:
        - name: Output information
          run: |
            echo "MONGODB_USERNAME:${{ env.MONGODB_USERNAME }}"
            echo "MONGODB_DB_NAME:${{ env.MONGODB_DB_NAME }}"        

• This code is from my github, here is my github account:

My Github (navraj singh dev)

Benefits of CI/CD

Implementing CI/CD in your development workflow brings a plethora of benefits:

1. Enhanced Code Quality

Regular integration and automated testing catch bugs early, ensuring higher code quality and more stable software releases.

2. Faster Time to Market

By automating the build, test, and deployment of code, CI/CD significantly reduces the time it takes to release new features and updates.

3. Reduced Manual Effort

Automation minimizes the manual effort required for building, testing, and deploying code, allowing developers to focus on writing code and innovating.

4. Improved Collaboration

CI/CD is a culture of collaboration and transparency among team members, as everyone works on a shared codebase with continuous feedback on code changes.

5. Increased Deployment Frequency

With automated deployments, organizations can release updates more frequently, responding quickly to market demands and customer feedback.

Tools for CI/CD

Several tools are available to help implement CI/CD in your workflow. Here are some of the most popular ones:

1. Jenkins

Jenkins is an open-source automation CI/CD tool widely used for building, testing, and deploying software. It is the most oldest tool that is still popular today. Jenkins is good for CI but doing CD in jenkins is not a good idea as it not primarily a CD tool. Jenkins is a powerful tool for CI, but for complex CD workflows, other dedicated CD tools might offer a more better experience. Jenkins rely heavily on plugins.

2. Travis CI

Travis CI is a cloud-based CI service that integrates with GitHub repositories. It provides a straightforward setup process and is known for its ease of use. It has paid and free plans. I would say good for CI but average for CD there are better tools.

3. CircleCI

CircleCI offers both cloud-based and self-hosted options. It supports multiple languages like ruby, python etc. and frameworks, in today modern devops this is a highly emerging tool. Many companies are interested in using till tool today.

4. GitHub Actions

GitHub Actions is a powerful automation tool integrated directly into GitHub. It is made by github for github. It is mostly free and one of the most sky-rocketing CI?CD tool in today devops market. This tool is in high demand and many companies are shifting toward it. It allows you to create CI/CD files called workflows. It is personally used by me and this is what i will teach from zero to hero in this complete CI/CD series on hashnode. It is very complete CI and also CD tools, as i said most previous tools were not that good in CD but this one is good in CD also.

Again i am not criticizing any tool, any tool can perform both CI/CD but it is just about little things like compatibility, pricing, features and other parameters. So if i use github-action doesn't mean you have to.. you can use jenkins or other ones.

Where CI/CD Fits in the DevOps Pipeline

We know CI/CD is a part of devops as a whole, so where does CI/CD come under devops lifecycle itself.

To understand where CI/CD fits in the DevOps pipeline, let's take a closer look at the stages involved in a typical DevOps workflow:

1. Build

The build stage involves compiling the source code into executable artifacts. CI tools automatically build the application whenever new code is integrated, ensuring that the code can be successfully built in various environments.

2. Test

Automated tests are run to verify the functionality and correctness of the code. CI ensures that these tests are executed for every code change, catching bugs early in the development process.

3. Deploy

CD automates the deployment of tested and verified code to various environments, including staging and production. This ensures a consistent and repeatable deployment process.

4. Monitor

Once the code is deployed, monitoring tools keep an eye on the application's performance and health. Any issues detected are fed back into the development process for quick resolution.

5. Feedback

Continuous feedback from monitoring tools, user reports, and automated tests helps developers improve the software continuously. This feedback loop is crucial for maintaining high-quality software and quickly addressing issues.

CI/CD integrates into this pipeline by automating the build, test, and deploy stages, ensuring that code changes are continuously integrated, tested, and deployed with minimal manual intervention.

Daily Life Examples of CI and CD

To illustrate the impact of CI and CD, let's look at some real-world examples:

Code Reviews (CI)

Code reviews are an integral part of CI. Every time a developer submits a pull request (like on github), automated tests run.. and verify the changes. This ensures that code reviews focus on code quality and design, rather than manual testing.

Automated Testing (CI)

Automated tests, including unit tests, integration tests, and end-to-end tests, are executed as part of the CI process. This ensures that any code changes do not break existing functionality.

Deployment to Production (CD)

With CD, any code that passes automated testing can be automatically deployed to production. This means that new features, bug fixes, and improvements are available to users as soon as they are ready, without manual intervention.

Monitoring and Feedback (CD)

Once deployed, monitoring tools continuously check the application's performance and health. Any issues detected are fed back to the development team, enabling quick resolution and continuous improvement.

Conclusion

Incorporating CI/CD into your development workflow is a game-changer. It enhances code quality, speeds up time to market, reduces manual effort, and builds better collaboration among team members. By automating the build, test, and deploy processes, CI/CD ensures that your software is always in a releasable state, allowing you to deliver value to your users continuously.

Whether you're a small startup or a large enterprise, the benefits of CI/CD are undeniable. Embrace these practices, choose the right tools for your needs, and watch your development process transform into a well-oiled machine.

My social handles guys, follow me

My Twitter (X)

My LinkedIn

My GitHub

#github #git #cicd #ci-cd #githubactions #navraj #kubernetes #devops #continuousintegration #continousdelivery