Setting up your first CI/CD pipeline with Jenkins
today i'm going to show you how you can build a ci cd pipeline uh using github and jenkins for an application on the now platform so we're going to start by creating an application on my dev instance here uh we'll say an app for jenkins is the name we're gonna make it a global app we're gonna skip the rows and tables and just to keep it exciting we'll uh add a script include a global script include for our new global app here have something in it so great there's a script next up let's link it to source control we're going to create a new repo in github here and we'll just call it the same thing keep it consistent now that i have my repo set up here we can come back to link it in my studio for my dev instance uh since this is my first time uh i'm just gonna go with the master branch and i've previously set up a credential in my dev instance for my github account using your personal access token already well that's thinking let's take a look at some of the uh things that we've released recently to help you get started with jenkins faster firstly is a servicenow cicd plugin on the jenkins plugin index this wraps the ci cd apis that we released in orlando and helps you to be able to automate a lot of your test validation steps publishing installing apps from the app repo managing plugins uh so you don't have to directly work with the apis you can just include your build steps as a part of the plugin that we've released here secondly we've provided example of pipeline templates that you can just copy and paste into your applications are github repos and we can run uh directly from these pipeline uh examples so coming back here we should have linked successfully now and we'll see that the application is indeed part of my github repo now and we're actually going to go ahead and add a new jenkins file so copy paste that pipeline so i'm going to take my pipeline sample here and just paste it in and now there's a couple of things to note about the pipeline firstly it depends on uh environment variables uh to be able to pass into the build steps so you'll see here for example we have the different environments set up here uh different societies representing the app or the test suite for atf in my test instance so we're going to make sure that those are updated so we're passing in the correct uh values into the build steps firstly for the abscess id we're going to come grab that from studio here branch name we're going to want to leave as is so we can pass it in the credentials i've previously set up in jenkins so for example if you come to jenkins uh we can manage credentials and you'll see here that i've got a two ids defined one is a credential for github that we're going to use in a moment that's also based on a based on our personal access token secondly is this a servicenow credential so i've got the same pair of credentials set up for um a service account all of my instances so we're just going to copy paste that in here mind the spaces i have three instances here so it's a dev instance a test instance and then a prod instance and i'm going to leave the test read id as is because it's already uh the correct one on my test instance um just to briefly explain uh how the pipeline works we have three stages firstly is a build stage where we apply remote changes from the relevant branch back down to the dev instance at the publish application version um uh from that branch secondly is a test stage where we uh install the application that we just published to the app reboot format of instance into the test instance and then on the test instance we run uh the atf test suite that i've already got set up and once that ci build is complete a pull request is completed as well and we can merge that branch into master that feature branch then lastly uh if it is uh if the master branch has a merge uh come in then it kicks off uh the cd bar the pipeline which is deploying uh the application browser will install the application due prod um so i've made all the changes i want to make to the pipeline here and we're just going to commit it to the master branch for now so great uh my repo is set up correctly now uh we can hop over here to jenkins where we can add a new uh item um to name our item uh let's just continue being consistent here and borrow from uh the repo here and we're gonna make a multi-branch pipeline this allows the jenkins file that we just defined to function as the pipeline as a part of your configuration for your multi-branch pipeline jenkins you're going to want to set up your credentials i just pointed out earlier so personal access tokens we'll see that that is working and we're going to add uh the link for the git repo here and validate that just in case yep that works so for discover branches you're going to want to use all branches um and then you can leave the discover uh pull requests from original forks as is everything else works as is your knowledge here to build configuration we're picking up the difference file that we just defined as part of our application at the root and we're just going to save here actually it's great we see the skin repository log and uh it's able to find a master branch from our repo we can take a look at that here so great looks like the master branches here uh we're gonna stop that job because there's nothing to deploy right now all right let's come back to our repo here um and uh for this scenario um let's imagine that we're picking up a story from a backlog um and we need to create a new feature off the master branch so firstly uh let's apply remote changes from our master branches see down here just to make sure our uh master branch here on instance has the latest and greatest from repo great um so first thing we're going to do here is create a branch off the master branch and we're going to call that a feature branch some number and once that branch has been created it's actually going to trigger a build if it gets picked up in jenkins uh while we're waiting for that uh we can go ahead and uh do some feature work on our new feature branch 33. for example i might make a change to the script include that we just created earlier so we'll say some feature was made and uh we can increment the version as well here so hey maybe 107. all right so we've made a few changes on our feature branch here um and once uh source control loads in again we'll see we made an update to the version number we can now commit these changes you can see two things were changed uh one was in the sysop record or version and secondly was in the script include we added that additional comment we're going to commit both great and now we head back to uh the repo here uh we'll see here that a new branch was created and we can start a pull request to merge this feature branch into the master branch so as a part of our jenkins setup here sometimes you have to scan repository to pick up these new branches and pull requests in order to kick off builds let's try reloading that there we go feature branch 33 is now in and we'll see we have two branches and one more request which reflects our uh repo here um don't mind the first one failing uh the second one is the one that we're going to take a look at here uh so as a part of triggering your pull request uh we're going to do a build and deploy and to test run uh your atf uh test suites um and if it's passing then then we should merge into master so if we hop into the pipeline here once i'm on the right tab we can see here that there's a couple of stages that i brought up earlier firstly we have a build stage which has passed already but it applied remote changes from the gear report back down to the instance and then published a version of the application 108. we increment as a part of uh the uh build steps uh then the test stage has passed as well uh so test was able to successfully install the application and i run my atf test suite we even have links to my test instances uh atf test suite in case you want to see the results so that passed we should see that in the uh request as well um again don't mind the first one but we passed the second one that one is the one that matters here so we're actually going over support requests because the build passed and we don't need to wrench anymore so great now that the master branch has been updated we should have kicked off the cd part of build so let's take a look back here on the master branch that is the run that we cancelled earlier um so we might have to do another scan to get things updated all right i'll see you again all right there we go started so we'll see here as part of the cd part of the build once we've merged changes into the master branch we're going straight to deploying the application version to production because that version of the application passed before and that was successful as well we were able to successfully install and the way that we can validate this is to take a look at my production instance so here i am uh coming up to my company applications in my production instance if we check the install tab with the app for jenkins version 108 has been successfully installed so in this example we started from a freshly created global app uh included just a uh global script in it uh link it up to source control uh set up a ci cd pipeline that's built on top of our plugin uh using the uh sample uh pipeline template that you can just copy paste in as the jenkins file for your application and just uh keep it with the git repo for your application um and from our jenkins instance we were able to run both the ci build on pull request as well as a cd uh all merging to master and that concludes our example for cicd pipeline built using github and jenkins thank you
https://www.youtube.com/watch?v=-FDdQ_ZgWGw