 Ever since Forster recognized GitLab as the leading CI-CD tool on the market, many people have been asking, how can I convert the jobs I've spent years building in a legacy CI tool, such as Jenkins, into GitLab CI-CD? The easiest way to answer this question is, just give it a try. In this video, we're going to walk through a basic Jenkins pipeline and convert it into a GitLab CI-CD pipeline. Then we'll talk about how GitLab autodevops can make this conversion even faster. Here we have a simple Java Spring Boot project, built with Maven. Today we have this project building in Jenkins. There are a number of different ways that this project could be built, including using the Maven plugin, or using a Jenkins file and a multi-branch pipeline. For this example, we're going to show the Jenkins file and how we can translate the stages and steps there into our GitLab CI-EML. In this Spring Boot project, we have a Jenkins file that defines four stages, validate, build, test, and clean up. Looking deeper, we can see this file calls a Jenkins tool named JDK8 and Maven. The build stage then sets some environmental variables with options for Maven and runs a Maven test compile. The test stage sets similar variables and runs Maven test. After that, Jenkins cleans up the workspace used for the build. To start refactoring this into GitLab CI-CD using a GitLab CI-EML file, we need to understand a few differences between GitLab CI-CD and Jenkins. GitLab CI-CD is optimized for containers, so we're going to use the Docker executor to start from an image that contains the tools we need. This means that the workspace is also a Docker container, which is cleaned up automatically between stages. After selecting the Docker container, we will set the same environmental variables and cache the M2 repository so that it is shared across the pipeline. The build and test jobs look very similar to the contents of the Jenkins file, with the stage being specified and the Maven script called out. We also upload the produced jar into our GitLab artifact store, but if Maven is already configured to upload that artifact elsewhere, that would work as well. Now, what if we don't understand fully how the Jenkins file is structured, or the new YAML concept in GitLab CI-CD? What if we simply want our code to build and test itself? And since it's a simple web app, could it also be deployed for us automatically? This is where GitLab AutodevOps comes in. Here, I've uploaded the same code to gitlab.com. I connected my Kubernetes cluster to my project and enabled AutodevOps with my domain name. Once I've done that, a pipeline automatically kicks off. Using Herokuish BuildPacks, GitLab detects that this is a Java Spring Boot project built with Maven. Here, we see a much more thorough pipeline was created. Automated jobs for code quality, dependency scanning, and static security testing run right alongside our Maven unit tests. From there, the app is automatically deployed into our specified domain and a performance baseline is run. Now, when we make a change to our project, a review app will automatically be created and all of those tests will be run again on every commit. To learn more about AutodevOps, visit about.gitlab.com.