 Hello, this is Mark Punsock, head of product at GitLab. I'm going to demonstrate going through the complete DevOps life cycle from idea to production, faster with GitLab 10.2. I'm starting off with a new installation of GitLab Enterprise Edition, running on Google Kubernetes Engine, and I'm already logged in. Since we want to work as a team, we'll create a new group. Groups allow you to organize projects into directories and quickly gives users access to several projects at once. You can even nest subgroups under groups to match your org structure. Let's give ours a unique name. Now let's create a new project. I'll import from a really simple example app, just to save myself some typing. Now let's get our project connected to the built-in Mattermost. Mattermost is an open source Slack alternative that comes bundled with GitLab. We also integrate with Slack, so you could use that as your chat client as well. Now we're ready to configure GitLab Auto DevOps, which is the easiest way to configure GitLab CI CD with a bunch of best practices built in. Let's go to the CI CD settings. We just need to enable auto DevOps and set our base domain. Now let's kick off the first pipeline. I'll dig into the pipeline details later, but for now, it's great to know that without any effort, we've got a fully functional CI CD pipeline. And great, that completes our setup. Now let's move on to our teamwork. Today, more of our team's conversations are happening in chat, not in issues. So let's start with our Mattermost client. And when a great idea comes along, it's such a waste to let it die in a chatroom. So wouldn't it be great if we could create an issue for a 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 to 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 our first issue. Great, we've created a new issue directly from chat, and now we can click through to see our first issue on our new project. Inspiration is perishable. So let's pick up this issue right away. 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. These columns are fully customizable, and you can have multiple issue boards per project to help your team organize their releases. I'll just add the default columns of to-do and doing. There, now we can just move the new issue from the backlog into the doing column because we want to resolve this issue right away. Now let's get coding. I'll click through to the issue, and here I'll just create a new merge request. This automatically creates a new branch for me, starting with the issue number to associate them, and automatically specifies that this merge request will close the associated issue. Clicking through the branch, I see that it's a really simple app, basically just hello world with some random timings to make monitoring more interesting. I'm going to go ahead and update the message and remove the to-do. After the commit, we see it automatically kicked off the CICD pipeline that will test our contributed code. Here we see a pipeline that contains four stages for build, test, review, and cleanup. In the build job, we build the Docker image and push it to the built-in container registry. If we didn't have a Docker file, it would have used Heroku build packs to detect the language and framework and build an appropriate Docker image. In the test stage, we see two jobs. The test job detects the language used, again using Heroku build packs. In this case, it's Ruby, so it runs rake test. The other job, code quality, runs static analysis on your code to look for stylistic and other quality problems. When the tests pass, it automatically creates a temporary review app in your Kubernetes cluster. Here we see a bunch of steps that it's doing for us, with the highlight really being a deployment to Kubernetes using our default Helm chart. If the app had a Helm chart in the project itself, it would have used that custom chart instead. Or I can even add a variable to point to another chart, but here we're using the default chart. But to see the beauty of the review app, let's go back to the merge request. Here we see a new line showing us that it was deployed to the review app. And here's the URL to actually see my change running live. And this is great because I don't want to trust just reading the code. I want to see it live in a production-like environment. And this review app provides that. So this is what we just changed. And any new changes pushed to a branch will automatically update the app. Now, back to the merge request. We see here that there's a line for code quality. And we see that it liked that we removed that to do. If we had made things worse, it would have shown up here as well. Now, if there are any problems, for example, differences between development and production, and you don't want to keep testing changes by pushing them to source control, we could debug those problems right here. By clicking the web terminal button, we get a command prompt in the same container as our application. And all of our files are here. Let's edit the server RB file. And now I'll restart the server. And now go look at our app. And now we can view the web page live to see how we like the changes. At this point, we'd usually ask for another developer on the team to review our merge request. They can see the exact code that has changed and even comment on it. And we'd see a thread of the discussion here so anybody else can follow along. And of course, get email notifications. Now, this all looks great. So let's remove the whip status and merge the changes into the master branch. Now we see it's kicked off a new pipeline. And inside this pipeline, it looks familiar, but a little different. Instead of creating a review app, this one is deploying right into production. This is continuous deployment at its best. Going to the environments page, I see production listed here. And the last deploy happened less than a minute ago. And I can easily click through to see what it looks like. There we go. We've got our new text changes all the way from idea to production. Now there's more to this page. Here I see the deploy board for production. Right now it's only got a single pod, but let's go and scale that up. I'll go into CI CD settings and set a project variable production replicas. I'll set that to four. Now I'll go back to environments list and redeploy. Soon we'll see the deploy board update in real time as the fleet rolls out. And we can wait a bit to see the deploy finish. So that's high level status of the deploy. But how about monitoring the ongoing health of your app environments? Clicking on this little graph icon, I can see response metrics, latency and error rate and throughput. And down here is the system metrics of CPU utilization and memory usage. And all of these are taken from the built-in Prometheus monitoring, the leading open source monitoring solution. 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. There's lines for each deploy as well, so you can correlate changes in performance caused by recent deployments. Application performance monitoring can help your team be more strategic, preventing errors versus simply reacting to them. Imagine if your application monitoring tool could help you avoid pushing poor performing code in the first place, saving your business future downstream costs. That's exactly where we're heading. Let's close the loop here and go back to our merge quest. Since it's already been merged, we have to look for it in the right tab. In the merge quest, we now see another status showing that this code has indeed been deployed to production. This is great for managers looking at closed merge requests to know if they've actually been deployed or not. But we go further and show feedback about your application's performance right on the merge request, telling you how much your memory usage changed before and after the merge request was deployed. That covers AutodevOps from build, test, code quality, review app, deployed to production, and monitoring. Pretty awesome. But what if you want to do something differently? Well, here I'll go to manually set up CI, but instead of having to start from scratch and recreate all that we just saw, I can pick AutodevOps from the templates and import the whole thing. Now there's a lot in here, but it's not as scary as it first looks. And there's some helpful tips in here already. Say I'm not ready for continuous deployment to production. I can just uncomment out this staging job. And if I want to add canary deployments, I can uncomment this one. I then just need to uncomment out this last line to make my deployments to production manual, and I'm ready to go. Save this into master, and now I see another pipeline has kicked off. This one, again, looks familiar, but there are two new stages for staging and canary. And there's still the production one there, of course. With this configuration, staging is going to be automatically updated with the latest changes, but production is no longer going to update automatically. When we're ready, we have to manually promote from staging to production, but we're not going to ship directly to the entire production fleet. GitLab supports canary deploys, basically letting you deploy to a smaller portion of your fleet to reduce risk. So the deploy to staging is now done. Let's take a look at the staging app. There it's running just fine. And here, I'll click on the canary manual action to start the deployment to the canaries. And I can even see my canary deployment running in the deploy board. Now there's one new pod in production running the new canary code. And it's taking a portion of the production traffic, but the rest of the pods are still running the old code. This is a great way to reduce risks in deployment. When we validated that canary is working as expected, we can then go and ship it completely to production. Let's go ahead and do that now. It just takes a moment to rerun the deployment. And pretty soon we'll start seeing the deploy board updating. There it's at 66%. Great, now it's in production at 100%. And it takes away the canary because that's no longer necessary. So whether you want continuous deployment to production or a continuous delivery flow that's more under your control, or even if you want something else altogether, we've got you covered. Here's how you spot bottlenecks in your development process. GitLab has a built-in dashboard that tracks how long it takes the team to move from idea to production. 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 managers looking to better understand their company's release cycle time, which is critical to staying competitive and responding to customers and changing market needs. Now not only does Prometheus monitor apps, but it monitors the GitLab instance itself. Let's go to the Prometheus dashboard. Now let's look at a couple simple queries to show how our GitLab instance is performing. We can paste in a query for our CPU usage, and then here's another query for our memory usage. So that's it. In about 10 minutes, we took an idea through the complete DevOps lifecycle with issue tracking, planning with an issue board, committing to the repo, testing with continuous integration, reviewing with a merge request and a review app, debugging in the terminal, deploying to production, scaling the application, application performance monitoring, and closing the feedback loop with cycle analytics. And all of this on top of a container scheduler that allows GitLab, the GitLab runners for CI, and the applications that we deploy to scale. Welcome to GitLab, the only platform for complete DevOps, helping you bring modern applications from idea to production quickly and reliably.