Jenkins Fundamentals:

OBJECTIVES

● Introduces students to Jenkins and the Continuous world

● Prepares students to take other courses that delve into
the specifics of how to work with Jenkins

AUDIENCE

● Any software professional who wants to learn about Jenkins.

PREREQUISITES

● Students should have some general understanding of the software development cycle.

APPROACH

● This class introduces concepts required to work with Jenkins

COURSE SECTIONS

● This course contains the following sections:

■ The role of Jenkins in the software development cycle
■ Why the continuous workflow is important
■ How Jenkins interacts with Source Code Management systems
■ The role of testing and how to implement effective testing
■ Contributing to the Jenkins Project

JENKINS OVERVIEW

MEET JENKINS

Jenkins is an open source automation server that enables developers around the world to reliably build,

WHAT IS JENKINS

● #1 Continuous Integration and Delivery server

● Created by Kohsuke Kawaguchi in 2006
■ Original project: "Hudson", renamed "Jenkins" in 2011
● An ​independent​ and ​active​ community (​https://jenkins.io​)

JENKINS POPULARITY: THROUGH THE ROOF

WORLDWIDE ADOPTION
JENKINS IS THE CD ORCHESTRATOR
 CLOUDBEES INTRODUCTION

CLOUDBEES AND THE JENKINS COMMUNITY

 ● Kohsuke Kawaguchi
■ Community leader and Chief Scientist at CloudBees
● Code and Releases
■ CloudBees partners with the community on development
■ CloudBees engineers contribute significantly to the Jenkins project
■ CloudBees partners with the community on releases
■ CloudBees contributes fixes back to the community
● Publishes a monthly newsletter for the Jenkins community
● Organizes Jenkins World and supports numerous Jenkins events
CLOUDBEES INC.

● Incorporated March 9, 2010

● Several hundred people worldwide
● CloudBees is the enterprise DevOps leader, powering the continuous economy
● We help our customers deliver ​software at the speed of ideas

CONTINUOUS WORKFLOW

WHAT DO YOU NEED?

After the code has been completed, what activities are required to release that modification?
SUMMARY OF REQUIRED ACTIVITIES

● Put the modified code into SCM

● Build code
● Test the built code
● Deploy the tested code
● Freeze a copy of the deployed code

CONTINUOUS INTEGRATION LOOP

 IN THE NOT-SO-GOOD OLD DAYS

● Development, Quality Assurance, and Packaging/Deployment were siloed

■ A large group of developers coded for months
■ Developers handed the "completed" code to Quality Assurance
■ Quality Assurance ran tests and handed bugs back to developers to fix
■ Developers fixed the bugs then handed the code back to Quality Assurance,
who reran the tests
■ Quality Assurance handed the tested code to Packaging/Deployment,
■ Packaging/Deployment released the product
Current practices advocate collaboration between different teams and more flexibility in planning and
development and shorter development cycles. Three major philosophies:
■ Agile — Emphasizes adaptive planning and evolutionary development. Work is planned
and completed in "sprints" (usually 1-2 weeks worth of work), with frequent (usually daily)
"scrums" where all team members report progress and plan next steps. See ​Agile Manifesto
■ DevOps — Extends the Agile philosophy into operations and production by advocating for
the automation and monitoring of all steps in the development cycle. See ​What is Devops?
■ Continuous — Implements Agile and Devops philosophies with tools that thoroughly test
each code modification before it is integrated into the official source.
 AGILE AND CONTINUOUS

● Agile mostly applies to the earliest steps of the process

● Continuous applies to all stages through deployment

CONTINUOUS PHILOSOPHY

● Integrate code often, at least daily, so that integration is a non-event

● Builds are triggered automatically based on ​commit​ and ​merge​ actions
and the success of upstream builds
● Each integration is verified by an ​automated​ build (including test)
● Automate the complete build-test-deploy cycle
■ Activities always run in the same order
● Build and test each code modification
■ Find problems sooner, when they are easier to fix
Continuous Integration does not get rid of bugs, but it does make them dramatically easier
— Martin Fowler

CONTINUOUS INTEGRATION, DELIVERY, AND DEPLOYMENT

● Continuous Integration (CI)​ is the frequent, automatic integration of code

■ Automatically tests all new and modified code with the master code
● Continuous Delivery (CD)​ is the natural extension of CI
■ Ensures that the code is always ready to be deployed
■ Manual approval is required to actually deploy the software to production
● Continuous Deployment​ automatically deploys all validated changes to production
● Frequent ​Feedback​ enables issues to be found and fixed quickly
HOW TO DO CONTINUOUS DELIVERY

● Have a collaborative working relationship with ​everyone​ involved

● Use ​Delivery Pipelines​, which are automated implementations of your product’s lifecycle
 JENKINS WORKFLOW

● Jenkins automatically performs all activities required to deliver your software

■ You specify how to build and test your software and when/where/how to
deploy it
○ Use a tool such as ​Apache Maven​, ​Gradle​, ​npm​, ​Apache Ant​, or
make​ to define
the specific actions required at each step
■ You define a Jenkins Pipeline to run each activity in the same order every time
○ Pipeline is glue for the activities defined
○ Do NOT code build actions directly in the Pipeline!
■ The Pipeline runs each time the code is modified

SCM TERMINOLOGY: BASICS

● Each set of changed lines on a single file is a ​diff

● A set of diffs that have been explicitly validated forms a ​commit

● A ​commit​ is actually a new version of the codebase

● A commit can exist only locally or only remotely
● The latest commit on the history is the ​HEAD

SCM TERMINOLOGY: BRANCHES

● A ​branch​, in SCM terminology, is a pointer to a single commit

■ HEAD​ is the "latest" branch, also known as the ​master​ branch
 ■ To integrate a branch, you must ​merge​ it:

SCM TERMINOLOGY: PULL REQUEST

● A ​Pull Request​ is a way of proposing a change to others without writing to their repository
■ A branch is pushed to the central server
■ It ​"asks"​ to be merged to the central repository
■ Opportunity is given to review the changes ​before​ merging
■ Pull request ends by being closed or ​merged​ to destination branch

SOFTWARE TESTING

TESTING GOALS
● Validate that the software meets its goals
● Search for defects that can be fixed to improve software quality
● Facilitate refactoring and upgrades by validating that everything is still working after
TEST ACTIVITIES

● Good testing involves many different types of tests:

■ Unit testing, integration testing, smoke testing
■ Functional testing
■ Non-regression testing
■ Acceptance testing
■ Code Quality and Static Analysis
■ Performance and Security Testing
■ Report test results
AUTOMATED TESTING

● Tests can be run frequently

● Tests should be independent from each other as much as possible
● Tests can be run in parallel
● Tests can be run in the same order
● Consume machine resources but little human time except to review
the results of tests that fail
● Running tests frequently means that problems are found early
and you usually know what small piece of code caused the problem
● Define different tests to run at different stages of the build chain

TEST ACTIVITIES

● Good testing involves many different types of tests:

■ Unit testing, integration testing, smoke testing
■ Functional testing
■ Non-regression testing
■ Acceptance testing
■ Code Quality and Static Analysis
■ Performance and Security Testing
■ Report test results

AUTOMATED TESTING

● Tests can be run frequently

● Tests should be independent from each other as much as possible
● Tests can be run in parallel
● Tests can be run in the same order
● Consume machine resources but little human time except to review
the results of tests that fail
● Running tests frequently means that problems are found early
and you usually know what small piece of code caused the problem
● Define different tests to run at different stages of the build chain

TYPES OF TESTING — FASTER

● Unit tests​ — test a small piece of code (a function or method or command)

 ■ Run blazingly fast, and are often written by the person who wrote the code
● Integration tests​ — validate integration between multiple sub-systems
■ Including external sub-systems like a database
● Smoke tests​ — validates basic functions of the system
■ Also known as ​sanity checking

TYPES OF TESTING — SLOWER

● Functional tests​ — validate the normal software behaviors against

the expectations and requirements
● Non-regression tests​ — validates that the system still produces
the same result
● Acceptance tests​ — tests the full product from the perspective of
the end-user use cases and feelings. Probably includes manual testing

MANUAL TESTING

● Is appropriate when test result is subjective, such as user experience testing

● May also be used when the cost of automation is excessive for some reason
● Should be performed rarely, and only on software that has passed all automated tests
TESTING PYRAMID

● Tests at the bottom of the pyramid run quickly and inexpensively and should be run very
frequently
● Tests at the top of the pyramid take more time to run and are expensive; they should be run
less frequently and only on software that has passed the tests lower on the pyramid.
 THE TESTING PORTFOLIO

● Should have more low-level tests than high-level tests

● When low-level tests fail, it seldom makes sense to run higher-level tests
before fixing the problems detected by the low-level tests
● When a higher level test fails, consider that it detected a defect in the
lower-level tests as well as a defect in the code
WHY THIS MATTERS

● Jenkins enables you to run large numbers of tests frequently and at appropriate
stages in the build cycle
■ Unit tests usually run every time you compile the code
■ You can define whether functional and non-regression tests run
if the unit tests fail
■ Large, broad tests can be set up to run periodically, perhaps during
non-work hours, rather than being run each time new code is committed
READ MORE ABOUT SOFTWARE TESTING

● Software testing is a vast subject with many excellent courses, books, and articles available.
Here are a few articles to get you started:
■ The stackoverflow ​What are unit tests, integration tests, smoke tests, and regression
tests?​ discussion introduces the types of testing you can do
■ Wikipedia article about Software Testing​ provides a comprehensive summary and
bibliography about types of testing and tools to use
■ Martin Fowler writes extensively about software development, and proper testing
figures prominently in his writing.
○ To get started, read the articles on his ​tagged by: testing​ page
○ You may also enjoy his articles about ​Unit testing​, ​Test Coverage​, and
Test Driven Development

WHY THIS MATTERS

● Jenkins enables you to run large numbers of tests frequently and at appropriate
stages in the build cycle
■ Unit tests usually run every time you compile the code
■ You can define whether functional and non-regression tests run
if the unit tests fail
■ Large, broad tests can be set up to run periodically, perhaps during
non-work hours, rather than being run each time new code is committed
READ MORE ABOUT SOFTWARE TESTING

● Software testing is a vast subject with many excellent courses, books, and articles available.
Here are a few articles to get you started:
■ The stackoverflow ​What are unit tests, integration tests, smoke tests, and
regression tests?​ discussion introduces the types of testing you can do
■ Wikipedia article about Software Testing​ provides a comprehensive summary
and bibliography about types of testing and tools to use
■ Martin Fowler writes extensively about software development, and proper
testing figures prominently in his writing.
○ To get started, read the articles on his ​tagged by: testing​ page
 ○ You may also enjoy his articles about ​Unit testing​, ​Test
Coverage​, and ​Test Driven Development

TRAINING RESOURCES

● If you really want to delve into the fine points of software testing, Black Box Software
Testing (BBST) by Cem Kaner offers a series of four six-week courses about testing. Each
course contains video lectures and exams:
■ About the Black Box Software Testing Courses
■ BBST Courses Offering at Altom

CONTRIBUTE TO JENKINS

WHY CONTRIBUTE?

● The quality of Jenkins improves as more people contribute

● People at all levels of skills and knowledge can make valuable contributions
● It’s a great way to learn more about Jenkins
● The Jenkins community includes lots of nice people
● Many of us find it fun and satisfying to contribute

WHAT CAN I CONTRIBUTE?

● Lots of ways to contribute

■ Provide feedback
■ Join a mailing list or a chat channel and answer questions
■ Review and/or test code and documentation changes
■ New code and new documentation is always welcome
■ Contribute to Jenkins Core and plugin localization
■ Et cetera…​

HOW TO START

● Go to the ​jenkins.io​ page

● Click the ​Community​ download and select ​Overview
 FOR FURTHER READING

● jenkins.io home page

● Github repository for the Jenkins project
● Jenkins Project Governance Document
● Participate and contribute in the Jenkins project
● Beginners Guide to Contributing
● The journey of becoming a Jenkins contributor: Introduction​ is a fun blog by our own Romen
Rodriguez-Gil wherein he tells of his experiences as he first became a Jenkins contributor.
● Newbie-friendly Tickets​ is the second installment in Romen Rodriguez-Gil’s blog series,
which steps you through the process of contributing a fix for a known issue.