 So GitLab is keeping track of the environments that we've deployed our app to. We can see we have production as well as some staging environments. Let's take a look at our website in production. We can see that we have some things for sale. Let's take a look at our Apple Cinema display. We can scroll down to the bottom and we see that we also have some recommended or related products. These would be things that we can use to perhaps upsell the customer on additional items that have a higher profit margin for us. And so are important for us to sustain our business. GitLab is also automatically set up to monitor the applications we deploy. Let's take a look. Being an e-commerce website, we are keenly interested in our metrics. If we can't be online or our users are unhappy with our website, they won't use it. Using the integrated monitoring, GitLab is tracking our error rates, our latency, our throughput, as well as our CPU and memory usage within the Kubernetes cluster. We're also tracking some very important metrics here for our business. We're tracking the average order value of dollars purchased. We're also tracking how many orders we're getting. And we're tracking how effective our suggested or recommended item engine is working. Again, because if you sell something like an iPhone, not a lot of profit in it, but if you can sell things like USB cables and cases, you do a lot better. So it's pretty important for us and our business that this is succeeding here. So you can see that there are two colors on our chart. One is orange and the other is blue. We're tracking the performance of the stable version of our code that is deployed and checking that against the Canary version of our code as well. Canary is the version that is essentially on deck. It's deployed to a single node of our fleet, and we're using that to essentially prove it out, test it out with low risk, and make sure it is something that we want to deploy to all of our customers. So in this case, we can see that the average is significantly lower for order value. And this is likely due to the lower number of recommended or suggested items that we were able to upsell people to. As you can see, we were about one less on average, which is causing a drop in our order value as well. So we can go back up and see what this commit was from. It'll be in our latest merge request. What this shows us is that we did in fact update our machine learning model to the latest model, hoping that we could further improve, further iterate and do a better job of reminding our customers that they might want an extra USB or power cable. Unfortunately, it doesn't look like that was a good update that we made. So we can go ahead and revert this or also go back to our environments tab and simply roll back to an earlier state of our production. Here are a few mockups of where we're heading. Continuous deployment should be boring. GitLab will have monitoring measure service level objectives and the impact on those SLOs of an individual deployment. When doing an automatic incremental deploy or canary deploy, GitLab will be able to use these measurements to automatically halt a troubled deploy and then revert or roll back.