A quick summary of the focus of this course as well as the approach taken. This course focuses on step by step hands on examples, backed up with a minimal amount of slides to help teach needed theory.

A description of the states of build maturity, including Minimal build process, continuous inspection, and finally continuous integration.

A quick summary of how the Jenkins system works by running on Jetty on a host system, and how on a more macro scale Jenkins is basically an executor of plugins.

A quick background on the instructor, Jason Taylor, and a dive into his experience as the build guy throughout his professional career.

An overview of the different computing platforms that will be used and what software will be installed on each, including Chrome, Git, Atom, Java, Maven, and Jenkins.

A quick overview of what tools will need to be installed, including the web browser Chrome, the source control tool Git for Windows, the text editor Atom, the programming language Java (JDK), the build tool Maven, and the build tool Jenkins.

A quick overview of what tools will need to be installed, including the web browser Chrome, the source control tool Git from Apple, the text editor Atom, the programming language Java (JDK), the build tool Maven, and the build tool Jenkins.

A quick overview of what tools will need to be installed, including the web browser Chrome, the source control tool Git from apt-get, the text editor Atom, the programming language Java (JDK), the build tool Maven, and the build tool Jenkins.

An overview of what basics will be covered in this section, including creating our first jobs, working with that job, managing Jenkins, managing plugins, changing configuration settings, and setting up the build languages Jenkins will use.

Creating our first job in our newly installed Jenkins installation, adding a build step to echo a basic command back to us, and then finally running the build and viewing the results.

Exploring the Jenkins interface on the main level to show how Jenkins handles our newly created job.

Making our job intentionally fail in order to give an excuse to disable and then re enable the job.

Renaming our job, including making sure we have a separate name for the project URL to make the URL web friendly. Afterwards creating copies of our job to have multiple jobs to work with for future lessons.

Researching, installing and updating plugins in our Jenkins installation, including an instillation of a purposefully out of date plug in.

Deleting specific builds within a project, as well as deleting an entire project when it is no longer needed.

Looking at a few items in the manage Jenkins section of Jenkins, including a few sections we will cover in greater detail in upcoming lectures.

Setting up the basic configuration in Jenkins, such as the number of executors, system message, and attaching all of the tools we will use in this course.

An overview of the process for this section, including validating our project outside of Jenkins, creating a Maven based Jenkins project, reviewing build results, integrating Maven deeper with Jenkins, and creating a workspace for Maven projects.

Compiling our project from GitHub on our local system first in order to ensure that it is working.

Setting up a freestyle job to use the command line Maven tool in order to build our project by specifying the goals.

Taking a look at the workspace that accompanies the Jenkins project, which contains the entire Maven project.

Installing the Maven Integration plugin into Jenkins in order to build our Maven project with more features.

Taking a look at the specific features provided by the Maven integration plugin, namely how it allows us to see build results for the individual Maven Modules.

Intentionally failing our Maven project to show what a failure looks like with the Maven project type.

Automating builds by building our project every so often on a set schedule using the cron-like scheduling format used in Jenkins.

Using the cron-like format in order to periodically poll changes from our source code management to only build only when changes are detected on our GitHub repository.

Looking at Jenkins views, which are tabs on the Jenkins homepage that allow us to sort our projects into groups.

Looking at our local files of our Jenkins build system, including the location within our build system where our Jobs and their workspaces are stored.

Taking a few moments to review the patch notes for Jenkins before using the Windows automatic upgrade system within Jenkins itself. Afterwards is an explanation of how to upgrade Jenkins on Mac and Linux.

An overview of what will be covered in this section, such as Java-focused code quality analysis tools, plugins to help with quality analysis, building and reviewing our quality analysis, and enforcing code quality by failing builds falling behind a threshold.

Reviewing the source code for our time tracker project on GitHub in order to understand better how the unit test dependencies work, where the unit test Java code is located, and how the project itself fits into all of this.

Installing the quality analysis plugins we will need to do unit testing, including Junit, PMD, FindBugs, and Checkstyle, configuring them to work in our project by adding their goals to the Maven project.

Building our time tracker project with the quality metric plugins enabled so that we can look at how Jenkins records the build trends.

Reviewing the Unit test results for our time tracker project within the terminal output as well as within the individual modules for our Maven build. Also will causing a test to fail in order to observe what that does to our results trend.

Reviewing the code quality reports to view where specific code quality issues come up in our build, such that we will be able to fix them in later lessons.

Using thresholds from the static analysis collector plugin in order to either make our build fail or become unstable based upon the unit test results we have run on the build.

Making changes to our project source code in order to improve our quality metrics to hopefully bump our project from the failing threshold to the unstable threshold.

An overview of the ways we will create a Jenkins artifact repository in this section, which is not a long term solution to publishing build artifacts but rather a simple one we can do within Jenkins.

Installing the Maven Repository Server plugin in order to prepare our repository to be able to create a Maven repository artifact.

Building our application with the Maven repository server plugin enabled, reviewing the results of the published artifact directory structure.

An overview of the artifact topics covered in this section, namely installing and configuring Tomcat before using Jenkins to deploy to Tomcat.

A guide to fully installing and configuring the Java tool Apache Tomcat onto our local system in order to then deploy our Maven build artifacts to. It also covers how to start and stop the service and login to our Tomcat server.

A guide to installing the Deploy plugin needed to send the build artifacts to the Tomcat web application server, then configuring our Time Tracker project to use that plugin to deploy the generated WAR file to that server.

Deploying our web application to Tomcat using the Deploy to container plugin in Jenkins, before making a few changes and seeing if Jenkins can re-deploy with the new changes.

An overview of the security topics that will be covered, including manually disabling security, re-enabling basic security, using matrix-based security, and using role based security.

Editing the Jenkins configuration file as a last resort if you manage to lock yourself out of your Jenkins installation and just have to get back in.

Enabling security within Jenkins by going to configure global security under our Jenkins management tools. This will also allow us to set up some basic security features, such as restricting non-logged in users from building or editing projects.

Setting up matrix-based security in order to offer finer permissions for each individual logged in user, as well as users who aren't logged in, and a special admin user account. This includes permissions that vary on a project by project basis.

Changing our security to role-based using the role-based authorization strategy plugin. This will allow us to group users together in roles before assigning them permissions all at once.

Using the previously installed role-based security plugin in order to specify more fine grain access to individual projects. We will use a regular expression to automatically add a user to a project when it has certain text as a prefix.

An overview of the topics that will be covered in this section on AWS lightsail for Jenkins Production, with an explanation of what creating a production style environment for Jenkins can do.

Creating a new AWS account and signing into it, making sure to fill out the payment information as it will be required to follow along.

Reviewing the scripts and files we will use in this section to automate the setup of our Jenkins installation on our remote AWS server.

Using the configuration and script files we just reviewed to spin up a Jenkins server on our AWS Lightsail remote server.

Setting up a static IP address for our Lightsail installation and then associating it with a domain name record, forcing the association on our local system before the global DNS record updates to include it. You must own a domain name in order to fully complete this section.

Accessing our instance on AWS lightsail using the ssh command on our terminal and the static IP address we just associated with our instance.

Accessing Jenkins on our remote AWS installation and walking through the setup wizard to be able to start using Jenkins.

Starting, stopping, and restarting our Jenkins instance on our AWS lightsail installation using the lightsail interface.

Using an instance snapshot to back up all of the information on our Jenkins server. This backup is a complete copy of the hard drive, but any further snapshots only store the changes between snapshots.

Creating a new Jenkins server instance from our backup snapshot, then performing a system upgrade on that Lightsail server, before finally switching our static IP address to our new server. This is a common production pattern called zero downtime deployment.

Cleaning up our Lightsail workspace by deleting our unwanted servers and snapshots, saving money in the process!

Updating the ssh fingerprint of our new Jenkins server instance in order to allow login via ssh on the terminal.

Beginning the process of encrypting traffic to our web server by enabling SSL security. This video contains theory about SSL, as well as the process of setting up our new Lightsail server instance with the necessary startup shell script.

Actually enabling SSL on our Lightsail server by using the command line to log into our Lightsail server.

Updating the core Jenkins server as well as several plugins we have installed onto it on Lightsail. This is done on the command line by logging into our instance using ssh.

A description of how to grow beyond what we have done with Lightsail in this section, including VPC peering, getting a larger instance, setting up automation tasks, scheduling snapshot backups, and security hardening.