 Hi, I'm Mark Punsock, head of product at GitLab. For GitLab 9.0, I demonstrated how we help you go faster from idea to production, and with GitLab 9.3 releasing today, I'm happy to demonstrate a few of the ways the idea to production flow has improved in the last three releases. I'm starting off with GitLab Enterprise Edition, running on a Kubernetes cluster on Google Cloud Platform. I'm already logged in, so I'll jump right in and create a new project, starting from a really simple hello world app. Now I'm going to enable GitLab Autodeploy, which automatically adds a great CI CD pipeline, and as of 9.1 has experimental support for private projects and apps needing a Postgres database. Now let's get coding. Here I'll just make a trivial change and save it to a new branch. As soon as the merge request is created, we see it kicked off the CI CD pipeline that will test our new code. Here we see a simple pipeline that contains three stages for build, review, and cleanup. In the build step, we build the Docker container image, and in the review step, we deploy that image to a special temporary environment called a review app, which is created just for this branch and deployed in our Kubernetes cluster. Now code review is great, but I don't just want to trust reading the code, I want to be able to see it live in a production-like environment, and this review app provides that. Yet from the merge request, we see a new status telling us that it's been deployed, and a convenient link to the actual app. This shows us what has changed, and any new changes pushed to our branch will automatically update the app. At this point, we usually ask another developer on the team to review our merge request. They can see the exact code that has changed, comment on it, and we'd see a thread of the discussion. In GitLab 9.2, we can even start threaded conversations. This all looks great, so let's click the merge button and merge the changes into the master branch. Taking a look at the pipelines tab, we see that we're rerunning CI on master to make sure the tests still pass after the merge. Going back to the merge request, we now see another status showing that this code has indeed been deployed to staging. In GitLab 9.2, we introduced app performance feedback right on the merge request, and in 9.3, we even made it better, telling you how much your memory usage changed before and after the merge request was deployed. Now let's ship these changes to production, but we're not going to ship directly to the entire production fleet. In GitLab 9.1, we added support for canary deploys, basically letting you deploy to a smaller portion of your fleet to reduce risk. Great, here we see the deploy to production happening live. Of course, we could have used chat ops and done this through Slack or Mattermost, but I demoed that last time. Great, now that it's running on a canary, we can verify that the canary is all working fine, and when we're ready, we can go ahead and ship this to the full production fleet. There we go, we've got our new wonderful change in all the way from idea to production. A new tweak to auto deploy is that we can now control the size of my production fleet using project variables. Here I'll set production replicas to 10 and redeploy. This does take a little while, so we can actually watch it progress real time using the deploy board. This does take a couple of minutes, so I'll just speed up the video here a little bit. Great, here we can see the fleet got rolled over and we watched it all in real time. I showed this before, but we've made some improvements to the application performance monitoring, so it's worth showing again. For example, we now show markers for each deploy. Oh, there's a couple more things I want to show you. In GitLab 9.3, we introduced the first changes to support cross-project pipelines. More and more projects aren't contained in a single repo anymore, whether that's a full suite of microservices or a more traditional three-tier web app. If your CICD pipeline spans multiple projects, you can now more easily trigger pipelines between them and now even visualize and navigate these complex pipelines. Here's an example, three-tier web app with a back end, including a database, and a front end. Looking at the back end and one of the recent pipelines, I see a new indicator here that after a built and deployed staging, it triggered a pipeline in the front end, which then ran integration tests based on that back end to make sure that everything still worked. So that's it, amazing improvements in going from idea to production faster, with higher quality and confidence. We hope you enjoy GitLab 9.3.