We talked about the basics of how version control works. Then, you've heard me say over and over again how central it is to a continuous delivery capability and just a more continuous pipeline in general. Let's walk through the mechanics of how these two things relate to each other in a little more detail. So, you have this new code. Bob has changes he wants to put into the trunk or the master version that they're going to go and push out to customers. So, he pushes a button that says, "Send this to version control," and that happens. Then, the version control system does this job of triggering these other events that do a build. So, that basically uses whatever processes they're going to use, hopefully, over here in deployment to assemble this software in a way where it can actually be run, one. Then two, it goes over here and it's going to run these small tests. If those pass, it moves on, and if they fail, then it kicks it back to Bob and so forth. Okay. So, this is how continuous integration works inside the creating of the code. Maybe there's a manual validation. What's important is that this builds as it moves through these different contexts of Dev or test or deploy, it's coming out of the single artifact repository. So, this build gets put here and we make sure that we're testing, we're deploying the exact same thing across this pipeline. So, that's how this version control and this artifact repository interact with the rest of the pipeline. Okay. So, these things are all interacting with the artifact repository to get the stuff that they're going to test, then ultimately, over here to deployment to get the stuff that they're going to deploy. Okay. So, this is how the role of version control and contexts of Dev and tests. What happens in deployment here is hopefully that they have a series of automation steps that are going to handle the deployment of the software really in the same way that's happened in the rest of the pipeline. Because we don't need everything to be the same, but we need them all to be put together in the same way, so that we get a reliable, dependable result, and we don't need these introduce variation in the build and deploy process, whether that's in Dev or test or production that could potentially cause yourself to break or behave unpredictably. Furthermore, what's key is that whatever infrastructure Dev uses to actually do that stuff, wherever those scripts, or recipes, or manifest, or whatever they are, that those are also stored in version control and really treated the exact same way as we've discussed for Dev. So, the way that they operate for their automation that deals with the job of Ops, of deploying the stuff, of upgrading the software, the OS', this is treated as itself a piece of software that handles that job. So, let's talk about a really specific example of what it means to be doing Infrastructure as code and what it means not to be doing it. So, I'm the Ops guy. My job is to deploy this thing, it's gone through the pipeline. My job to push a button and say, "All right, put this new version on server number 437." I do that, it's up for 437. My monitoring system sends something back like red light, you know, this thing's broken. I go in, I look at what's going on, I see, "Oh, this one little parameter is set improperly." I know that it should be B not A. Do I either, number one, just go in and change that parameter, so everything goes green and starts working again? I shouldn't do that. Or do I be, go into version control, find out why the recipe that we're using, the automation that we're using to make this change doesn't work. Why it missed making the appropriate change to that configuration parameter? Figure that out, fix it, recommitted it to version control, so it's the master version that everybody else is going to use. Then, push the button again and redeploy the software. It's that second thing that keeps you in this infrastructure as code, in this sort of DevOps automation oriented environment. The second thing starts to create that snowflake that we want to avoid like, "Oh, this server has been configured in the same way except for this one thing." Then, the problem is, of course, it's a sort of mix winter metaphors that snowflake snowballs into this big set of things that now we've got all this dark arts custom stuff going on in all our servers, and it's really hard to consistently do things properly. So, that is the role of version control both in the area of Dev and test as well as the job of Ops in the step of deployment in our pipeline.