The course is part of these learning paths
This course introduces you to Jenkins, a popular open-source tool used to perform Continuous Integration and Continuous Delivery.
We review the key Jenkins features and associated terminology. We then take you through a deep dive in configuring Jenkins to perform automated builds using the Jenkins web administration console in hands-on demonstrations, familiarising you with Jenkins and how to administer it. We’ll demonstrate features such as:
- Installing and setting up Jenkins
- Creating and configuring pipelines manually
- Creating and configuring pipelines using a Jenkinsfile
- Triggering build pipelines, manually and automatically
- Navigating downstream and upstream build projects
- Connecting to version control repositories such as GitHub
- Setting up build pipelines for Java-based projects using Gradle
- Recording artifacts and test results
Learning Objectives
What you'll learn:
- The basic principles of build automation as implemented within Jenkins and how they should be applied to manage and maintain building, testing, and deploying your own enterprise software projects
- How to install, set up, and configure Jenkins pipelines
- The key differences between Jenkins declarative and scripted pipelines
- How to manage build artifacts and test results
- How to integrate and leverage third-party build tools like Gradle, Maven, Yarn, Webpack, and many more within a Jenkins pipeline
Demonstration
This training course provides many hands-on demonstrations where you will observe first hand how to use Jenkins to build and release different types of software projects, for example:
- Building a front-end application which has been developed using the React Javascript framework, using technologies such as Webpack and Yarn
- Building a back-end application developed using Java, Gradle, and Docker, requiring Jenkins to compile the source code, packaging it into a WebArchive file, and then finally releasing it into a Tomcat-based Docker image complete with Splunk-based instrumentation for logging and monitoring
Prerequisites
- A basic understanding of CICD, or Continuous Integration and Continuous Delivery
- A basic understanding of software development and the software development life cycle
- A basic understanding of version control and associated workflows
Intended Audience
- Software Build and Release Engineers
- Software Developers
- DevOps Practitioners
Resources
The following GitHub repo contains sample Jenkins configurations used within the provided demonstrations:
Supporting Documentation
The following supporting Jenkins documentation is available online:
- https://www.jenkins.io/doc/book/
- https://www.jenkins.io/doc/book/pipeline
- https://www.jenkins.io/doc/book/pipeline/syntax
- https://www.jenkins.io/doc/book/pipeline/pipeline-best-practices/
- [Instructor] Okay, welcome back! In this next demonstration, We'll use Jenkins and we'll create our first build project. In this particular case, we'll create a basic freestyle project and we'll demonstrate the concept of using environmental variables exposed by Jenkins.
So, we'll log back in. Click the create new jobs link. For our build job, we'll call it BuildJob1 and we'll configure it as a freestyle project. Now freestyle build jobs are considered general purpose build jobs and is often a good start for setting up your first project. We click on OK. So, entering into the configuration options for the freestyle project, the first thing to draw your attention to is the tabs at the top of the configuration page. So, we have General, which covers the general configuration options. Source Code Management, covering source code management options. Build Triggers, Build Environment, Build and Post-Build Actions. We can also scroll to these by scrolling up and down on the page. So, under Description we'll paste in the Build Job name. We won't worry about any of the general configuration options and we'll jump straight down into the Build area. So, clicking on Add Build Step. We're going to execute a shell script. So, for our very first build all we'll do is echo out Build Step, Build Step 1. We'll click Apply and we'll click Save. From here we can trigger the build by clicking the Build Now link. So, we've scheduled a build and under Build History this build has already executed and run. So we click on the build number, #1, and we click on Console Output.
You can see all of the script output for this build job. And in this case, we simple echoed out, Build Step 1. The statement is echoed here and, as you can see, we had a success message to conclude that the build was successful. So, let's go back now, to the build project. Click on the Configure link and let's flesh out the build script a little bit more. So, scrolling back down to the Build section. Next thing I want to draw your attention to is the list of available environment variables. So if we click on this link, Jenkins provides convenient documentation for all of the environmental build variables that are available. So here, the first one is BRANCH_NAME, which gives you the branch name for the source code that you might be building on. Other interesting ones are the BUILD_ID, which gives you the current build ID for the build job. Likewise, the BUILD_NUMBER. So each sequential build, the build number will increase by one. So, let's try using these. So, back within our build configuration. The next thing we'll do is echo out $ and BUILD_ID.
Another thing we'll do is we'll add a second build step. So again, we click on the Add build step, Execute shell. And this time we'll echo out Build Step 2 and we'll echo out the BUILD_NUMBER, along with the BUILD_URL. Apply, click Save. Again, we trigger the build by clicking the Build Now. That schedules the build. The build has already been triggered and we click on Build #2. We then click on the Console Output for this build. And again, we can see the full output of our build script. So, Build Step 1 runs first. You can see now that it's echoing out the build id, and that we also have Build Step 2 executing. And in this case it echoes out the build number and the build URL, which is a convenient link back to the build job. So, we could actually take a copy of this, open up a new tab, paste, enter, and it takes us directly back into Build Job #2. Okay, go back to BuildJob1. Click on Configure. And we'll scroll down. And this time, we'll update the first build script. This time we're going to echo out, we scroll down to WORKSPACE. So, the WORKSPACE is a directory path to where the build actually takes place on the server that the build is executing on. In this case, it's building on the master link. So, we've added in our echo statement. And the next thing we'll do is we'll actually do a directory listing from that particular directory. Again, we'll Apply, click Save, and Build Now again. So, this will kick off Build #3. We click on it, go back into the Console Output, and here we can see that the workspace variable is holding this value. Which is /var/lib/jenkins/workspace and BuildJob1. Here we're doing a directory listing on that same directory. And, at the moment, that directory is empty.
Okay. Let's close this window. Go back to our original window. Click on BuildJob1 again. Click on Configure. Scroll down to the build scripts, And this time, what we want to do is actually write some files out to our workspace. So, this time I'll take a shortcut and I'll use the cat command to write out to the workspace directory into a file called file1. And all I'm going to write out is some text into this file called some build data. We close it off by using the EOF character sequence. I'll copy this and paste it again to write out into a second file called file2. Okay. Apply, Save. Now, before I trigger a new build, notice that for any build that we run we actually have a link to the workspace. So, if we look at the workspace, you'll see that it's actually empty. There is nothing in it that we wrote out in the last build. So, let's now trigger the build. The build's been scheduled. And this will result in Build #4, which is completed. If we click back on Workspace, this time you'll see that we actually have two files. Which are the two files that we wrote out to using the cat command in our build script. We can view them. As expected, some build data. Likewise, file2. Some build data. We can actually download the files by clicking the name of the file, file1. Results in a download. Likewise, file2. Results in file2 coming down. And in the case we were running a build job that has many, many files in the build workspace, there is a zipped version that we can use to download the entire workspace.
Okay. One more thing in this particular demonstration that we'll show you is a different approach to triggering the build. So, if we click on the Build Triggers tab, we're taken to the Build Triggers configuration area. You'll notice we have different options for triggering the build. For this particular demonstration, we'll choose the top option to trigger builds remotely. For this setup, we need to provide an authentication token, which will allow us to authenticate to Jenkins when we try to trigger this particular build job. So, we'll create the authentication token to be a secret value only known to us. In this case, secret-token. Beneath this is the actual URL that is used to invoke a build of this build job. Where we substitute out the token_name value with our secret token. Okay, we'll click Apply, Save. We'll then open up another tab, we'll paste in our triggering URL. Carefully, with the token specified, in this case carrying the secret-token value that we set up. We click Enter.
Although the screen has come back blank, this has actually worked. And we can tell this by going back into Jenkins. We'll click on the BuildJob1 link. And here we can see that a new job has been triggered and that it completed successfully. If we go back again and we bring up developer tools and we click Enter. You see that we get a 201, which is a success code. And again, if we refresh this page, and our new job has been created.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).