More on this book
Community
Kindle Notes & Highlights
Read between
September 5 - September 5, 2021
INFORMATION SECURITY
feedback at every step of the software delivery lifecycle,
design through demos to helping with test automation.
ADOPTING CONTINUOUS DELIVERY
technical practices of continuous delivery have a huge impact on many aspects of an organization.
Continuous delivery improves both delivery performance and quality,
improve culture and reduce burnout and de...
This highlight has been truncated due to consecutive passage length restrictions.
rethinking ev...
This highlight has been truncated due to consecutive passage length restrictions.
The key pattern which connects these feedback loops is known as a deployment pipeline, see https://continuousdelivery.com/implementing/patterns/.
ARCHITECTURE
architecture of your software and the services it depends on can be a significant barrier to increasing both the tempo and stability of the release process and the systems delivered.
applied to mainframe systems, firmware, or to an average big-ball-of-mud enterprise environment
possible with all kinds of systems, provided that systems—and the teams that build and maintain them—are loosely coupled.
TYPES OF SYSTEMS AND DELIVERY PERFORMANCE
the type of system and team performance.
Greenfield: new systems that have not yet been released Systems of engagement (used directly by end users) Systems of record (used to store business-critical information where data consistency and integrity is critical) Custom software developed by another company Custom software developed in-house Packaged, commercial off-the-shelf software
Embedded software that runs on a manufactured hardware device Software with a user-installed component (including mobile apps) Non-mainframe software that runs on servers operated by another company Non-mainframe software that runs on our own servers Mainframe software
custom software developed by another company (e.g., an outsourcing partner).
Low performers were also more likely to be working on mainframe systems.
no significant correlation between system type and delivery performance.
packaged software and “legacy” mainframe systems—
low performers were more likely to be using—or integrating against—custom software developed by another company underlines the importance of bringing this capability in-house.
FOCUS ON DEPLOYABILITY AND TESTABILITY
We can do most of our testing without requiring an integrated environment.1 We can and do deploy or release our application independently of other applications/services it depends on.
It appears that these characteristics of architectural decisions, which we refer to as testability and deployability, are important in creating high performance.
loosely coupled—that is, can be changed and validated independ...
This highlight has been truncated due to consecutive passage length restrictions.
loosely coupled, well-encapsulated architecture drive...
This highlight has been truncated due to consecutive passage length restrictions.
Make large-scale changes to the design of their system without the permission of somebody outside the team Make large-scale changes to the design of their system without depending on other teams to make changes in their systems or creating significant work for other teams Complete their work without communicating and coordinating with people outside their team Deploy and release their product or service on demand, regardless of other services it depends upon
Do most of their testing on demand, without requiring an integrated test environment Perform deployments during normal business hours with negligible downtime
In teams which scored highly on architectural capabilities, little communication is required between delivery teams to get their work done, and the architecture of the system is designed to enable teams to test, deploy, and change their systems without dependencies on other teams. In other words, architecture and teams are loosely coupled. To enable this, we must also ensure delivery teams are cross-functiona...
This highlight has been truncated due to consecutive passage length restrictions.
“inverse Conway Maneuver,
The goal is for your architecture to support the ability of teams to get their work done—from design through to deployment—without
requiring high-bandwidth communication between teams.
Architectural approaches that enable this strategy include the use of bounded contexts and APIs as a way to decouple large domains into smaller, more loosely coupled units, and the use of test doubles and virtualiza...
This highlight has been truncated due to consecutive passage length restrictions.
service-oriented architectures don’t permit testing and deploying services independently of each other,
teams to achieve higher performance.3
between teams, and we don’t mean to suggest teams shouldn’t work together.
A LOOSELY COUPLED ARCHITECTURE ENABLES SCALING
loosely coupled, well-encapsulated architecture with an organizational structure to match, two important things happen. First, we can achieve better delivery performance, increasing both tempo and stability while reducing the burnout and the pain of deployment. Second, we can substantially grow the size of our engineering organization and increase productivity linearly—or better than linearly—as we do so.
number of deploys per day per developer.
while adding developers to a team may increase overall productivity, individual developer productivity will in fact decrease due to communication and integration overheads.
Low performers deploy with decreasing frequency. Medium performers deploy at a constant frequency. High performers deploy at a significantly increasing frequency.
factors that predict high delivery performance—a goal-oriented generative culture, a modular architecture, engineering practices that enable continuous delivery, and effective leadership
ALLOW TEAMS TO CHOOSE THEIR OWN TOOLS
Reducing the complexity of the environment Ensuring the necessary skills are in place to manage the technology throughout its lifecycle
Increasing purchasing power with vendors Ensuring all technologies are correctly licensed
it prevents teams from choosing technologies that will be most suitable for their particular needs, and from experimenting with new approaches and paradigms to solve their problems.
The benefits of a standardized operational platform are discussed at length by Humble
Debugging problems with someone else’s code gets a LOT harder, and is basically impossible unless
there is a universal standard way to run every service in a debuggable sandbox”
