The course is part of this learning path
This course introduces you to Jenkins, a popular open-source tool used to perform Continuous Integration and Continuous Delivery.
We spend time early on reviewing 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, ensuring that you become familiarised 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
What you'll learn:
- The basic principles of build automation as implemented within Jenkins and how should be applied to manage and maintain building, testing, and deploying your own enterprise software projects
- How to install, setup, 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 3rd party build tools like Gradle, Maven, Yarn, Webpack, and many more within a Jenkins pipeline
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 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
- 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
- Software Build and Release Engineers
- Software Developers
- DevOps Practitioners
The following GitHub repo contains sample Jenkins configurations used within the provided demonstrations:
The following supporting Jenkins documentation is available online:
- [Instructor] Okay, welcome back! In this demonstration we're going to carry on from where we left off in the previous demonstration, but this time, we're going to set up a triggering of our build, based on any time that we commit our source code back into GitHub.
So up until now, all our demonstrations have been manually triggered. That is, within Jenkins, we've had to click the build now link. So let's get started. Again, we log in to Jenkins. We navigate in to our previous build job, BuildJob3. We'll click on Configure. And we'll quickly review the current settings. So at the moment, we've indicated that it's a GitHub project found at this URL. We've set up source code management and specified the repository URL. And then down towards the bottom, we specified some basic execution commands to do the third-party library install as well as the transpilation process. This time, we'll scroll back up, and under build triggers, we'll enable the GitHub hook trigger.
We'll then jump over in to our GitHub repository, and this is the repository that we're building within Jenkins. We then click on settings, navigate to Webhooks, click on the Add webhook button, then under the payload URL, we'll paste in a link back to our Jenkins server. So our server is running at this public IP address, port 8080, and we need to specify the path github-webhook. We specify the content type as application/json. Under "Which events would you like to trigger," we're going to trigger on just the push event in to our repo. We leave the Active enabled, and we click the Add webhook. Next, we go back to Jenkins, and we'll apply the settings, and we'll click save. We then navigate back to the react-webapp, and we'll copy the clone url.
We'll jump back into our terminal. We'll make a new directory called JenkinsDemo. We'll navigate into it, and we'll git clone our repository. We'll navigate into the react-webapp directory, we'll do a directory listing, and from here, we'll start up visual code, and we'll make an edit. We'll navigate into the source directory, and this time we'll open up App.js. And on line 22, we'll just tag on version 2.0. We'll save the file, we'll jump back into our terminal, we'll do a git status. We can see we've updated or modified the App.js file. A git commit - a to add - m for message. updated App.js. Enter. So now that we've set up our web hook, when we make any connects back to our repository, GitHub in the background will make an HTTP post to our Jenkins web server. But for our Jenkins web server to accept it, we need to update the associated security groups to whitelist the GitHub public IP addresses.
Now the public IP address range that GitHub uses can be found at this documentation link. So if we navigate to it, you'll see here that you can retrieve the list of IP addresses from the this Meta API endpoint. So let's click on this. And here, we can see the three address ranges that GitHub uses for its webhook mechanics. So let's jump over into the AWS console. I'm running the Jenkins master server as an EC2 instance. So I've already pre-created a security group that has these three address ranges in it. So on my EC2 Jenkins instance, I'll select Networking and Change Security Groups. Here, I'll attach the GitHubHooks security group. If we click on it, click on the Inbound tab, we can see that each of the address ranges have been added as an inbound rule to port 8080.
Okay, so with everything in place, we'll select our Jenkins web server. We'll refresh this page. You'll notice that we still have only one build job that has been executed. We now jump over into our terminal, and we'll do a git push. So we'll push our updates into our GitHub repository. Okay, that is completed. We'll jump back into Jenkins, and we'll wait for a bit. So here we can see that a trigger has happened, and that it's now executing build job two. So in summary, what we've seen here is that we're able to commit to GitHub and automatically trigger a build within Jenkins, so no longer do we have to do a manual build now. This is a really important concept that you need to understand and reapply when you build your own CICD pipelines.
The point is, anytime that you commit to your single source of truth, your source repository, you should perform an automated trigger of your build pipeline to validate any check-ins into your source repository.
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, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, and Kubernetes (CKA, CKAD, CKS).