Hi, I'm Myles Brown, the Senior Cloud and DevOps Advisor at ExitCertified.
One aspect of DevOps that people ask a lot of questions about is this concept of CI/CD.
It's often written CI slash CD and you may hear people talk about a CI/CD pipeline.
So I'm going to answer that question:
What is CI/CD?
Well, first off, the CI stands for the concept of Continuous Integration.
The CD could stand for either Continuous Delivery or Continuous Deployment.
It can be either. And we'll talk about what's the difference between them.
But all of this is part of DevOps, where we're trying to increase the communication between developers who build code and the operations teams who deploy it to production and manage it in there.
And for many years, there were lots of fights between these groups.
Developers would take months to build code and then hand it over to operations, who would deploy to production and run into all kinds of problems.
And so DevOps is really the set of concepts and practices and principles that try and increase the communication between those developers and operations teams.
And one of the things that we try and do is increase the frequency of deployment so that the deployed code is not as big and doesn’t cause so many problems.
And if we can make this a very automated process, then we can really speed up how often we deliver software.
And that's really what a CI/CD pipeline is: It's an automated series of tools that you use that when developers check in code into a version control system, that's usually the first step.
Then there's a bunch of automated things that build that software, run various tests on it, deploy it into production or into test environments to make sure that it's going to run as expected when we eventually deploy the code into production.
And that's really the CD, Continuous Deployment, which means every time we check in code, we go through the whole automated process, which includes putting this new code into production.
However, a lot of places don't take it quite that far.
They make sort of a gateway where the business decides: “When do I take this deployable artifact and put it into production?”
A good example would be … think of Facebook. You know, it's a web app.
They can make changes to the web app all day long.
But in my mobile app, you know, I've got an iPhone.
I don't want to be going to the Apple store, to the iOS store, and having to download a new version of Facebook four times a day.
And so what they do is they pick sort of a two-week window and they say, “Okay, we can make little changes and if they're not mission-critical, some sort of weird security batch that we have to push out right away, then we'll wait, and every two weeks we'll take the collection of all those new changes and we'll push them all into production at once, just because we think that that will annoy people less.”
So it's a business decision when to deploy to production.
But that automated environment is still going on in the background where every time developers check code in, there's a bunch of unit tests that have to happen.
A lot of programming languages are compiled languages. So we have to go and compile the code, build some sort of an artifact out of it that will get deployed, and maybe we then start running a bunch of unit tests, functional tests, integration tests.
Maybe we provision a whole test environment that looks just like production.
We deploy it in there and do some more tests in there.
These days, with the cloud, it's much easier to take the same template that you use to build your production environment and say, “Let's quickly build a test environment, launch this artifact in there, run a bunch of tests, and then get rid of it.” We can automate all of that.
It's surprising how many tests can be automated. And so this is the process that we go through and sometimes the CI/CD process, you see it as this sort of like the Infinity sign where you know we build code, we test it, we deploy it, we run it in production. We monitor it and then we come back and look for, fixes and everything else. So we're going to be continuously checking in code into one of those code repositories.
Most code repositories these days are some sort of a Git-compliant code repository.
Git is an open-source tool, but you can also use commercial products like GitHub and Bitbucket.
And then when you check the code into Git, Git usually will automate, something happens as soon as you check in the code, it will start running some tests and build that artifact out of it.
Well, that's where a CI server comes into play.
So Continuous Integration servers, there's lots of commercial ones.
There's also a very, very popular open-source one called Jenkins.
Jenkins is wildly popular because it's very versatile.
It's easy to build plug-ins so that whatever kind of test environment to test tools that you need to run might be Selenium tests or Cucumber or JUnit. (Selenium is a free (open-source) automated testing suite for web applications across different browsers and platforms. Cucumber Framework is used to execute automated acceptance tests written in the “Gherkin” language. Gherkin is a domain-specific language for behavior descriptions. JUnit is the testing framework for Java programming language.)
Whatever the tests are, there's a plug in for Jenkins and so you could cobble together a whole bunch of these open-source tools and build your CI/CD pipeline that way. Jenkins is an open-source automation server which enables developers around the world to reliably build, test, and deploy their software.
You can also use a commercial vendor like GitLab to build a sort of product from end to end.
Or, maybe if you're a .Net developer and an Azure user, you might use Azure DevOps Services to do that.
You know all the cloud vendors kind of have products like these: AWS has CodeBuild, CodeDeploy, and CodePipeline, a series of services to build that CI/CD pipeline.
The big idea with CI/CD is that we're going to build all kinds of automation, starting when the developer checks in code, and then going into a series of tests and builds and deployments to test environments.
And maybe if you're if you're really involved with Continuous Deployment, maybe we push it right into production. But most companies stop short of that. And that automation should increase the number of deployments that we can do per day, which means that when something does go wrong, it's a very small deployment. With a small deployment, we probably have a very good idea what the change was and we can roll back quickly.
All of these tools allow us to sort of roll back things to the last known state and then investigate what was that change that broke it. We then can fix that and then deploy it again.
And so CI/CD is the one of the most common practices we see in DevOps these days.
Now at ExitCertified, we're a technical training company.
We have training from end-to-end on this whether it's big picture sort of DevOps ideas and culture change down to, “Hey, how do I build the CI/CD pipeline?” to all the individual tools.
If you want a course on Git and GitHub or Jenkins or maybe on Azure DevOps or on the AWS DevOps tools we've got you covered. No matter where you're looking and across all cloud and DevOps related things, we've got a large offering of courses. We call it the CloudCentrix suite and we have a nice diagram that kind of shows you the full breadth of what we can deliver.
Anyway I hope that you now understand what CI/CD is and hopefully we’ll see you in a class soon.
