 Hello. This is Mark Punsock, head of Product GitLab. I'm going to demonstrate going from idea to production faster with GitLab 9.0. I'm starting off with the new installation of GitLab Enterprise Edition, running on a Kubernetes cluster, running on Google Cloud Platform. I'm already logged in, so let's create a new group. I'll make it public. Now let's create a new project, starting from a really simple example app just to save myself some typing. Let's get our project connected to the built-in Mattermost. Mattermost is an open-source Slack alternative that comes bundled with GitLab. Now we're ready to configure GitLab AutoDeploy. Back to the project, let's click Setup AutoDeploy and choose the Kubernetes template. This is a great template to get us started, and we just need to edit the cube domain to use our own domain. Great, that completes our project setup. Let's go to our Mattermost client. Chat is where the team would discuss the project and come up with great ideas such as, let's improve the homepage. When a great idea comes along, it's such a waste to let it die in a chat room, so wouldn't it be great if we could create an issue for the project right from chat? Well, with the GitLab Chat command integration, we can do exactly that. Let's see how it works. On first use, the command will ask you to connect your GitLab account, which is as simple as clicking the provided link in the response. Great, now we can see what commands are available. Let's go ahead and create that issue. Great, now we can click through to see our first issue on our new project. As a team leader manager, I'd go to the issue board. Since this is our first time, we have to add a couple columns here to match our workflow. I'll just add the default to do and doing columns. Now we can just add the new issue to our board. Because we want to resolve this right away, I'll move it into the doing column. Great, now let's get coding. We could, of course, code on our local laptops, but then we'd have to waste a bunch of time setting it up properly before we could even start. Since we've set this project to deploy automatically to a staging environment, GitLab provides web terminal access to that environment. This is especially useful for debugging, but we can use it here for testing out small tweaks. By clicking the terminal button, we get a command prompt in the same container as our application. Let's edit the server.rb file. Now we've saved the changes. Let's restart the server. And now we can view the web page live to see how we like the changes. That looks pretty good for now, but we didn't commit anything, so this change will be lost the next time we deploy. So let's move on to committing changes into source control by using the web editor. I'm just going to add a header to it. Now, instead of committing directly to master, I'm going to create a new branch named with the issue number. GitLab knows by the branch name that it closes issue number one and adds that message automatically, so we don't have to do anything except hit submit. As soon as the merge request is created, we see it kicked off the CI CD pipeline that will test our contributed code. Here we see a simple pipeline that contains three stages for build, review, and cleanup. At this point, I'd ask another developer on the team to review our merge request, but I don't want to just trust reading the code. I want to see it live in a production-like environment. When a new change is pushed to our branch, this change will automatically deploy to our Kubernetes cluster in a special app called a review app created just for this branch. Right 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 is what we just created, automatically deployed to Kubernetes to make our review easier. It looks great, so let's accept this merge request and merge it into the master branch. Taking a look at the pipelines tab, we see that we're rerunning CI CD on master to make sure the test still pass after the merge. We actually see the history of all CI CD pipeline runs, and if there are any failures, it'll quickly show you the stage where any runs fail. Going back to the merge request, we now see another status showing that this code has indeed been deployed to staging. We can see our changes running live on our staging server. Let's ship these changes to production. There's this thing called chat ops that encourages us to do these kinds of things in a common chat room so everyone can see important changes. Great, here we see the deployed to production happening live. As an alternative to chat ops, we could have also triggered the deployment from the GitLab interface. Now that it's done, let's go back to environments. Okay, great, we see that the production environment shows up. There we go, we've got our new text in it all the way from idea to production. Here's a new feature in 9.0. If I click on this icon, I see the deployed board for production. Right now, it's only showing a single pod, but if I scale that manually using the Kubernetes command line and then reopen the deploy board, I can see that it's now rolling out 10 instances of the application. Refreshing shows progress. It's now up to three instances. While that's going on, let's see how the app is performing. Clicking on the graph icon, I can see a graph of CPU and memory usage. There's not much to see right now, but this will show the last eight hours so you can monitor how your app is doing. One final thing, the cycle time of getting from idea to production is very important. So GitLab has built a dashboard that helps you track that. Here we can see some metrics on the overall health of our project, and then a breakdown of average times spent in each stage on the way from idea to production. So far, we're doing amazingly well by completing a release cycle in minutes. This is great for team managers and high level managers looking to better understand their company's release cycle time, which is key to staying competitive and responding to customers. So that's it. In 10 minutes, we took an idea through issue tracking, planning in an issue board, coding in the terminal, committing to the repo, testing with continuous integration, reviewing with merge request and review app, deploying to staging with continuous deployment, deploying to production with chat ops and monitoring with Prometheus, and closing the feedback loop with a cycle analytics dashboard. This is all on top of a container scheduler that allows GitLab to get lab runners for CI and the applications we deploy to scale. Welcome to GitLab, the only platform that connects every step of your software development life cycle, helping you bring modern applications from idea to production quickly and reliably.