How to Set Up Continuous Integration & Delivery (CI/CD)
A comprehensive guide to CI/CD
So first of all, when you hear terms like Waterfall, SCRUM, Sprint, Agile, Continuous Integration, Continuous Delivery, Continuous Deployment, DevOps, DevSecOps, etc; think of those terms as a way of doing something, not a skill set.
All the above are concepts that can be applied in different ways, depending on the tools and platforms used by an IT team or Organization. There are “no 12 steps” to successful CI/CD or DevOps or Agile, etc. it’s pretty much just using those concepts and applying them to create a workflow that works better for your team or organization.
So, let’s briefly revised these 3 terms: Agile, CI/CD, and DevOps
How they differ from each other and how they relate to each other.
- Agile focuses on processes highlighting change while accelerating delivery.
- CI/CD focuses on software-defined life cycles highlighting tools that emphasize automation.
- DevOps focuses on culture highlighting roles that emphasize responsiveness.
- For more details, check out my article: What is DevOps? “In Simple English”
CI/CD are often cited as pillars of successful DevOps. To establish and optimize the CI/CD development model and reap the benefits, you need to build an effective pipeline to automate the build, integration and testing processes.
Tip: Share & collaborate on utility and UI components
Use Bit to easily publish, install and update small individual modules across different JavaScript projects. Don’t install entire libraries and don’t copy-paste code, when you can build faster with small reusable modules. Take a look.
Continuous integration
In software engineering, continuous integration is a development practice or a process of automating the build and testing of code every time a member of a development team commits changes to version control. CI encourages developers to share their code and unit tests by merging their changes into a shared version control repository after every small task completion. Committing code triggers an automated build system to grab the latest code from the shared repository and to build, test, and validate the full master branch.
Continuous Delivery vs Continuous Deployment
Continuous delivery is a software development practice where code changes are automatically prepared for a release to production. CD expands upon continuous integration by deploying all code changes to a testing environment and/or a production environment after the build stage. When properly implemented, developers will always have a deployment-ready build artifact that has passed through a standardized test process.
With continuous delivery, every code change is built, tested, and then pushed to a non-production testing or staging environment. There can be multiple, parallel test stages before deployment to production.
The difference between continuous delivery and continuous deployment is the presence of a manual approval to update to production. With continuous deployment, production happens automatically without explicit approval.
Continuous delivery automates the entire software release process. Every revision that is committed triggers an automated flow that builds, tests, and then stages the update. The final decision to deploy to a live production environment is triggered by the developer.
To learn more details about CI or CD, simply google it!
Now let’s try to build a fun clock with pure vanilla Javascript, HTML, and CSS. We’ll also create and set up these environments in the following way:
- dev environment → Continuous Integration/Continuous Deployment
- test environment → Continuous Integration/Continuous Deployment
- production environment → Continuous Integration/Continuous Delivery
For the purpose of this tutorial:
- use any of the projects you have already built or start a new one.
- I’m using my javascript Analog project demo, feel free to clone it and follow along:
git clone https://github.com/YannMjl/Analog-Clock-JScd Analog-Clock-JSgit branch -a
Recommended IDE for this project: VS Code
I have created 3 branches for this project, you can name yours anything that makes sense to you, I named mines:
- dev branch → development environment
- test branch → test environment
- master branch → production environment
I then set up my branch with the following logic:
dev branch | development Environment
This is the only branch where all code is written, changes are made, brief where the application is being developed. if you’re following my demo, the web app can be run on the localhost using live server extension on VS Code.
Ideally, After a team member is done writing code (fixing bugs, adding features, removing/editing or adding stuff, etc) locally on dev. The team member will push their commits to remote dev. Which then will trigger the build process and automatically deploy the changes made on the development environment. Thus, Continuous Integration and Continuous Deployment.
I set up the dev environment here:
https://clock-dev.netlify.com/ (build branch: dev)
The other team member can also see visual changes and the evolution of all the work in progress by navigating the dev environment.
test branch | test Environment
The test environment in this context can be used to regulate and coordinate changes or feature added to the application by team members working on different parts of that application, do code review, etc. Before sending the changes live to production.
To get changes made into the test environment, each team member must create a pull request from dev to test. Now the test environment can go from a simple code review or a visual look of change made to a complex automated unit testing or system requirement checks.
After submitting the pull request and successfully merging dev to test. The submission will trigger the build process and automatically deploy the new artifact on the test environment.
Thus, Continuous Integration and Continuous Deployment.
I set up the dev environment here:
https://clock-test.netlify.com/ (build branch: test)
All team members can check all the work done on the project and ready to go live by navigating the test environment.
master branch | production Environment
The master branch is the production environment branch. after testing and making sure that everything works as expected.
New changes or features can then be merged to master (pull request) and go live.
However, to implement continuous delivery. All deployment to the prod environment must be approved first.
So in this case. I simply added a rule to the master branch so that all pull requests must be reviewed and approved by at least one person.
Ideally, this individual should be the project lead developer.
Every approved pull request to master will trigger the build process and deploy the built artifact to the production environment.
Thus, Continuous Integration and Continuous Delivery.
I set up the production environment here:
https://clock-prod.netlify.com/ (build branch: master)
Everyone can now see the new updates or changed made to my clock app by navigating the public live production environment.
This is a very simple and basic implementation of Environments and CI/CD. However, this can get complex in real IT organizations with respect to what they are building and the tools used (AWS, Jenkins, Puppet, Chef, Azure, etc.) to implement CI/CD pipeline.
Cheers!
