Why You Need to Think About Team Design for CI/CD @Jenkins World Lisbon 2019
At Jenkins World 2018, Kohsuke Kawaguchi talked about the need to move away from Jenkinsteins, those single-headed monsters that eat all our food (resources) and steal our peace of mind. Jenkins X, Pipelines as Code, Configuration as Code, Evergreen, and Serverless Jenkins are all important initiatives to achieve modern, fast and reliable software delivery. However… there’s still something we need to talk about and that is team organization for effective continuous integration/continuous delivery. Should every application team own and maintain their own instances and flavors of Jenkins, since it’s all code now? Or do we still need a Jenkins admin team to handle Jenkins for everyone in the department/org so they only have to worry about their own pipelines and nothing else? Or something else, like a CI/CD platform providing out-of-the-box solutions that can be customized by application teams to fit their specific needs? The answer, as you probably guessed, is: it depends! But just like we are advancing our tools to become easier to install, run and update, we also need to think about how to design our teams and responsibilities for transparency and ownership of both the CI/CD system (it’s actually a product) itself and the application pipelines. This talk draws on research and case studies from the book Team Topologies by Matthew Skelton and Manuel Pais (IT Revolution Press, 2019) together with first-hand consulting experience from the authors with organizations around the world. Key takeaways: 1. Moving to fast, distributed, and reliable CI/CD systems is not just a matter of better tooling, but also clearer team design and responsibilities. 2. With “everything as code” for CI/CD, application teams can be empowered to own their CI/CD chains if they wish. But with great power comes great responsibility. We need to consider the teams’ cognitive capacity as well as organization size (which btw might change quickly). 3. By applying four fundamental topologies and three interaction modes from Team Topologies, we can describe different ways to split responsibility for our CI/CD system and decide which one best matches the organization and teams’ needs.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Why You Need to Think About Team Design for CI/CD @Jenkins World Lisbon 2019
Similar to Why You Need to Think About Team Design for CI/CD @Jenkins World Lisbon 2019 (20)
More from Manuel Pais
More from Manuel Pais (14)
Recently uploaded
Recently uploaded (20)
Why You Need to Think About Team Design for CI/CD @Jenkins World Lisbon 2019
- 1. Why You Need to Think About Team Design for CI/CD Manuel Pais @manupaisable
- 2. 2 Standardize vs Accelerate CI/CD as a Platform Growing Capabilities Evolving Team Design
- 3. Team Topologies 4 Organizing business and technology teams for fast flow Matthew Skelton & Manuel Pais IT Revolution Press (2019) https://teamtopologies.com
- 5. 6
- 6. 7
- 8. 9
- 9. 10 How to encourage both: sharing good practices & tech and autonomy & experimentation
- 10. We need a team-centric approach for sustainable CI/CD, not tool-centric 11
- 11. CI/CD as a Platform 12
- 14. 15
- 15. Ideal service model won’t accelerate delivery w/o adequate team behaviors and interactions 16
- 16. 17
- 17. 18
- 18. “A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product.” – Evan Bottcher, 2018 19
- 19. 20
- 20. 21 enable stream-aligned teams to deliver work autonomously with self- service capabilities ... Platform Purpose
- 21. 22 strong collaboration with stream-aligned teams for any new service or evolution Platform Behaviors
- 22. 23
- 23. 24 provide support and great documentation for stable services Platform Behaviors
- 24. 25
- 28. 29
- 33. Build & Unit Tests Static Analysis Accept. Tests 30 mins 15 mins Security Tests Deploy 34
- 34. 35 Pipeline fail criteria: 1. test fails 2. test coverage decreases 3. code health decreases 4. new vulnerabilities 5. build time > 10m 6. cycle time > 1h
- 35. Build & Unit Tests Static Analysis Accept. Tests 30 mins 15 mins Security Tests Deploy 36
- 36. 37 accelerate flow reduce cognitive load CI/CD services
- 38. 39
- 39. 40
- 40. 41 team of experts to help bridge capability gaps (technical or product mgmt) Enabling Purpose
- 41. 42 facilitate knowledge via ● training, workshops ● tool/framework selection ● pairing on examples ● guidance on good practices Enabling Behaviors
- 42. 43 Facilitating ● detect gaps in capabilities ● willingness to teach and learn ● not “doing the work” of team ● interaction may be unfamiliar
- 44. 45
- 46. 47
- 47. “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” – Mel Conway, 1968 48
- 50. 51 FTW: Enabling + Platform Discover good practices, then push to Platform
- 52. 53
- 54. 55
- 56. 2. Establish CI/CD Platform & Enabling Teams 57
- 57. 58
- 58. 59
- 59. 3. Fractal Platform & Focused Enabling 60
- 60. 61
- 61. 62
- 62. CaseStudy 63
- 65. Team Topologies 66 Organizing business and technology teams for fast flow Matthew Skelton & Manuel Pais IT Revolution Press (2019) https://teamtopologies.com
- 66. Thank you! teamtopologies.com 67 Matthew Skelton, Conflux @matthewpskelton Manuel Pais, Independent @manupaisable Copyright © Conflux Digital Ltd 2018-2019. All rights reserved. Registered in England and Wales, number 10890964 Icons made by Freepick from www.flaticon.com - used under license
- 67. Why You Need to Think About Team Design for CI/CD