Yale Jenkins Show and Tell


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Yale Jenkins Show and Tell

  1. 1. Yale JenkinsBuild and Deploy E Camden Fisher camden.fisher@yale.edu Technical Lead Unix Infrastructure and Virtualization
  2. 2. Who Uses Jenkins @Yale?
  3. 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. 4. Continuous IntegrationContinuous 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 whats happening ○ Automate DeploymentAvoid "Integration Hell!!"
  5. 5. What is Jenkins?Jenkins is an application and a framework that manages and monitors the execution of repeated tasks.
  6. 6. Why Jenkins?● Easy!● Extensible● Scalable● Flexible● Open Source● Supported by Cloudbees
  7. 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. 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. 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. 10. Builds without Jenkins● Builds take a long time● Automated Testing takes longer!● Code coverage reports take even longer!● Result: developers dont build, test or report on their code regularly enough because its 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. 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 whats happening!● Developers can get back to coding instead of building and testing.● Releases are quick and easy
  12. 12. 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
  13. 13. Deployments without Jenkins● Choice between loss of control or loss of agility ○ Either devs can edit deployables or they cant ○ Often devs can configure the container● If they can... ○ Code is deployed, edited and removed without Change Control ○ "Ill clean it up later!" ○ Dev environments quickly diverge from Production ○ Security is compromised ■ Elevated privileges on servers ■ Shell management on servers● If they cant... ○ Change requests are "slow", systems groups must do everything
  14. 14. 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
  15. 15. Non-Java languagesThis all applies to Non-Java projects too!Php ○ Continuous deployment to DEV for Drupal ○ Code coverage and unit testing availableRuby ○ Automated unit testing ○ Automated code coverage ○ Automated deployment coming soon.Net ○ Build, unit test, archive creation
  16. 16. The future...● RBAC + folders ○ delegate responsibility to other systems groups● More ruby ○ unit testing and code coverage ○ deployments● Enterprise Service Bus● Cloud deployments
  17. 17. Questions? E Camden Fisher Technical Lead Unix Infrastructure and Virtualization camden.fisher@yale.edu @fishnix