Building Node.js application with Jenkins

[Music] hey guys in this video we will learn how to build and prepare for a deployment of a typical nodejs project in Jenkins this video is a part of a larger tutorial series and you can either watch it as a standalone tutorial or if you need a little bit more context on how to set up Jenkins how to make it up and running check out the link to the complete playlist that is fully published on YouTube and completely free in the description for this video so now let's go on and configure Jenkins for job in no GS so what we'll do is we'll go and click the new item here because we want to create a new job here we will enter the name so I will call it nanogram exactly as a name of our fictional website and I will choose a type as a freestyle project these days it's considered to be slightly better to use pipeline type of a project but it is a slightly more advanced configuration and we'll go there soon after a couple of videos once we learn how freestyle projects work because freestyle projects are significantly easier than pipeline projects let's go and click OK and this is already known build configuration screen in this build configuration screen I will go right away or scroll down to source code management and here what we want to do is to choose our version control system in this case it is get my project is hosted on github and you can paste the repository URL here and the URL can be in any style that gets supports so I'll go to my github account and I'll find the button clone or download on my project page and I will make sure that I'm cloning it with HTTPS not with SSH but was HTTP why is it important because right now I do not want to add authorization to this project just yet because authorization will be subject for another video in this tutorial series and right now I will be using public projects so if your project requires credentials check out now the video where we will be talking about setting up credentials and Jenkins but for now I'm just assuming that this project is publicly accessible at least for reading all right so now git is configured and right away what I want to do I want to save this changes and I will trigger the build of this job and we'll make sure that Jenkins has access to get and it will receive the files from my project from my git repository let's go now to workspace see this blue bowl here means that everything went well so there was no errors but still it's better to make sure so let's go to the workspace and check if the files are there and yes I see all the files from my project downloaded successfully that means that Jenkins could establish connection to gate and could get my source code so this first step is already established now it's time to build our project so let's go back to configuration click configure and go to the build part or scroll down to the build suit you can scroll it this way or you can click on the tabs on the top of this way nowadays we're saying that an OGS there is no built per se so you don't have to convert your JavaScript into some sort of a binary form and package it into some sort of a form like for example for Java project this is very typical you know G as all you really have to do is to install the dependencies and then run a unit test and then maybe you want to archive the results so that you can deploy it to the server so this is exactly what we'll do in this video I'll create a new build step and I'll execute shell here and here I can write the script that will be executed right after Jenkins downloaded the fresh version of the code it is worth noticing that this script will be executed on the box that is running Jenkins and on the OS that is running Jenkins so if you are running Jenkins for example on Windows it will be Windows that is executing this script so make sure to use the appropriate shell commands that your OS will understand so here I will run npm install and this command will be well understood by both windows and linux and that will download the dependencies all right and let's save it and just try to trigger the build one more time and see if node modules appears together with this project now as usual let's open workspace and check that node modules are there so now you have the whole package that you need to deploy to the server and the next step of the build would be to archive the whole package and make sure that you can safely on the server so right after installation is over I'll do tar see that F I'm creating zipped file and then I will put the name of the file so let's call it nanogram dot tar dot G Z and then I will list the folders and files that I want to include into this archive so that will be node modules obviously names yes package.json and maybe public because that's where my public HTML files are residing and finally license for your specific project of the list of files may be different well in this case just use your files that you will want to have deployed to your server in this command or maybe if you're building a library or NPM module the next step for you would be to run npm publish in this video we'll create an archive that contains all the resources for this application to run so all we will have to do is to upload this archive to the server extract the contents of this archive and around the application there alright let's save and run our build once again now the build is completed really quickly and now you will see that there is one more file that just appeared in our workspace folder and it's called nanogram tar.gz just like in our previous videos this file contains everything that you need to run this application on your server but we can do a couple more things to make this job configuration even better so let's go back to configure screen now let's scroll all the way to the build and look at this command once again I'm always creating the same file that is called nanogram tar.gz it would be nice to have couple of additional things first I would like to include the number of the built into the name of the archive this way if I have several files lying around my hard drive or in my server I know exactly what was the build number for this specific artifact and doing that is very simple with the help of environment variables that Jenkins is exposing to our job during the build so here see the list of available environment variables let's go and click this link Jenkins will open its documentation and here you see all the environment variables the Jenkins is providing to you during the build time and you see there is plenty of them and the most interesting one for us is a build number I can see it straight away but it should be their build number here it is I will use this number as the part of a name of my file so I'll go back to the configuration and I will call this file nanogram - dollar build number tar.gz now let's save it and run our build once again to make sure that the build number is indeed added to our build artifact and I'm sorry let's go back to the project and open workspace here it is nanogram - for tar.gz if you want to be a little bit more fancy you can even include the commit number into the name of the artifact so this way you will know exactly which commit caused that build or there are some other techniques to do that for example you could include the file that you dynamically generate during the build into this archive that tells exactly when the build was made what was the ID of a commit and what was the name of the server etc and so on so some additional information now the small issue here is that each time when I will be building my project I will create another archive because they are not cleaned up they are not deleted there are two ways to address it first and foremost you can go and say that you want to wipe the whole workspace before the build so if you scroll down all the way to build environment you will see this option here delete workspace before build starts this approach could work but I would not generally recommend it for an OG as project because it will simply mean that NPM will have to recreate node modules and even doing so from the cache is kind of heavy operation so I don't want to delete the whole workspace I just want to delete the old files before the build and for that I'll just go to my execute shell and add another command here rym ref everything that ends with tar dot G Z so this way at the beginning of the build I will delete all the older archives but I will keep my current archive because I'm deleting it at the begin of the script and not at the end of the script when the file is created so let's save it and let's build it again now if I go again to the workspace I'll see that nanogram five tar.gz is here but not the other files now there is one more saying how to improve this build we can go back to configuration and we can ask Jenkins to keep build artifacts so that they are not wiped and they are easy accessible afterwards in this way if you will ever need to restore your build to some older version and include all the dependencies that were downloaded at that time Jenkins will keep that artifact for you of course there are better options to do so there are artifacts repositories so it's strictly speaking it's not Jenkins job to keep those artifacts forever but nevertheless it is pretty convenient solution at least up to the point when you have your own doctor repository up and running and you can publish artifacts properly alright so we will add a post build action and we will say that we want to archive the artifacts and here we will need to tell Jenkins what are the artifacts for this project this field over here is not exactly a rag expert it's rather a pattern that is used internally and Jenkins and you can find the documentation about how this patterns work in this link but the easiest way is just to show how it works and nanogram - star dot tar.gz will quite intuitively match all the files that start with nanogram and and with star cheesy no matter what is in the middle Jenkins will copy and keep this file separately so even after you're deleting all the tar.gz files in your workspace this artifacts will not be affected because Jenkins will keep them separate from the workspace so let's save and see how it will work let's run the build again and this is build number 6 for us it's taken a bit longer now instead of going to the workspace let's go to the build history and click on the build number 6 and you see here this additional section that is called build artifacts and here this artifact will be accessible for as long as Jenkins is keeping the bells if you want to give this artifact forever well you can click keep this built forever and Jenkins will keep this built forever this way you will be always able to download this artifact alright guys thank you very much for watching in the upcoming videos we'll talk about credentials in Jenkins we'll see how to authorize against the private repositories in git and also we'll see how to deploy this resulting artifact to the server and run our application with p.m. - see you in the next videos bye you

Channel: Juriy Bura

Views: 29,303

Keywords: continuous integration, jenkins node.js tutorial, jenkins, node.js, deploying node, node.js build

Id: XQt4fzt3bUc

Length: 11min 48sec (708 seconds)

Published: Wed May 13 2020