
- Software Engineer, Product
- Modern Technology stacks:
- So What is a Tech Stack?
- Frontend tech stack
- Backend tech stack
- How to choose/build a tech stack
- What is a CI/CD Pipeline?
- Software Business Analyst
- Node.js Express Back-end Overview
- Build React App With Java Backend
- Connecting React-Frontend and NodeJS/Express Backend Applications
- React-Frontend, Node.js/Express-Backend, MySQL Architecture
- React Frontend with a NodeJS/Express Backend SQL-Architecture
- So What is git ?
- Git vs GitHub
- Big O Notation


CI/CD Pipeline : Everything You Need To Know

To understand we will delve into the basics of CI/CD pipelines, outlining the benefits of using them. We will then look at each stage in the pipeline, and what makes up a good pipeline, along with some examples relating to Terraform.
Build stage
Test stage
Deliver stage
Deploy stage
The build stage involves the code being written. This is typically done by multiple people in a team, and for larger projects, multiple teams. Code is held in a version control system (VCS), and a Git-based workflow is commonly used to control code being added to the repository (also referred to as GitOps). When used in a pipeline, tools to regulate developer environments and standardize them are particularly useful in order to eliminate any differences between different authors’ code. This will usually take the form of a docker container when using cloud-native software.
Testing can be broken up into multiple types, using a combination of these with a combination of different tools will give the highest code coverage and result in a higher quality product. Where lots of different tests are used, these can be parallelized to reduce the pipeline run time.
Below you can find a diagram of the CI/CD pipeline.
Adopting the use of CI/CD pipelines brings many benefits, including:
Reduced costs - Reducing the time it takes the app or infrastructure to get coded and deployed means less human resources are taken up.
Reduced time to deployment - Time to deploy is reduced through automation. The entire process, from coding to deployment, is streamlined, reducing the total process length and making it more efficient. Deployments can be made more often. The rate of release can give companies a significant competitive business advantage over competitors. Deployments can also be rolled back easily, should there be a problem. Developers of the code can remain focused.
Enabling continuous feedback - Enables teams to improve their code and workflow based on the feedback received. The testing stage highlights problems or faults and immediately gives feedback to allow code to be improved. Detecting errors earlier in the coding process means that these are easier and quicker to fix. Notifications can be set up to alert team members to failures or successes at each stage.
Improving team collaboration - The team has visibility into problems, can view feedback, and make changes where appropriate. Audit trails - Each stage of the pipeline generates logs and can enable accountability and traceability.
What Makes a Good CI/CD Pipeline?
What is a CI/CD Pipeline?
A CI/CD pipeline is used to automate software or infrastructure-as-code delivery, from source code to production. It can be thought of as a series of steps that needs to be taken for code to be released.r. CI stands for Continuous Integration, and CD stands for Continuous Delivery or Deployment. 'Pipeline' refers to the automation of the delivery workflow, consisting of build, test, delivery, and deployment stages. Although each of these steps can be executed manually, automating and orchestrating the stages maximizes the benefits of using CI/CD pipelines by minimizing human error and bringing consistency to each release. CI/CD pipelines are commonly used by application delivery teams and operations teams (DevOps). They are the backbone of adopting a DevOps methodology. Read more: Building the DevOps Pipeline. CI/CD pipelines are themselves commonly configured in code, sometimes referred to as 'pipelines-as-code'. Typically a build server (or build agent) is used to enable CI/CD runs. Typically these take the form of self-hosted virtual machines in the cloud which can be fully configured but also have to be maintained, or virtual machines provided as part of the platform you are using, which are typically less flexible in terms of adding software and plugins to them. Containers can also be used to enable consistent build environments, further removing the reliance on having to maintain a build server. Each step of the CI/CD pipeline can be run in its own container, allowing each step to be run inside a fully customized container. This also enables pipelines to make full use of all the benefits containerization orchestration affords, such as resilience and scaling where required.Continuous Integration (CI)
CI covers the build and test stages of the pipeline. Each change in code should trigger an automated build and test, allowing the developer of the code to get quick feedback.Continuous Delivery / Deployment (CD)
The CD part of a CI/CD pipeline refers to Delivery and Deployment (CI/CDD anyone?!). CD takes place after the code successfully passes the testing stage of the pipeline. Continuous delivery refers to the automatic release to a repository after the CI stage. Continuous deployment refers to the automatic deployment of the artifact that has been delivered.Stages of a CI/CD Pipeline
Starting with writing the source code, and ending up in production, these phases make up the development workflow and form the lifecycle of the CI/CD pipelines. Pipeline runs are usually triggered automatically by a change in the code, but can also be run on a schedule, run manually by a user, or triggered after another pipeline has run.The four parts of the CI/CD pipeline are:
Build stage
Test stage
Deliver stage
Deploy stage
1) Build
The build stage involves the code being written. This is typically done by multiple people in a team, and for larger projects, multiple teams. Code is held in a version control system (VCS), and a Git-based workflow is commonly used to control code being added to the repository (also referred to as GitOps). When used in a pipeline, tools to regulate developer environments and standardize them are particularly useful in order to eliminate any differences between different authors’ code. This will usually take the form of a docker container when using cloud-native software.
2) Test
As greater resiliency is required and more varied infrastructure is introduced, testing code leads to greater confidence that the code will perform as expected. Testing of your code can be automated. In general, this is normally a repetitive, complex and sometimes tedious process to perform manually. A mistake that a lot of teams make is to skip the test stage or underuse it, as the benefits of properly testing code before delivery and deployment can be huge, contributing to a high-quality product.Testing can be broken up into multiple types, using a combination of these with a combination of different tools will give the highest code coverage and result in a higher quality product. Where lots of different tests are used, these can be parallelized to reduce the pipeline run time.
Smoke testing
- Perform quick sanity checks on the code.Integration Testing
- Integration tests are intended to test all the code, or system as a whole. They validate that newly introduced code does not break the existing code.Unit Testing
- Unit tests are intended to test a particular function, several functions together, or part of the code. Smaller parts of the infrastructure can be isolated, and tests can be run in parallel to shorten the feedback cycle.Compliance Testing
- Compliance testing is used to ensure the configuration follows the policies you've defined for the project.End-to-end Testing (E2E)
- E2E tests validate everything works together before deploying to production. It is the complete test of the whole process.3) Deliver
After the code has been tested, the code is packaged up as an artifact and committed to a repository.4) Deploy
The deploy stage allows the orchestration of the artifact release. Usually, teams will deploy to multiple environments, including environments for internal use such as development and staging, and Production for end-user consumption. Using this model, teams can automatically deploy to a staging environment when a pipeline is triggered. Once the staging environment has been reviewed and approved, the code can be merged into the main branch, and then automatically deployed to Production.Below you can find a diagram of the CI/CD pipeline.

Reduced costs - Reducing the time it takes the app or infrastructure to get coded and deployed means less human resources are taken up.
Reduced time to deployment - Time to deploy is reduced through automation. The entire process, from coding to deployment, is streamlined, reducing the total process length and making it more efficient. Deployments can be made more often. The rate of release can give companies a significant competitive business advantage over competitors. Deployments can also be rolled back easily, should there be a problem. Developers of the code can remain focused.
Enabling continuous feedback - Enables teams to improve their code and workflow based on the feedback received. The testing stage highlights problems or faults and immediately gives feedback to allow code to be improved. Detecting errors earlier in the coding process means that these are easier and quicker to fix. Notifications can be set up to alert team members to failures or successes at each stage.
Improving team collaboration - The team has visibility into problems, can view feedback, and make changes where appropriate. Audit trails - Each stage of the pipeline generates logs and can enable accountability and traceability.
What Makes a Good CI/CD Pipeline?
