(Image above source: https://www.tmap.net/building-blocks/CICD-pipelines)
I was just looking for an image that visualized the idea very well, and they have a great article as well over there that I fully intend to go through myself to review this topic!
Continuous Integration / Continuous Deployment (CI/CD) Review
Though CI/CD is generally referred to as a single concept, it is actually two separate philosophies / operations used by developers to ensure smooth deployments of applications and updates to features, so I first want to explore them separately.
This will be a shorter post as the “Describe CI/CD” on the Blueprint is more leaning towards knowing the basic concepts and components rather than how to kick off the actual process, so this will be a shorter article from my class this week.
Also the Security Section I assume to be very large, and I’m start to learn more towards a CI/CD method of writing out my notes for this DevNet class rather than GIANT articles 🙂
Continuous Integration
The goal of “Continuous Integration” is for developers to continually merge their changes to the master branch often, to avoid conflicts or the introduction of bugs, this also keeps the master branch clean and current when a developer checks it out they will have the most current branch that everyone else is working on (again to mitigate conflicts).
One important consideration is the SCM (Source Control Management) platform used so that all Developers can work from ideally the same Repository, using the GIT Branching system if it is needed for individual chunks of work, so that the “Pipeline” is available to every Developer at any time from any machine on demand.
Once kicked off the goal is to build automation into the CI Pipeline to reduce the room for human error and reduce time making manual changes, which consists of a short list of important tasks that will need to be automated to keep the pipe moving Continuously:
- Code Compiling
- Unit Testing
- Manual Code Analysis
- Integration Testing
- Packaging / Versioning
- Publishing to the Repository
There may be situations where large chunks of code compiles / commits must be in succession while integrating into the CI Pipeline that may rely upon each other to trigger the next piece of the code, and these are often the type of scenarios where the usage of separate branches are used outside of the Master Branch – For these situations.
Continuous Delivery
This goes back to Agile Software Development Cycle that consists of “Sprints” where I described keeping code not necessarily deployed, but in a state ready for deployment, so these end products of CI are in a state to be deployed to an existing application – Hence the term CI/CD being coupled together because the two rely on each others concepts.
The steps involved in the CI/CD Process can be roughly described in 4 steps:
- The end product of CI Pipeline Code is delivered to a Repository
- This code is Automated to be pushed into a Staging Area for Testing
- Automated testing for this like Performance / Scaling / Security / and any other requirement of the final product being deployed
- Some sort of Human “last line of defense” should manually verify the code has passed all testing and is deemed deploy ready and deployed to end users
If the code the code fails during any part of this Automated CI Pipeline process, or deemed not deploy ready by the last line Human safeguard, it should be immediately returned back to Developers to review and run back through Automated processes.
CI/CD uses the “Test Driven Deployment” model described in my SDLC blog, where Automated Testing / Chunks of Test Code that mimic the actual code to be deployed are built first to ensure bug fixes are identified in each “Sprint” of code, and the process of CI stops until that Iteration is fixed and passes Automated Testing from all angles.
Continuous Deployment
This is the ultimate goal of CI/CD after the code has gone through rigorous testing and quality checks, ready to deploy, these changes are also Automated to be pushed into the production environment for End Users as the ultimate final tested – As CI/CD does go through as much testing as possible before deployment it is Continuous Deployment so it will not be manually pushed but Automated to be Continuous throughout the cycle.
This means that with “Continuous Delivery” having a human intervention before pushing code into Production, this push is also Automated if the code passes all phases of testing, which may use some different strategies to reduce possible user impact.
These different strategies of use impact for Continuous Deployment include:
- Rolling Upgrade – Most straight forward way of CD, changes are pushed in a way as to not impact “current users” of an application, so the change should not require a re-install of the software or application
- Canary Pipeline – The change is pushed to a portion of users to test the changes first, and if everything is working, the change is then pushed out to all users
- Red-Blue Deployment – This is where two production environments exist where some traffic can be cut over to the environment with changes, and if no issues are found all of product can be cut over so the other environment is ready for the next upgrade push – So at any time there are two “Production” environments running so one is always running the updated code and the other ready for the next push
The benefits of environments using a CI/CD Deployment / Integration model
- Integration using “Agile” methods – This provides fast delivery of sub-sets of features constantly being developed into working software in “sprints” by developers, so the software isn’t one big feature add but constant small adds
- Shorter MTTR (Mean Time To Resolution) – Issues are easier to identify and fix quickly because the pushes of changes into the environment are small adds
- Automated Deployment – The Automated Testing means Predictable Deployment into the production environment, which means faster delivery into the production environment using strategies that mitigate user impact such as “Red-Blue” (this may be called any different set of colors on exam day)
- Less Disruptive Releases – Smaller chunks of updates will generally lead to less user impact if an issue is found, rather than larger pushes of code or features
- Improved Quality – All of the benefits listed above means a better user experience, because the code goes through rigorous Automated Testing, and minimizes downtime / fixes / “technical debt” when deploying upgrades into production
- Rapid Deployment – Because features are being rolled out one at a time rather than as an entire feature-set, the software feature-set grows rapidly rather than a longer wait for the full feature-set to be delivered at once
I think some of the key takeaways from the benefits is the entire feature-sets are delivered in pieces via Automated Testing and Predictable Delivery, meaning that feature-sets fill in faster and are easier to fix if something does not work properly.
I would definitely keep in mind this is both “Agile” and “Test Driven Deployment” methods in the CI/CD process, only the TDD portion is Automated making it rapid or AKA a CI/CD Pipeline, it is short “sprints” of TDD in an Automated fashion for speedy delivery.
One popular tool for CI/CD Systems Integration and Build Status is Jenkins
I am unfortunately unable to demo this CI/CD Pipeline creation tool at this time as I am getting some errors that I don’t want to go too far with ‘hack’ fixes for to my VM, as I’ve already gone through one 2 VM deaths, but wanted to add for sake of completion.
Jenkins is where you can both define “Build Jobs” by adding a GitHub Repository to pull from, and also a PipeLine feature where an actual Pipeline can be built from Jenkins, with options on what triggers the CI/CD pushes.
I will try to demo this down the road once I am not in a scramble to keep pace with my class work that I got behind (excuses, excuses), but I will be watching some youtube videos myself on this to see how it works if nothing else and encourage others to do so before sitting the DEVASC as its probably beyond “Describe CI/CD” in the exam Blueprint but I am sure it will help to illustrate the process of creating CI/CD Pipelines and the different ways to configure the Pipeline to operate.
With that I am going to cut off this part here, as its time for Security!
Security is going to be a very robust topic, or at least I’d like to add as much information as possible into the section of my post for this Cisco Study Group, once I am done with the rapid pace group I will be covering all the content again with the DevNet OCG and CBT Nuggets videos to reinforce all points so additional articles will likely be added to include more information (as there is no such thing as TOO MUCH information)!
Until Next Time keep it Geeky! 🙂
The DEVNET GRIND! 