Automate our existing Jenkins Pipeline

Hey guys. Welcome back. This is the second lecture about pipeline as code in this lecture. We're going to continue where we left off and build an actually useful pipeline that is going to build and deploy the web application that you've been looking at throughout this course. But this time 90 percent of the work is going to be managed from code so let me start by explaining the environment that we have set up here for our pipeline us good example. First of all we have an Apache Tomcat running on port 80 80. That's going to be our staging slash testing server. We of course have Jenkins running with three jobs that we're going to explain here in a moment. Also we have another Tomcat running on Port Nighty nighty. This is our production instance and we're going to use it to simulate our production server going back here to Jenkins. You'll notice that I have three jobs the one at the bottom called package is the one that we're going to use to execute our pipeline as code. The purpose of this job is to manage the other jobs. Also this job will be used to call maven which is going to give us our web archive or binary artifact. Now we're going to use to deploy to production and staging. Once you have these three jobs set up you will hardly have to do anything in the Jenkins UI. Everything will be control from the Jenkins file that we have in our code repository. We'll take a look at that in a moment. There are two ways and Jenkins in which you can write an automated pipeline that's code. One of them is actual Ruby scripts and all the way is a declarative pipeline which is what we're looking at on the screen. This is the format that we're going to be using for our pipeline of scope. You can easily identify it because everything must be contained within the pipeline directive at the top within the curly braces of pipeline. You can add sections such as the agent section and the stages section. The agent keyword tells Jenkins where would you like to run the code. In this case the key word any tells Jenkins to use any available notes to compile build deploy your code as needed. You could also specify the agent section within a stage in case you have a specific stage that takes too long or that you would like to run in a specific Jenkins note. Each stage is made up of individual steps could be one could be many depending on your needs. In our opinion the declarative pipeline is a good balance between a fully scripted pipeline and groovy or just doing everything manually in the Jenkins UI. It provides you with the ability to code your pipeline without actually having to write code logic because this example Jason hybrid syntax is pretty self-explanatory. You can spot mistakes easily and it's easy to learn so without further ado let's go develop our code. Pipeline here you can see the Jenkins file that is executed by that package job and Jenkins as you can see we only have one stage which is to build stage and that is made up of a single step which is a shell execute to one command. In this case maven with the parameters clean and package we have a conditional below this step which you can see in the post section and the condition is if this six step succeeds we want to echo the message to the screen that says Now archiving we use the archive artifact commands to store the generated war file. This will be picked up later by the copy artifacts blogging that we have in our Jenkins. Let's go back to our Jenkins console and see what what this looks like. Click on package we'll go to configure and as you can see I have defined by blight name right here and pretty much nothing else other than a specify that this is a pipeline that comes from a script and source code management. I put in my repo it does not require any credentials and I put the file name which is Jenkins file that's all there is to it. Do we just hit save. If you are just doing this right now and whenever you want to execute it you just click the execute button and they will download the repo. It will look for the Jenkins file and execute the job from there. What we're gonna do now is we're gonna go back to our code editor we're gonna save these changes and push this to our repository to see what this looks like when it's running. By the way if your interesting is using this code editor I'm using Visual Studio code which is a free code. Ed by Microsoft I believe it runs on Mac OS Linux and Windows as well. So you should be able to run this no problem regardless of the platform that you're using. One of the reasons why I use this code better because it has get support built in. So if I make this changes to this file that you see here I'm going to hit safe. And as you can see it tells me there is a source control change here. So I'm going to stage my change locally now set stage and I'm going to commit this changes on a type of my message. First Jenkins file and I'm going to commit once committed I can push it to my get hub by just doing push pushing to pushing the master branch to remote and it's done now back here. And the Jenkins UI I'm going to execute the job and see what happens. As you can see there's a bill that's been scheduled and it's running out this time. Let's take a look. Bill 30 still running. Let's take a look at the console output of Bill Number 13 so you can see executed our command maven clean and package. It runs our test after generating the necessary binaries and then it generates our war file if you can see this message. Now archiving and archiving artifacts it means that our build was successful. Let's go back to our script. As you can see the condition to print now archiving message is that this step actually succeeded. And it did this time we'll go back to our dashboard and as you can see the latest bill was a success which was built 13 OK guys. Here we are back in our Jenkins files script and we know it works. But now we need to make a significant change which is we need to actually deploy to one of our Tonka servers. Let's go ahead and do that in order to do that. I'm going to at one stage to our pipeline here is going to be stage. I'll give it a name. It's going to be deployed to staging you know had the necessary steps. This one is going to be pretty straightforward. We're going to do a built job a built job is a function of a pipeline that you can use to trigger a job that is defined and Jenkins. Since we already have define our deployed to stage and deploy to production. In previous lectures in this course we're going to leverage that we don't need to rewrite that step. It's fairly simple. So we're going to leverage that and reuse it here and other benefit that we get by doing it this way. Is that the devil's engineer that manages. Jenkins can actually change the IP addresses or host names for the Tomcat servers that this job gets deployed to without having to require access to the Jenkins files in any way they can change it over there without having to come here and change it anyway. Let's continue here. The job name is deployed to staging and it is that simple. It's done. So we're gonna save our changes. We're gonna come here and stage our changes locally and we're going to commit locally as well to deploy stage head commit and push to the remote GitHub repo and push to remote now with that change deployed let's go back to our console here and execute our package bill so you can see a bill has been schedule number 14 and it's running you should see a trigger to deploy to staging here pretty soon and there it is. It says deployed to staging as on cue so that needs to finish first before our package bill can finish. And as you can see everything finish. Let me make sure I refresh this and everything is blue. No reds meaning that every single successful let's take a look at Bill 14 and the console output. It says that copy copy one artifact from package. In this case package just the name of the job that triggered this job to run and then it triggered a deployment of the web app. Wah file to Tom. Got a we go to our TOMCAT which is this one the one that we define a staging slash web app and there's our application OK let's do a couple of things here. We're gonna do a code change. That way we can verify that we're actually changing something and it's not using some leftover binary from a previous build and two we're going to add our deployment to production. That one is gonna be more interesting we're going to add a little bit more interesting logic. Let's get started. All right guys let's do a couple of things now. First of all let's do the easy one first which is I'm going to open this index GSP file and I'm gonna make a change here. I'm just going to add version 2 and save it. This is to prove that we're actually changing our code. This will simulate a software developer updating their application. In this case a web application that gets built into a binary Wah file that we're going to deploy. The other change that we're gonna make is of course we're still not deploying to production. We need to do that. I'm gonna take my production deployment stage here and I'm gonna paste it here and then I'm going to explain to you just go ahead and do that. Let me grab my clipboard copy and paste. All right. Here should apply to production stay that we just added first thing you're gonna notice is that it's a little more complex than that applying to stage. There's a reason for it. First we're going to add an input message that says approve production deployment. And by the way this request for approval can have as submitter attribute that you can name a specific group of user or one user that will be the person that is allowed to click on that button to approve the deployment. The reason why you would you would do that is because your company may not allow direct deployments to production unless they're actually tested for functionality. The other thing you'll notice about this input message is that it is surrounded by a timeout. In this case the time is five and the unit is days. This means that this stage which is called applied to production will fail in the event that five days go by and nobody approves or rejects this stage in the event of approval. It will proceed to call the bilge up task which has to deploy to production that we define earlier in our Jenkins console. I had a little bit more logic so that I can show it to you. It's call a post Bill step and this case is looking for two conditions. One is either success or fail in the event of failure. You could send an email or notification to a dev ops in the near to have a look in the event of success. You could just say Call deployed to production or email the person that trigger the job. Let's go back to our Jenkins console and see what it looked like. But before we do let's go ahead save this changes and push them to our repo let me make sure it is files properly save as well. You see it now we have two files change. We're going to stage the changes locally the floor to prod. That's the message for our comet and as do the comet and now he's done. And now we're going to push it to our repo and is complete. Okay now let's go back to our Jenkins console and what you're going to notice here is that I'm going to click on Bill's schedule bill for our package and it will take care of calling both deployed to stage in as well as deployed to. OK let's get our bill now. Let's see what happens. Bill Number 15 just started when I click on 15 here see the console output it's running tests running binaries and now says deployed to staging. Good. Good. Let's go back to the main dashboard and now you see it says deploy to production here. Let's take a look gonna go to Bill 15 and you will notice a new item here. It says pause for input. When I click on it and that's the question that we place in our script let's go take a look. This is our script. It says approve production deployment. This is what you see here. And it gives us a couple option proceed or abort. I'm going to proceed now it's a scheduling then deployed to prop job and a completed here as you can see entire pipeline from checking out this from source code triggering the bill deploying to stage and lastly deploying to production as you can see deployed to production loss executed 19 seconds ago and it was successful since we also change a code file. Let's go to both of our TOMCAT servers and verify that everything was deployed correctly. First we're going to go to staging still says hello world here. I'm going to refresh this. Now says Version 2 x. We're going to go to the production line which we haven't touched so far still in the brand new stage. So we need to type web app here and it has the correct deployment that we just did pipeline as code as certainly the way of the future. It makes your workflow so much more comfortable and easy to maintain without having to move back and forth from your code to Jenkins and back in fact if you set up get Pauling within Jenkins You don't even have to go there to hit the bell schedule button. You can just make your changes push you change to the repo. And Jenkins will pick up the changes automatically so you can concentrate on writing code and maintaining your code pipeline and that's it. Jenkins we'll take it from there. See you guys on the next one. Bye by.