CI/CD Pipeline

CI/CD stands for Continous Integeration and Continous Deployment. While working with github, you must have heard about it. When you have the code deployed on the github, you make some changes in it and you deploy it again. but everytime you deploy it on github there are some commands you always run and check if the code is working or not? if there are linting errors? or you perform some tests before deploying it on github, you dont want to push the code faulty right? so we can use the continous integration for this. how? we will leter see in this article. After the code is pushed, we also want it to be directly deployed on the platform of deployment which provides the deployment services. how? the deployment is done in the CD pipeline/workflow. so combining these two makes it Continous Integration and Continous Deployement.

So before knowing how these CI/CD Pipeline Works, you should know some keywords regarding it.

Continous Integration:

So as we discussed the Continous Integration is the process of validating and Testing the Code when deployed on github.
We prepare a workflow of how & which sequence of commands/steps to perform while pushing the code to repo.

Continious Deployment:

Continous Deployment is the process of deploying it to a pushed code automatically to the deployment platform, so dont have to manually check everytime.

Some of the keywords that we will be using in it:

on: its used to indicate when to trigger/use this workflow. for example: push, pull_requests etc..
push, pull_requets: these are actions on the github.
branches: on which branch the operations are performed then trigger the workflow.
jobs: jobs are nothing but the sequence of commands/steps to perform and are mentioned. it will execute the steps/commands in the order which they are written.
build: build is use to indicate that workflow will create a dev build which is going to be integrated in the current flow, build consists of the steps to be performed and on which OS the system will perform the build etc..
runs_on: indicates which OS the machine of github will use to perform the ci & cd. ex: ubuntu-latest
steps: these are the sequence of the steps that will be executed. each step will have
- name: which indicates the name of the step.
- run: provide command here, which command to run.
- uses: we can provide the github actions which are created by the people on the internet.
- with: its used to pass the arguments the actions.
Github Actions: These are nothing but the sequence of commands/steps written by the official vendor devs or the people on the internet and deployed on the github so that you dont have to rewrite the logic of that action, you cna just mention, uses: actions/xyz. for example - you can use the uses: actions/checkout@v3, now this checkout action is used to copy the content of your repo into the OS of the machine which is building in this workflow. so this action simply just copies the files of your repo before the push of the latest code like previous code, into the described OS for integration of the codebase.

Now lets see how can we create a simple ci/cd workflow:

You have to first initialize your empty repo and set it up.

for example:

npx create-next-app@latest

now in the root of your repo:

create a .github folder
create workflows folder.
create a .yaml or .yml file. for example - ci.yaml

in the ci.yaml:

name: <Workflow name(Continous Integration)>

on:
    push:
        branches: [main]

    pull_requests:
        branches: [main]

jobs:
    builds:
        runs_on: ubuntu-latest

        steps:
            - name: copy your existing codebase
              uses: actions/checkout@v3

            - name: run the build command
              uses: npm run build

            - name: you can also perform some tests
              uses: echo "perform some steps"

when you deploy your code, you can just push it with this file and github will pperform this actions and push only id the validation and tests are successful or integrate the code.

summery:

so we create a .github folder in which workflows folder and it contains .yaml files, now these are just the workflow like its like i write manual terminal commands but with automation as the commands are given in sequence, in the ci we integrate the code to existing codebase, we give workflow a name and then on which action to run like push or pull_request and on which branch. then bunch of jobs will run and at first we also mention that the build will be done on which os like we use ubuntu-latest and then each step in the steps are like name and run, run is used to pass the commands like terminal commands, and uses is used for action, action is nothing but bunch of terminal commands written by other folks and provided by github so that i dont need to go into such depths, and with: is like parameter we can pass issential details for the action. note: each step run in the order written. cd is continuous deployment- it also applys the same syntax of yaml that used in ci but it runs after ci and can access the build of ci to deploy.