Jenkins Deep Dive
Jenkins Deep Dive
1h 47m

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


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


  • 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


The following GitHub repo contains sample Jenkins configurations used within the provided demonstrations:

Supporting Documentation

The following supporting Jenkins documentation is available online: 




- [Instructor] Welcome back! In this lecture we'll quickly summarize what Jenkins provides and what might motivate you to consider using it in the first place, ensuring that you understand the fundamentals and are able to walk away and apply these into your own CICD setups. If however, you're already familiar with Jenkins theory and associated terminology please feel free to skip on forward to the next section. 

Okay, let's begin. Jenkins is first and foremostly a continuous integration and continuous delivery system or CICD for short. CICD is an important concept that needs to be implemented to support the demands and rigors required to build rock solid enterprise software applications. In essence, Jenkins is the go to tool when it comes to implementing CICD. Some of the key features and reasons why you might choose Jenkins are simple installation and configuration, simple web based administration, flexible build jobs and pipelines, customization and flexibility using the Jenkins plugin ecosystem, scalability through distributed builds using build agents and executors, and excellent online documentation with an active user base. 

Now, before we deep dive further into Jenkins and build pipelines it pays to be familiar with and to understand the terminology you'll often here when administering and configuring Jenkins, particularly when it comes to build jobs and pipelines. Therefore, let's quickly review several of the more common terms now. 

Jenkins Master. A Jenkins Master is the central service from which the administration console is served from. And amongst it's many responsibilities the master is mainly responsible for configuration of build jobs, pipelines, and plugins via the web administration console that it serves, build job scheduling, and build job dispatching to build agents. 

Jenkins Build Agent. A Jenkins Build Agent is a seperate server that receives instruction in the form of build job dispatches from the Jenkins Master. Each agent can run it's own particular operating system. For example, you may have a Windows based build agent which is dedicated to executing .net build jobs. Whereas you may also have a Linux based build agent dedicated to building RPM packages. There are other motivations for running separate build agents, which we'll discuss in more detail later on. 

Note, you'll often find in Jenkins documentation the terms build agent, slave, and or node, are used interchangeably when discussing distributed build architectures. In most cases they are the same, minus some subtle differences. 

Build Project. This is used to define the build configuration properties required to build a unique piece of software. Different project types exist for different build requirements. The current build project options that Jenkins provides are: Freestyle Project, Pipeline, Multi-configuration project, Folder, GitHub Organization, and the Multibranch Pipeline. 

Label. A label is a user defined piece of metadata used to group together different Build Agents. For example, Labels can be used to group agents by operating system or by build technology. 

Node. Defines by Label a machine which is capable of executing a build pipeline or project. This defines where the execution should take place. Nodes are used within Scripted Pipelines. 

Agent. Defines by Label a machine which is capable of executing a build pipeline or project. This defines where the execution should take place. Agents are used within Declarative Pipelines. 

Artifact. An Artifact is an output file generated as an outcome of a Build. An Artifact for example could be a JAVA JAR file, or a .net assembly, or just a plain old ZIP file. Artifacts are considered immutable, that is an artifact should not be altered externally to the build process that created it. Artifacts are often tracked and traced by applying a fingerprint, which is just a checksum over the Artifact in question.

Pipeline. A modeling concept that embodies and encapsulates the core build logic and workflow. Jenkins supports the creation of pipelines using two different syntaxes, the Scripted Pipelines and the Declarative Pipeline syntax. 

Scripted Pipelines. Are created using the Groovy language, providing you with freedom and flexibility to build very customized pipelines, however to be productive requires you to be knowledgeable in Groovy and this extra required learning curve may not be desirable to build and release support personnel unfamiliar with Groovy. 

Declarative Pipelines, on the other hand, provide a more simplified and cleaner syntax. Declarative Pipelines have an opinionated form of syntax meaning that they are more defined with a guiding structure which must be followed. They are less flexible than scripted pipelines, but easier to work with if lacking Groovy knowledge. 

Stage. A pipeline stage is used to segment distinct sub sections of the overall pipeline. Defining individual stages has several benefits it allows you as the author of the pipeline to apply structure. Secondly it is used to provide build visuals to highlight progress during build execution. Typical stages model key and important stages within he CICD cycle, such as Clone, Build, Test and Deploy. An individual pipeline stage may consist of multiple pipeline steps. 

Step. A pipeline step defines a single build task and what specifically should happen. A Pipeline stage typically wraps multiple pipeline steps. 

Workspace. Is a dedicated filesystem directory where build work is performed for the current pipeline or build job. When troubleshooting builds, this particular directory and the sub directory structure within it is useful to interrogate. The workspace will be created on a particular build agent for which the pipeline or build job has been configured to run on. 

Downstream. Downstream represents another pipeline or build job that will be triggered as a consequence of the current running pipeline or build job. 

Upstream. Upstream refers to the pipeline which triggered the currently running pipeline or build job. 

Okay, that concludes the slide show. Having good comprehension of Jenkins terminology will greatly assist you with learning Jenkins. In needed times when you are stuck you'll know what to search for and filter on within the extensive online documentation. 

Okay, go and ahead and close this lecture and we'll see you shortly in the next one.

About the Author
Learning Paths

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).