As we get into this week, there are two concepts I want to introduce that are really central to this practice of testing your functional hypotheses as you go. One is a continuous delivery pipeline and the other is this practice of DevOps, which is a Domain Specific extension of Agile. Starting with our product pipeline, in this area of continuous delivery, I'm going to grab this section and expands a little bit. So our input is new code from the code step. What we're going to look at in this week is this series of tests that we run. So these unit tests, integration tests, and system tests or small, medium, large tests. The nomenclature is a little bit inconsistent in this area. So we're going to really dial and like, well, what do we mean by that? What are the differences between these tests, and more importantly, why are the differences between these tests, and why is there that progression? Then you may have a manual validation step, you deploy. Then we're over here in unreleased products, something that's in front of the user. So this is just like the product pipeline is an archetypal pipeline for the whole process of building something. This is an archetypal pipeline for the test everything from new code getting created or committed to a version control system out to working software. You may not do all these steps, but again, this is a generalized pattern that has all these elements, has them in a certain sequence. So we would be referencing that and thinking about how it might apply to the way that you test your functional hypotheses. The other concept is DevOps. Whereas Agile is this thing that deals with the business people, the product managers, and the development team as a general entity. DevOps is a Domain Specific extension of Agile that deals with the relationship between those two folks, but also in particular the relationship between developers, testers, and operations or systems folks. Let's look at what that means in a little bit more detail. In the old world, we had silos development test and Ops, and the inputs to the developer were hopefully user stories, wireframes, or in the old world requirements. The output is basically software that they say is ready to be deployed. They pass this over to the tester, they get working software, maybe they get some notes on how it's supposed to work. Hopefully they do. Their job is to make sure it's all tested, nothing bad can happen. Then this gets handed over to the ops people. This is a job I've done and they are supposed to deploy it and make sure that when they deploy it, it doesn't break. So they are at the end of the chain any kind of issue, code issue, test issue, is going to trickle down to them and they're going to be the ones touching it, seeing it, getting that call in the middle of the night. The idea is that in DevOps, we rethink the relationship between these folks and we think about both just in general, how they can work better together. I guess that's the overall chart of DevOps, you might say. Then specifically, there's some patterns like test-driven development that we talked about a little bit. So how might the developers make test a more integral part of how they build code, how do we enable the testers to invest in automated testing that this asset that we can use over and over again in infinite amount of times to enable them to do both better work unless drudgery and then for Ops, how did we make their work more continuous these folks, and a lot of those patterns have to do with this idea of infrastructure as code. So for example, rather than the developer or the tester giving the Ops people list of instructions about how to update a given piece of software. Instead, they collaborate together on an automation script that automatically will upgrade the software and then that's the way that they're testing software. That's the way that they're deploying the software. Though these things have been a tremendous asset to the teams that use them, this approach of continuous delivery, this use of DevOps is really ascendant and an important part of a healthy agile team. So we're going to spend a little bit of time looking at how we do these things to better tests or functional hypotheses.