Let's talk about this idea of a pipeline in a little more detail. How do we go from point A to point B? This is very central to the practice of continuous integration and continuous delivery. I'm going to start by zooming out and talking about this idea of a product pipeline. So, here we go all the way from observation to something that's released. This process here is what I'll refer to as continuous design. Not really our focus, but extremely important because you don't get really good outcomes from continuous delivery without high-quality ideas. First of all, if you don't have high-quality ideas all this stuff you're building up the capability to deliver really fast to the customer isn't necessarily going to generate positive outcomes, whatever you're trying to to have that outcome be. If it's a product, it makes more money, users like it more, if it's an internal thing that your users are working more effectively, it's hard to get those things and it's hard to know if you're getting them without high-quality testable ideas. Number two, without those high-quality testable ideas it's really hard to drive to the focus you need about testing in your practice of continuous delivery. Now, let's zoom in on on the actual delivery part of the pipeline which is this part and it starts with new code that is committed by the developer. So, here we go from new code to release product, and hopefully, we're delivering something really awesome out to the user. This set of steps here you can see has to do with testing. The basic idea here is that as we progress from small to medium to large tests, we'll just call them for the moment, we're extending the boundary of what we're testing and that is really, really crucial to a good high functioning pipeline that's delivering everything it needs to deliver to all it's different audiences. So, by boundary I mean that this small or unit test we're really just testing this one little piece of code this individual will call it function. We're really trying to isolate it and test it very, very quickly and very very specifically. Then when we move to medium or integration test, what we're looking at is, let's say that A interacts with B and C, these other two chunks of code in some fashion. Our integration tests we're going to have one that tests this interaction with just B and then we're going to have a second one that somehow isolates B and controls for it and then just tests how A interacts with C. So, we're still down at these individual pieces of code, but we're testing how they work together with these medium or integration tests. Then we extend this boundary even further when we go to the system tests. We're really looking at how the user would experience the system at when it's out there in the field with regard to these particular functions and probably several others. So, we're practicing like we play, we need to know what that is exactly when we move to this large or system tests. Then we often have some manual validation. This might happen on every single commit, every single thing you put out there or it might just happen sometimes when, for example, you're testing wants to do exploratory testing, take some new content and think about the best way to test it or system test it. But we may have some manual validation steps. Then we move to deployment which could mean a lot of different things, upgrading app in an app store or deploying software to the web or both, and then we get to released product. So, this isn't exactly necessarily what your pipeline will look like, this is a reference pipeline that we'll use to anchor us into the big categories of things that most teams do. We'll reference it a lot as we go through the course. Now, you understand the basic idea of what do we mean by pipeline and why is it important.