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:
- Creating and configuring pipelines using a Jenkinsfile
- Configuring Jenkins pipelines using the Blue Ocean interface
- Defining build execution environments using docker containers
- Setting up and scaling out Jenkins with multiple build agents and executors using SSH
- Setting up build pipelines for Java-based projects using Gradle
What you'll learn:
- How to scale out Jenkins using Master and Build Agent setups using SSH
- The benefits of codifying pipeline build instructions using a Jenkinsfile
- How to leverage Docker containers within a Jenkins pipeline to provide additional build isolation and flexibility
- How to install and use the newer more modern pipeline centric BlueOcean user interface
- 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] Welcome back! In this lecture, we'll introduce you to the important concept of a Jenkinsfile and the associated benefits with which should motivate you to use one. Okay, let's begin.
In essence, a Jenkinsfile is nothing more than another code file, but for which contains all of your pipeline build instructions, regardless of whether they are in the format of a declarative pipeline or scripted pipeline. So the immediate question is why would you want to use one when you can simply paste your pipeline configuration directly within the Jenkins web administration console? Well there are several benefits that come with using a Jenkinsfile. For starters, now that your pipeline configuration exists in a file, you can and should treat this file like all of your other coding assets.
Primarily speaking, you should now check this file in alongside the rest your codebase into your source control repository. In doing so, you immediately gain several benefits. For example, having an audit trail of change, having a single point of truth for the pipeline configuration, developers who have access to the repo can contribute and maintain the build implementation, it provides a documented view of the build process, if you've configured Jenkins to auto trigger a build when any push is detected within the code repository, then if you modify the Jenkinsfile and push this change, Jenkins will auto rebuild the pipeline for you, centralizing and parameterizing the pipeline configuration into a single Jenkinsfile allows you to configure multiple pipeline build jobs where the parameters are injected at build time. For example, using environment variables provided by Jenkins. This in turns minimizes unintentional configuration drift between the different build jobs.
Having just reviewed some of the motives as to why you should consider using a Jenkinsfile, it would be a remiss to not consider any downsides. The only real key concern you should be aware of is that of credential management. A Jenkinsfile as we've already mentioned should be treated like a standard coding asset and therefore stored within your source control repository. If your pipeline requires credentials to authenticate to say, other 3rd party systems, for example SonarQube for static analysis or Artifactory for artifact management, then you do not want to expose these credentials directly within your Jenkinsfile, since this file is committed into your source control repository, and anyone with access to the repository gains access to the exposed credentials. Instead consider using the internal Jenkins credential store to configure and host the credentials securely and importantly, externally to the Jenkinsfile. Then within the Jenkinsfile you query for the credentials at build time, asking for them by a assigned credential id that has been preconfigured and mapped to the credentials in question.
So, now that you understand the benefits of a Jenkinsfile, and you've gone ahead and codified your pipeline instructions into a Jenkinsfile, how do you go about configuring Jenkins itself to use it at build time? Well, it's very simple. Within the pipeline configuration, you simply change the pipeline definition setting to be the value Pipeline from Jenkinsfile. You also need to declare the location of the Jenkins file relative to the project root directory. Typically, and often by convention, the Jenkinsfile is hosted in the project root directory.
Okay, that completes this lecture on how to configure a pipeline using a Jenkinsfile.
Go ahead and close this lecture, and we'll see you shortly in the next one.
Jeremy is the DevOps Content Lead at Cloud Academy where he specializes in developing technical training documentation for DevOps.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 20+ years. In recent times, Jeremy has been focused on DevOps, Cloud, Security, and Machine Learning.
Jeremy holds professional certifications for both the AWS and GCP cloud platforms.