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