Jenkins 2.0 Evolutionary Improvements
•Download as PPTX, PDF•
8 likes•2,553 views
The document discusses Jenkins 2.0 and outlines goals to position Jenkins as a continuous delivery platform. It proposes three pillars for Jenkins 2.0: updated messaging and website to focus on continuous delivery, an improved out-of-the-box experience centered around workflow and pipeline functionality, and targeted internal changes like library upgrades and deprecated API removal. Potential pitfalls are also identified around scope, disruption, backwards compatibility and massive internal changes.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Jenkins 2.0 Evolutionary Improvements
Similar to Jenkins 2.0 Evolutionary Improvements (20)
More from Kohsuke Kawaguchi
More from Kohsuke Kawaguchi (19)
Recently uploaded
Recently uploaded (20)
Jenkins 2.0 Evolutionary Improvements
- 1. ©2015CloudBees,Inc.AllRightsReserved 1 ©2015CloudBees,Inc.AllRightsReserved Workflow, Containers, & Beyond Kohsuke Kawaguchi Creator of Jenkins @kohsukekawa
- 2. ©2015CloudBees,Inc.AllRightsReserved 2 © 2015 CloudBees, Inc. All Rights Reserved 2
- 7. ©2015CloudBees,Inc.AllRightsReserved 7 node(“linux”) { git ‘https://github.com/foo/bar.git’ sh “mvn install” parallel( { sh “./regression-test.sh” }, { sh “./performance-test.sh” } ) … }
- 8. ©2015CloudBees,Inc.AllRightsReserved 8 Key Features • Pipeline as Code • Parallel, other interesting control flow • Allocate slave nodes and workspaces –As many as you like, whenever and wherever • Standard project concepts –SCM, artifacts, test reports, …
- 12. ©2015CloudBees,Inc.AllRightsReserved 12 node(“linux”) { git ‘https://github.com/foo/bar.git’ sh “mvn install” parallel( { sh “./regression-test.sh” }, { sh “./performance-test.sh” } ) … }
- 15. ©2015CloudBees,Inc.AllRightsReserved 15 vars/acme_service.groovy def call(name) { node(“linux”) { git “https://github.com/foo/${name}.git” sh “mvn install” parallel( { sh “./regression-test.sh” }, { sh “./performance-test.sh” } ) … } }
- 16. ©2015CloudBees,Inc.AllRightsReserved 16 Use Cases • I have lots of repos that are built, tested, & deployed the same way (e.g., micro-services) • I want to maintain centralized control of the build process • My product developers aren’t Jenkins experts
- 17. ©2015CloudBees,Inc.AllRightsReserved 17 Using Workflow is as easy as 1, 2, 3 1. Create “Jenkinsfile” in repo 2. Create job in Jenkins 3. Specify SCM URL
- 18. ©2015CloudBees,Inc.AllRightsReserved 18 To keep it simple …
- 20. ©2015CloudBees,Inc.AllRightsReserved 20 © 2015 CloudBees, Inc. All Rights Reserved 20
- 29. ©2015CloudBees,Inc.AllRightsReserved 29 Too many image problems • Image names change all the time • ‘latest’ changes what it points to • Image gets transformed all the time
- 34. ©2015CloudBees,Inc.AllRightsReserved 35 © 2015 CloudBees, Inc. All Rights Reserved 35
- 41. ©2015CloudBees,Inc.AllRightsReserved 42 Jenkins needs to adjust to this change • Our pitch on website hasn’t changed • We still bundle CVS & Subversion plugins • Lots of new stuff being done, but requires hand-assembly
- 43. ©2015CloudBees,Inc.AllRightsReserved 44 Goals • Claim Continuous Delivery space –We have lots of pieces, but we are not communicating any of them very well • Revisit out-of-the-box experience of Jenkins –Things people use everyday has been stale • Keep the ecosystem that makes Jenkins great 2.0 sends a clear signal that we are moving forward
- 44. ©2015CloudBees,Inc.AllRightsReserved 45 Aspirational Timeline • Announce intention publicly (now) • Discuss and nail the details of 2.0 (Sep-Oct) • Execution (Oct-Dec) –Periodic alpha/beta releases & feedbacks –PR activities –RC • Work on plugin “2.0 readiness” (Jan) –Ensure key plugins are compatible • Release (end-Jan) • Drop 1.x development
- 51. ©2015CloudBees,Inc.AllRightsReserved 52 Pitfalls to avoid Focusing too much on internals
- 52. ©2015CloudBees,Inc.AllRightsReserved 53 That means … • Jenkins 2.0 needs to be limited-scope “evolutionary improvements” exercise • Not “let’s start from scratch” kind of 2.0
- 53. ©2015CloudBees,Inc.AllRightsReserved 54 Three Pillars 1. Messaging changes 2. Out of the box experience that caters to CD needs 3. Targeted internal plumbing changes
- 54. ©2015CloudBees,Inc.AllRightsReserved 55 Messaging •jenkins-ci.org → jenkins.cd •More up-to-date feature list page •Authoritative & curated getting started guide •Easier-to-contribute blog •Room for future growth –Better plugin directory
- 55. ©2015CloudBees,Inc.AllRightsReserved 56 Messaging Infra •Infra that enables –Drupal → static site generation –Confluence retirement (?)
- 56. ©2015CloudBees,Inc.AllRightsReserved 57 OOTB Experience •Initial setup wizard –Recommend initial set of plugins •UX refresh
- 57. ©2015CloudBees,Inc.AllRightsReserved 58 OOTB Experience for CD •Deliver modern functionalities, OOTB –Workflow –Pipeline as Code –Folders •CloudBees is open-sourcing workflow stage view
- 58. ©2015CloudBees,Inc.AllRightsReserved 59 Internals • Policy for removing deprecated APIs • Brand-new frontend development method • Selected library upgrades –Limited to “should be compatible” kinds • Java 8 & Servlet 3.0
- 60. ©2015CloudBees,Inc.AllRightsReserved 61 © 2015 CloudBees, Inc. All Rights Reserved 61
- 62. ©2015CloudBees,Inc.AllRightsReserved 63 Integration/consumption of containers ircbot: 51 jira: 7 wiki: 13
Editor's Notes
- assembly a complex CD workflow today is like a LEGO model assembly
- Workflow does this in one job
- and in text / not just calling other jobs, but do stuff within itself
- Tolerate loss of master & slaves
- and in text / not just calling other jobs, but do stuff within itself
- and in text / not just calling other jobs, but do stuff within itself
- As an architect of the CD pipeline, you can define them as code in one place. Then product teams get to reuse them
- Docker is driving changes in software development, and Jenkins is no exception. I want to discuss the continuous delivery in the world of containers
- Let’s start with the simplest use case, containerizing app / how hard can it be? / Even simple things like this can be made simpler / Credentials management
- Common credential across all the docker plugins
- Your container building often depends on another container.
- trigger plugin is also useful / ex. JIRA + LDAP
- If a test pass, what do you do? You want to publish images to another repository / tag.
- You’ve got stuff coming in, test it, reject it, test it, accept it / the same problem with these guys /
- Not a new problem, the same with files / but Docker is worse
- We need our own tracking tags
- Tags get scanned everywhere / find where it is / And what we released so far is just a starter. We are going to expand it
- for example, know what went into that container / important view point because it lets you focus on how things are flowing through the system
- I did first handful of plugins myself
- We know how to assemble LEGO / our pain points are often different.
- Need to have enough to justify 2.0 but not everything for everyone / direction setting
- We know how to assemble LEGO / our pain points are often different.
- We know how to assemble LEGO / our pain points are often different.
- We know how to assemble LEGO / our pain points are often different.
- We know how to assemble LEGO / our pain points are often different.
- We know how to assemble LEGO / our pain points are often different.
- References to images get baked somewhere / these ideally live in a VCS / trigger activities in Jenkins
- And then you start putting things together / the whole thing starts to look eerily similar. Artifacts are different, languages are different, but they all follow the same paradigm.