We often talk about monoliths at the application and database level. However, there are many other manifestations: monolithic tooling, monolithic infrastructure, monolithic releases, monolithic testing, and even monolithic thinking. In my experience, more than legacy technology or architecture, the emergence of monoliths often comes down to a lack of purposeful team design and evolution. Conway’s Law - the mirroring effect between team structures and dependencies and the resulting system design - is no stranger to CI/CD. Once we acknowledge the socio-technical nature of software delivery, we consequently recognize the need for a team-centric, not tool-centric, approach for sustainable CI/CD. We start asking questions like: should every application team own and maintain their own instances and flavors of the CI/CD tooling (since it’s all codifiable now, right)? Or do we need a CI/CD team to handle the tooling and infrastructure for everyone else in the org so teams only have to worry about their own pipelines? Or something in between, like a CI/CD platform providing out-of-the-box solutions that can be customized by application teams to fit their specific needs? Just like we are advancing our tools to become easier to install, run and update, we also need to think about clarifying team interactions and responsibility boundaries for effective ownership and evolution of both the CI/CD system (it’s actually a product) and the application pipelines. Manuel Pais is co-author of Team Topologies: organizing business and technology teams for fast flow. Recognized by TechBeacon as a DevOps thought leader, Manuel is an independent IT organizational consultant and trainer, focused on team interactions, delivery practices and accelerating flow.

1. TeamTopologies.com
@TeamTopologies
Avoiding the CI/CD Monolith
with Team Design & Evolution
Manuel Pais
co-author of Team Topologies
@manupaisable
London CD meetup - 14 July 2020

2. 2
Manuel Pais
Independent IT organizational consultant and trainer
Ex-dev, ex-build manager, ex-tester, ex-QA lead
LinkedIn instructor on Accelerating Continuous Delivery
Twitter: @manupaisable
LinkedIn: manuelpais

3. Team Topologies
3
Organizing business and
technology teams for fast flow
Matthew Skelton & Manuel Pais
IT Revolution Press (2019)
https://teamtopologies.com

4. “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
4

5. “if the architecture of the system and
the architecture of the organization
are at odds, the architecture of the
organization wins”
– Ruth Malan, 2008
5

6. “if your architecture doesn’t
fundamentally support
Continuous Delivery, then
you’re going nowhere”
https://www.youtube.com/watch?v=_wnd-eyPoMo

7. 7

8. 8

9. 9

10. 10

11. 11
facilitates knowledge via
● training, workshops
● tool/framework selection
● pairing on examples
● guidance on good practices
● mentoring, coaching
Enabling Team

12. We need a team-centric
approach for sustainable
CI/CD, not tool-centric
12

13. 13https://info.acloud.guru/resources/brazeal-how-your-org-predicts-your-ci/cd-pipeline

14. Centralized vs decentralized
CI/CD is missing the point
14

15. • Upfront decision on requirements for Continuous Delivery
• “One size fits all” (monolithic thinking)
• Monolithic toolchains (“Jenkinsteins”)
• Overgrown home tools diverge from/don’t support emerging new practices
Centralized CI/CD anti-patterns
15

16. • Poor levels of resilience, maintainability, scalability (“hanging from wires”)
• Large blast radius for tooling issues
• Fragile tool chain integration causes frequent, hard to diagnose failures
• Slow evolution of the tooling and practices (“CD = pipeline”, right?)
Decentralized CI/CD anti-patterns
16

17. We need to clarify and
evolve the CI/CD boundaries
& responsibilities over time
17

18. 18
How to encourage both:
sharing good practices & tech
and
autonomy & ownership

19. 19

20. “Cognitive load is the total amount
of mental effort being used in the
working memory”
- John Sweller
20

21. Intrinsic (skills)
Extraneous (mechanism)
Germane (domain focus)
21

22. (Intrinsic)
] Extraneous [
Germane
22

23. CI/CD as a Platform
23

24. “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
24

25. 25
A platform is an ever evolving
curated experience for
internal customers.

26. Higher Level
Abstractions
26

27. Build &
Unit Tests
Static
Analysis
Accept.
Tests
30 mins 15 mins
Security
Tests
Deploy
27

28. “The objective is to eliminate unfit
release candidates as early in the
process as we can and get feedback
on the root cause of failure to the
team as rapidly as possible.”
– Continuous Delivery, 2010
28

29. Build &
Unit Tests
Static
Analysis
Accept.
Tests
30 mins 15 mins
Security
Tests
Deploy
29

30. 30
Pipeline fail criteria:
1. test fails
2. test coverage decreases
3. code health decreases
4. new vulnerabilities
5. build time > 10m
6. execution time > 1h

31. Build &
Unit Tests
Static
Analysis
Accept.
Tests
30 mins
Security
Tests
Deploy
31
• Overall code health same or better
• No blocking code issues introduced
• Tests pass with growing coverage
• No new vulnerabilities
• Build time <= 10m
• Execution <= 1h

32. Build &
Unit Tests
Static
Analysis
Accept.
Tests
30 mins
Security
Tests
Deploy
32
• Overall code health same or better
• No blocking code issues introduced
• Tests pass with growing coverage
• No new vulnerabilities
• Build time <= 10m
• Execution <= 1h

33. 33
accelerate flow
reduce cognitive load
CI/CD
services

34. Developer Experience
#DevEx
34

35. 35

36. 36
Scale Your DevOps Initiative Beyond its Awkward Teenage Years - ABN AMRO Bank

37. Ops Experience
#operability
37

38. 38

39. Biz Experience
#BizEx ?
39

40. 40https://dzone.com/articles/user-personas-and-pipeline-faccedilades-for-effect

41. 41https://dzone.com/articles/user-personas-and-pipeline-faccedilades-for-effect

42. 42
Product Owner Mobile Developer
Ops Engineer Data API Engineer

43. 43

44. 44

45. 45
strong collaboration with
stream-aligned teams for
any new service or evolution
Platform Behaviors

46. 46

47. 47
provide support and great
documentation for stable
services
Platform Behaviors

48. 48

49. 49
Collaboration
● two teams working together
● defined goal or outcome
● specific time period
● mutual respect is required

50. 50
X-as-a-Service
● one provides, one consumes
● clear service expectations
● emphasize UX / DevEx

51. 51

52. 52
Expect to collaborate with a few
teams to validate use cases and
abstractions for each new service.

53. 53
The hard problem about
platforms are trust and
effective team interactions.
Clarify & grow these first.

54. Team Topologies
54
Organizing business and
technology teams for fast flow
Matthew Skelton & Manuel Pais
IT Revolution Press
Order from Amazon or other retailers:
https://teamtopologies.com/book

55. Workbook
coming soon...
Team Topologies
for Remote Teams
55
for Remote
Teams
Resources: teamtopologies.com/remote-first
Icon by Pixel perfect from www.flaticon.com

56. Remote-
Friendly
Training
🠊 teamtopologies.com/
training
56

57. Resources
57
teamtopologies.com/resources
linkedin.com/learning/devops-foundations-
accelerating-continuous-delivery-in-the-enterprise
dzone.com/articles/
user-personas-and-pipeline-faccedilades-for-effect
slideshare.net/ManuelPais/
treating-your-pipeline-as-a-product-full-day-workshop

58. Thank you!
teamtopologies.com
58
Matthew Skelton, Conflux
@matthewpskelton
Manuel Pais, Independent
@manupaisable
Copyright © Conflux Digital Ltd 2018-2020. All rights reserved.
Registered in England and Wales, number 10890964