DevOps | CI/CD

3 min readJul 4, 2023

CI means: Continuous integration
CD means: Continuous deployment and continuous delivery.

CI is for developers to merge frequently. Traditionally, developers developed desperately (in different branches) and made a significant effort to merge the code. With CI, you can merge the code whenever you want and create tests (unit test, smoke test, etc.).

Usually, there is a CI server. Whenever the developer commits the code CI server detects the changes, tests them, and builds automatically. So you can test and build during the day. If something breaks, you can always roll back to the previous code if the CI server detects any problem.

CD:

The CD is for keeping the deployable code state. A feature release is about job planning, but the code should always be deployable.

Continuous deployment and delivery are so close to one another but are not the same thing.

Continuous deployment is adding new little features to production frequently. But in the other hand, continuous delivery keeps the code deployable. With CD adding new features to the production is not a big scary event.

Each code version goes through lots of automation, such as build automation, automated tests, packaging, etc. But sometimes, we could do manual things like acceptance testing. After these processes, we decide whether the code will go to production. Of course, these processes are part of automation.

In short, the code is automatically updated when the decision is made.

After deployment, if something is not right, you can always roll back.

WHY SHOULD WE DO CI/CD?

For early detection: If there is a bug, we can fix it quickly because we can get feedback faster with CI.
Frequent release: The code is always ready for production
Fast time to market: Code is always in a deployable state and always prepared.
Continuous testing: The QA tester team is part of the deployment process, not just the end of it.
Lower risk: The code is always deployable, so we eliminate the risk of mistakes.
Reliable rollbacks: like divide and conquer, we divide and fix the issues, so rollbacks are stable.
Fearless deployment: Thanks to these features, we never fear releasing the code to production.

Examples: Jenkins, TravisCI, Bamboo

Also can make pipelines in Gitlab and Github too. Here’s an example of a GitLab pipeline configuration file for continuous integration and continuous deployment (CI/CD)

stages:
  - build
  - test
  - deploy

variables:
  APP_NAME: my-app
  DOCKER_IMAGE_TAG: latest
  DOCKER_REGISTRY: registry.example.com
  DOCKER_IMAGE_NAME: $DOCKER_REGISTRY/$APP_NAME

build:
  stage: build
  script:
    - docker build -t $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $DOCKER_REGISTRY
    - docker push $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG

test:
  stage: test
  script:
    - docker run $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG npm run test

deploy_staging:
  stage: deploy
  environment:
    name: staging
  script:
    - kubectl config use-context staging
    - kubectl set image deployment/$APP_NAME $APP_NAME=$DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG

deploy_production:
  stage: deploy
  environment:
    name: production
  script:
    - kubectl config use-context production
    - kubectl set image deployment/$APP_NAME $APP_NAME=$DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG

Let’s examine the pipeline configuration in detail:

Stages: Build, test, and deployment are the pipeline’s stages.
Variables: Any environment variables used in the pipeline are defined by variables. The application name, Docker image tag, Docker registry, and Docker image name are all variables in this case.
Build: The construction of the Docker image, accessing the Docker registry, and pushing the image to the registry are all tasks carried out by the build step.
Test: Using the produced image, test stage executes the tests within a Docker container.
Deploy: The application is deployed to the staging and production environments, respectively, through the deploy_staging and deploy_production phases.
Kubectl: The image of a Kubernetes deployment is set to the freshly created image during these stages using kubectl commands.

Thank you for reading and supporting me. If you have any questions, don’t hesitate to ask.

Linkedin: https://www.linkedin.com/in/yagmurozden
GitHub: https://gist.github.com/YagmurOzden
You can check my other blogs: https://medium.com/@yagmurozden

DevOps | CI/CD

WHY SHOULD WE DO CI/CD?

Written by Yagmur Ozden