 Welcome to this GitLab video. Today we're going to be discussing the verify vision and update you on where we're going with this category in DevOps lifecycle. My name is Brandon O'Leary and I'm the product manager for the verify stage of the DevOps lifecycle here at GitLab. This is how GitLab thinks about the DevOps lifecycle as a continuous set of stages that unite with each other and work to deploy code into production. Today we're going to focus in on the verify portion of this graph and talk about where we're going with this stage. First I think it helps to talk about how we think about verify and when we talk about verify we think of three north stars. The first being the gateway to operations. Verify is the first stage in the operations portion of the DevOps lifecycle and thus is where we can take everything that a developer is doing i.e. every commit to the code and unite it with what the operators need which is reliable tested deployments. Therefore verify tries to be a shining city on the hill if you will of all of the tangible and emergent benefits of a single application for the entire DevOps lifecycle by bridging the worlds of Dev and Ops. At the core of what CICD was built for in GitLab is speed and scalability. Built with cloud native and Docker in mind and built on top of those technologies themselves it's reflected in both the product design and the product vision how we are focused on automating all of the tests that we can and making sure that we can quickly and easily get tested code into production. And finally lovable solutions to complex problems. Again this is a goal of GitLab as a whole but it's specifically important for verify because oftentimes DevOps problems are some of the most complex problems that our users try to solve and so we want those solutions to be much simpler and then be seen as a very lovable easy answer to what was once a very complex problem to solve. When we're thinking about breaking down the verify stage we break it into these categories. Of course continuous integration is a major portion of what we do in the verify stage today but we also are focused on code quality and then a various kinds of testing. I want to go through each of these testing categories to talk about how GitLab thinks about these testing categories and where we're going in each. First performance testing is really based around the performance of your application and if the changes that you're making are going to make it more or less performant than it was before. System testing talks about how modern software is really a collection of microservices or larger services that can be deployed to multiple clouds and multiple locations rather than a single monolith on a single server. Validating these complex interactions to ensure the reliability of the system as a whole is just as important as understanding if a given change is going to break one part of one of those microservices. System testing is how we're going to advance this vision and make sure that when you're deploying your code you've not only tested the individual microservice but the system as a whole. Usability testing is obviously very important for our users that are deploying software to their customers or users. This allows you to work seamlessly within one application to not only review the code that's being changed but also review how that's going to impact the usability of the system. Accessibility testing kind of goes beyond what compliance needs are out there and also goes to GitLab itself using GitLab's tools to build GitLab. That is our team and our UX team is focused on making sure that with every release of GitLab we're making it more accessible and not causing an issue for anyone that would want to contribute and so we want to bring that forward to our users as well. Lastly compatibility testing is very broad discipline but it covers things such as hardware testing for software that runs embedded on a device as well as multi-cloud capabilities which is very important for many enterprises that are deploying to multiple clouds because they don't want to put all of their eggs in one cloud basket. And lastly let's talk about our users journey to DevOps maturity. GitLab sees concurrent DevOps as the answer for what has traditionally taken a very long time and been very sequential method of getting code into production. That is we think that one application, a single application for the entire lifecycle will allow people to work together seamlessly, provide one place for accountability, one place for testing and results and that's where verify comes in. We want to help a customer no matter where they are along the journey to concurrent DevOps. We want to help them understand even if they're just getting started with CI or they have very mature CI processes how GitLab can help those users mature and move further along the DevOps maturity lifecycle. Next let's talk about the next three releases. So coming up in February will be GitLab 11.8. This is going to come with a few key features that I'm really excited about. For a while now you've been able to trigger a downstream products pipeline from yours but it involved calling a number of APIs in the GitLab API. This cross project trigger ability is going to bring it as a first-class citizen to GitLab so that you can just say trigger and then specify the downstream pipeline or pipelines that you want to run after this pipeline completes. We're also going to then expand that visibility by allowing you to expand up and downstream pipeline results from within each pipeline. That way you can understand how dependencies or prerequisites pipelines are running relative to yours. Another way that we're increasing visibility is a pipeline dashboard. This is going to be a personal dashboard for you where you can add the projects you care about and see the status of the pipelines, what's failing, what's working and what's been deployed. We think this is going to be really helpful for teams that want to have a cross project view of their pipelines in general or want to display those on maybe a board in the team's workspace. And on the management side we're adding some more tools for system administrators to allow removing tags from the container registry and cleaning up old images in the registry. Next in March, GitLab 11.9 is going to come with a few great features. Some of those that I'm really excited about include enabling our interactive web terminal on gitlab.com. So our interactive web terminal is something we introduced a while ago that allows a user to see, interact directly on the web in the application with the terminal that's in the runner that's running their jobs. This can be really helpful when debugging or trying to understand how what's going on with a runner's job. We're working with our infrastructure team to bring this capability to gitlab.com so that all of our users on our SaaS version of this software our software can take advantage of this. Another big change that's coming in our vision for a single application is Windows Container Executor. For a long time we've had the ability to run a shell executor on Windows machines for people making builds on Windows but this is going to allow first class support for Docker on Windows. Next as I pointed out earlier verifying every commit is crucial but today that is either done on the branch by branch basis and then only after being merged into say the master branch is it is that pipeline run again. So what we're bringing is the ability to run a pipeline on the merged code result before you actually merge the code. This will ensure you that once you merge master will stay green and we're also bringing simple protection of CI variables in job logs. This will obfuscate any CI variables that may be accidentally or intentionally echoed into the logs. Lastly, GitLab 11.10 will come out in April, April 22nd and here we're going to focus on how we can help folks that are building very complex projects with GitLab CI. So this includes improving what we did with the trigger by feature in 11.8 by adding triggered by conditional support. In this way something that relies on an upstream project can say run my pipeline anytime that upstream project's pipeline completes and passes. This means that the upstream pipeline doesn't need to know about all of the children that may depend on it but anyone using that as a dependency can make sure that they kick off their pipeline after those pipelines complete. We're also adding more logic for build conditions to allow you to bring multiple build conditions together and create a much more complex set of pipelines and logic. From a visibility standpoint we're going to look at graphing results to your tests over time so that you can understand how your team's improving or maybe not improving their testing over time. And on the management side we're looking at a community contribution that's going to help us bring outside secret management into GitLab specifically with Vault but we're doing it in a way that's very open and able to use any number of open API providers of secrets management tools. Thanks for watching this video. You can reach me on Twitter or on GitLab or in any of these issues. Please visit about.gitlab.com slash Direction slash verify to see all the details for these three releases and what we're thinking about after that. We'd really love your feedback and look forward to talking to you.