The document discusses how Jenkins helps improve the software development process at Yale. It outlines challenges without Jenkins, such as slow and error-prone builds, difficult testing and code coverage, and lack of change control for deployments. With Jenkins, builds are automated and consistent, testing and code coverage are automated, changes are tracked, and deployments are easier. Jenkins supports continuous integration, containerized artifacts, and managed deployments to improve agility, catch bugs early, and standardize environments. The document also discusses how Jenkins supports non-Java languages and future plans.

1. Yale Jenkins
Build and Deploy
E Camden Fisher
camden.fisher@yale.edu
Technical Lead
Unix Infrastructure and Virtualization

2. Who Uses Jenkins @Yale?

3. Overview:
How does Jenkins make life better?
Without Jenkins With Jenkins
● Building is slow, error prone ● "fire and forget", consistent!
● Testing is onerous ● Testing is automated!
● Code coverage is onerous ● Code coverage is automated!
● Bugs caught later ● Bugs caught early and often!
● Devs worry about environments ● Devs worry about code!
● Lack of change control for ● Change control in the right
deployments places for deployments!
● Slow progress ● Rapid progress! Agility!
● Different artifact per environment ● Identical artifact per
● Inconsistent configuration per environment!
environment ● Identical configuration per
● Deployments are "hard" environments!
● Integration Hell ● Deployments are easy! "Click!"
● Integration Nirvana

4. Continuous Integration
Continuous Integration is a software development practice
○ Maintain a Single Source Repository
○ Automate the Build
○ Make Your Build Self-Testing
○ Everyone Commits To the Mainline Every Day
○ Every Commit Should Build the Mainline on an Integration Machine
○ Keep the Build Fast
○ Test in a Clone of the Production Environment
○ Make it Easy for Anyone to Get the Latest Executable
○ Everyone can see what's happening
○ Automate Deployment
Avoid "Integration Hell!!"

5. What is Jenkins?
Jenkins is an application and a framework that
manages and monitors the execution of
repeated tasks.

6. Why Jenkins?
● Easy!
● Extensible
● Scalable
● Flexible
● Open Source
● Supported by Cloudbees

7. History Lesson:
Application lifecycle is a progression
● Source Code Management
● Maven and Artifactory
● Building and Testing with Jenkins
● Container Configurable artifacts
● Managed deployments with Jenkins

8. Source Control Management
● Islands of SCM begat central SCM (subversion)
○ Single source repository!
○ Easy to get access.
○ Easy to onboard.
○ Easy to support.
○ Everyone wins!

9. Maven and Artifactory
● Maven
○ Project Object Model (POM)
○ Simplifies dependency resolution ("oops I forgot that .jar!")
○ Makes the build process easy and uniform
● Artifactory (Maven Repository)
○ Where do I put my built artifacts?
○ Makes it easy for everyone to get the latest build!

10. Builds without Jenkins
● Builds take a long time
● Automated Testing takes longer!
● Code coverage reports take even longer!
● Result: developers don't build, test or report on their code regularly enough
because it's just too time consuming.
● Build environments are not standardized
○ my laptop has a different o/s, jvm, ruby version, gems, libraries, etc
than yours
● Mistakes are caught later, harder to debug

11. Builds with Jenkins
● SCM commits automatically kick off a build
○ Automate the build!
● Testing and code coverage is automated and is run on every commit.
○ Makes the Build Self-Testing!
● Broken builds immediately notify the team and the committer (Email, IRC,
IM, Taskbar, etc)
● Tests run in a Clone of the Production Environment!
● Everyone can easily see what's happening!
● Developers can get back to coding instead of building and testing.
● Releases are quick and easy

13. Container Configurable Artifacts
● Artifacts were built with configuration information embedded inside them.
○ ie. datasources, CAS service endpoints, etc
○ Artifacts are different per environment! What!?
○ "Oops, I forgot to update that parameter!"
● Externalization of configuration parameters
○ deployable XML
○ Apps self configure with JNDI
● Now we have Container Configurable artifacts
○ The SAME artifact migrates between environments
○ XML configuration data is all that differentiates environments
● Vendor-lock-in-less PaaS plug

14. Deployments without Jenkins
● Choice between loss of control or loss of agility
○ Either devs can edit deployables or they can't
○ Often devs can configure the container
● If they can...
○ Code is deployed, edited and removed without Change Control
○ "I'll clean it up later!"
○ Dev environments quickly diverge from Production
○ Security is compromised
■ Elevated privileges on servers
■ Shell management on servers
● If they can't...
○ Change requests are "slow", systems groups must do everything

15. Deployments with Jenkins
● Consistency!
● Jenkins writes configuration XML
● Developers can deploy to DEV at will
● Eliminate shells, and elevated privileges on servers
● Container is managed by infrastructure with the O/S
● Empowers developers to GTD
● Puts gates at appropriate places
● Changes to the Jenkins jobs require change control
● Frees Systems folks to work on more interesting things
● Workflow integration with Kintana

22. Non-Java languages
This all applies to Non-Java projects too!
Php
○ Continuous deployment to DEV for Drupal
○ Code coverage and unit testing available
Ruby
○ Automated unit testing
○ Automated code coverage
○ Automated deployment coming soon
.Net
○ Build, unit test, archive creation

23. The future...
● RBAC + folders
○ delegate responsibility to other systems groups
● More ruby
○ unit testing and code coverage
○ deployments
● Enterprise Service Bus
● Cloud deployments

24. Questions?
E Camden Fisher
Technical Lead
Unix Infrastructure and Virtualization
camden.fisher@yale.edu
@fishnix