 Hi, and welcome to the Configure Roadmap Update for June of 2019. My name is Daniel, and I'm the Product Manager for the Configure Stage here at KitLab. I am at kitlab.com for slash danielgrusso, and as always, feedback is very welcome. So feel free to reach out. On my last roadmap update in January, we had nine stages of the DevOps lifecycle. Fast forward six months, and we now have 10 stages of the DevOps lifecycle with the addition of the Defend Stage, which deals with all the features related to defending, reacting to, and remediating security threats. Configure sits on the ops portion of the DevOps lifecycle. You can view the full contents of our stage by following the link at the bottom of the screen. The Configure Group deals with the configuration and operations of applications and infrastructure. We aim to make complex processes and tasks easy for operators and developers alike. Our focus so far has been around advancing the maturity of our flagship features, such as AutoDevOps and Kubernetes, empowering operators by providing features that enable them to carry out their day-to-day activities in KitLab. And lastly, we want to simplify the developer experience by eliminating the pains of provisioning compute space. As I mentioned earlier, the Configure Stage deals with two main areas. The first one is infrastructure. This includes our Kubernetes integration, serverless, and our application development platform, formerly known as PAS. For our Kubernetes integration, we'll focus on two areas. The first area is adding more features to support the enterprise use of Kubernetes, and the second revolves around features to advance the maturity of this category. For enterprise support, we want to provide separate namespaces for each of the project environments that are created. In order to advance the maturity and make our integration viable, we want to do things like validate the credentials entered when an existing cluster is added, and offer the same features that we offer at the project level at both the group and instance level. So we'll get started with things like pod terminal access and deploy boards. And then we also want to add the ability to uninstall any KitLab-managed apps that you've added to your cluster, as well as offering most of the apps at all levels. Currently, there are some that are offered at the project level, which may not be available at the group or instance level, such as Jupyter Hub. For our serverless category, we'll focus on continuing to advance its maturity. Specifically, we want to make use of KitLab serverless features with existing Knative installations. For example, if you're using a hosted service such as Google Cloud Run, we want you to be able to use all the nice features of KitLab serverless. And additionally, we want to support the installation of Knative on both group and instance level clusters. Additionally, we want to offer support for more providers, and that will take the form of the ability to easily deploy your serverless functions to AWS Lambda. For our application development platform, formerly known as PAS, we will focus on adding features that will make it easy for operators to provision this kind of platform for developers. And we'll start with the ability to see all the deployments that are made to a group or an instance level cluster. For example, if an operator provisions an instance level cluster so that developers can deploy to it and make use of tools like AutodevOps, we want to make it easy for the operator to see both the deployments and the resources that are being consumed on the cluster. The second main area we focus on is operations. We want to provide operators with a robust tool set to carry out their day-to-day operations. This includes runbooks, chat ops, and cluster cost optimization. For runbooks, we have exciting new features arriving, namely the repository integration with Jupyter Hub. So any Jupyter deployment made from the GitLab managed apps Kubernetes integration will now ship with the Git integration for Jupyter. This will allow you to version control all the contents that you create in Jupyter, as well as surface all of the contents in your Git repo attached to your project or any of the projects that you have access to. And then we'll also work to fix a couple of bugs in that category as well. And for cluster cost optimization, we'll get started with flagging over provision Kubernetes deployments. One of the main categories we've been focused on this year is AutodevOps. AutodevOps provides a predefined CI CD configuration which provides a modern workflow, automatically out of the box with no effort. It's effectively a CI template that allows everyone to implement best practices. And so for the upcoming releases of AutodevOps, we are focusing on making AutodevOps smarter, and that's effectively not running when we know that AutodevOps will not be able to add value. So for example, if there is no Docker file or no matching build pack to build your app, we will not run AutodevOps. Similarly, when there is no runner configured for your project, we will not run AutodevOps. We will also want to focus on efficiency. So you may be familiar with a new project called Cloud Native Build Packs. And we want to integrate this build packs with AutodevOps as they are more lightweight and geared toward Cloud Native's apps. And then we also want to focus on storeships. So we want to bring the ability to scope environment variables to core. This will enable users to use AutodevOps with multiple environments and be able to scope those environment variables to each one of the environments easily. And that's it for this roadmap update. You can check out the entire vision for the configure stage on the first link on your screen. And you could also contact me if you want to continue the conversation. Thank you.