Let's take a look at this CI or possibly CD process and how it actually breaks down into specific steps and how it relates to the operation of one of these systems. When I say one of these systems, this is probably primarily stuff that's built on an off-the-shelf product like a Jenkins is a popular open source option with lots of things built on top of it and around it, Travis as another example. If the team is using the Atlassian suite, they have an offering that some teams like call the Bamboo, Circle CI is another option. So, this is a system that standardizes and automates and allows configurability of all these different steps in the pipeline. So, let's look at a specific example for our company we've been playing with HVAC in a hurry. Let's say there's two developers Shri and Diego. Shri's working on a user story, they're working on this parts ordering application. Shri is working on currently on a user story about the technicians being able to sort parts by popularity and Diego is working on a story about them being able to bookmark certain parts that they want to be able to come back to. So, here they are hypothetically working on this thing, they are operating against a single GitHub repository. The way that they're doing that is, they're using pull requests instead of direct commits to the master. The reason they're doing that is two reasons: One is, they want to initiate all these great tests that they've written and their team is written and make sure that all of those paths before they merge code into the master. Secondly, they want to use the pull requests as a trigger to do code reviews with each other and discuss the changes that they've made. I think this is particularly important because they have a general architectural design direction about how engineering wise they're going to approach all this stuff, but instead of prescribing all the details in advance, they're going to just let the design emerge as they go and figure out how to do all these different things for the technician. But they want ultimately a coherent design that makes sense, it's mutually understood that's internally consistent where that might be important, and they're using the pull requests as a way to come together and do that. So, Shri has new code. She pushes a button because she wants to test it and let's say in this case you want to also move it into the master branch to keep her merges small. So, what happens? Well, the first thing that has to be done is the software is going to be built so that it can be tested and we make sure that the build process is something that passes these tests. That's great because we want to make sure that whatever steps have to be done to go from just raw code to this can be executed in production, we want to begin with that end in mind and make sure that we're consistently using the same build process in all the different contexts, in development and test, in whatever kind of phases of the deploy process there are so that we don't get surprised on a production when everything should be working but it isn't. So the CI/CD this system is going to handle this process of doing whatever has to be done to build the software into an executable format and it's going to put it on this artifact repository, so we're always testing the same thing. Then two, it's going to run all these tests. So, what is important about what the CI or CD system is doing to facilitate this stuff? Well, number one on this build step, builds can take time especially if they're not done well. So, a good CI or CD system does things like the right caching and helping the developers speed up these builds because as we discussed with the test pyramid or test stack, speed is really key. What we want is the thing that's really fast so developers are getting a lot out of pushing that button to test to merge a lot because that helps them; one, know that their codes okay and it minimizes the surface area and the potential for merge conflicts and at least reduces their size. Then when these tests run, if everything's green, check box, fine then that output is pretty easy to understand but what if certain tests fail? It's very important for the developer to easily be able to see this kind of apropos of the isolation vector we talked about on the test stack or test pyramid, we want to know exactly what tests failed and why it failed though where's that test output how do I find it. A good CI/CD system is going to facilitate that for the developers so that they can run their test quickly and where they fail, easily know where and why they failed so they can act on that easily and rerun this process. So, are our protagonists Shri and Diego, Shri has committed Diego is going to review this code, it gets committed to master and then it goes on to the next step, whatever that is. So, the CI/CD system is going to trigger the build to be deployed to test or QA system if that's part of their process and notifying whatever fashion they like to be notified, the test team. Then either after that or let's say they don't do that, we're going to invoke the deploy and it's going to go out into production. So, that can happen a few different ways. If they're using Kubernetes let's say or K8 as it's often abbreviated, then they may trigger a command to the Kubernetes master or they may just place a container someplace where Kubernetes knows to look for new builds of a certain type and that triggers the Kubernetes automation to go out and orchestrate whatever were to happen to update the build. How does the CI/CD system know how to do all this stuff? Is just something that runs algorithms. So, it has an input files, kind of like the configuration management systems have some configuration input. These CI/CD this systems they have some file that is often in a format, you'll probably see this if you read some of the notes called YAML which stands for YAML in Markup Language and this is a sort of JSON-ish format, which is another format for basically just consistently describing structured information and texts that various communities of practice have found works well for them. So, this file says, "Here are the steps that I want you to take, here is the thing that you should build, here's where you should find the objects for the build process and do or don't take these various deploy steps?" So, as the team goes forward, it's really this configuration file here that they're going to operate against when they're telling the CI or CD system what to do. So, those are the general steps I'll say and covers I think that the major basis of at least a typical process where a team is working together on an integrated pipeline with one of these CI/CD systems in place.
