my name is charn and i'm product manager for surface now's ci cd features under our developer productivity and devascale umbrella and today i'm going to show you how to create a ci cd pipeline on gitlab for a brand new application so we're going to start off here my dev instance and create an application and we'll call it a new gitlab app and copy that we're going to make it a global app and just to make it more interesting let's add a script include in there global file here same name script one and uh we'll say this is on the future great so we've got a global app with a global file in it and let's think of the source control so great now we need a new gitlab project this here is my gitlab account so we're going to create a new project here so we have a repo to work with and uh we're just going to call it the same thing can also be public create that project go ahead and uh grab the link for the repo plug it in here uh since the first time creating this we're actually just going to stick with the master branch and i already have my credentials set up on this instance from before so let's link it to source control and there we have it linked so just sharing with you some of the other setup that i've got going on here i also have a test instance where i have an atf test suite set up with atf as well as a mock production instance where we're going to check to make sure the application is installed to or deployed to after our cd pipeline has run a couple of other useful bits here that we're going to borrow from this is a pipeline template example that we can use to just copy and paste and set up our pipeline as a part of the pipeline template you'll see here that we're calling an image here this is a docker image that we have published to docker hub that contains build steps wrapping the apis that the ci that we published in orlando that way our customers don't have to spend the time uh pouring over the api documentation and wrapping uh each of the apis individually and can instead just call upon uh the equivalent build steps so you know for example if you're doing a source control apply remote changes all you have to do is fill in the right values pass in the right values as parameters and uh your offset races so that's actually what we're going to do here now now that we've uh successfully linked the source control and then our first uh commit and push-up of the application uh we're going to create a new pipeline file and you can also hear that there is a really good lab ci diamo files that we can use now we'll call it the same thing and uh this is where this comes in very useful just copy paste the whole thing straight in and that is your pipeline now there's a couple of things that we're going to have to change here firstly is the variables that are defined as a part of the pipeline you notice that hey there's a few environment variables we're going to have to update in a moment and a couple of instance names that we have to change so i'm just going to plug in my devtest and broad instance names here go grab the society from my newly created application and i've actually already set up the atf test suite and so we're going to keep that the same from for myself uh but for your case definitely make sure to grab the society for your test suite and the rest of this is going to be good on this so we're going to commit to street to master let's hold off and run into pipeline for now one of the other things that we have to set up here [Music] is called ci cd variables so here we are going to have to define uh three different variables so uh we're passing in the right credentials as a part of uh the pipeline for my three different environments so we're going to go on pause here for a moment so for example we're going to want to define an s and authdef variable that will be generated in the environment we're not going to want to protect it otherwise we can't run it on no master branches and i'm going to be doing this three times oops it's great i've got my csu variables set up here now we're going to head back to my pipeline so let's do a quick test of our pipeline to see if it works we're back in our app now still on a master branch we're going to apply remote changes great and now we're going to create a new branch we'll call that future branch five and great we have a new branch up and running as a part of this new branch if we refresh here we should see the branches here terrific uh let's increment our version of the application representing some feature changes we can even create a new script include again and we'll just call it new lab script two some new feature french stuff so great we've incremented version added a feature in the form of a script we refresh that real quick should see two scripts here and wait for resource control to load in great we can commit the changes and we should see here two changes that we made one is new script and one is the virgin equipment on sysapp and we're gonna do both so about new version and script bam gonna commit that push it up to the repo awesome so let's take a look at uh back at the repo so we see here that we have a new feature branch 5 that we just created we're going to create a merge request to merge into master our changes and that kicked off a pipeline based on what we just entered in to make this uh more seamless we can even merge when the pipeline succeeds so i don't have to manually press the merge button and let's take a look at what the pipeline is doing so the pipeline that we copy pasted uh is doing is triggered on uh two ways firstly is on pull requests from future branches into master and the secondly is when the master branch itself is updated on a pull request we are applying changes down from the git repo to our dev instance for that branch we're publishing from a dev instance a version of the application then we're installing the application version into a test instance running the atf test suite that i've got set up beforehand and if that's successful it will not roll back the app but will complete the build for the merge request at which point we'll be merging into master automatically however if the test fails then we're going to roll back the application to clean up the test environment so here we're going to give it just a moment to complete the pipeline see here that the app has been installed my atf test is running and my test is passed so if we head back to the merge request here and give that a quick refresh we'll see here that the path the build passed and it was automatically merged into master and i elected to have the branch automatically deleted earlier so a future branch is gone and if we go take another look at the pipeline we should see here that the cd part of the pipeline is running so on the master branch since it had the feature branch merged in we're kicking off that deployed to broad stage and that's been successful as well so if we head over here to my production instance here we should be able to see that for the application is published on this instance and is that the right version let me give that a good old refresh yep so a nuclear lab app uh version 107 has been deployed to production after passing the build so that concludes our demo today uh starting from scratch with the global app linking to source control building your first ci cd pipeline and then pushing through a feature branch through a pull request or march request in gitlab parlance and once that build pass we merged into master and trigger deploy into production so thank you so much for your time today