More on this book
Community
Kindle Notes & Highlights
Read between
September 1, 2019 - January 11, 2020
Continuous delivery improves both delivery performance and quality, and also helps improve culture and reduce burnout and deployment pain.
We found that high performance is possible with all kinds of systems, provided that systems—and the teams that build and maintain them—are loosely coupled.
We discovered that low performers were more likely to say that the software they were building—or the set of services they had to interact with—was custom software developed by another company (e.g., an outsourcing partner). Low performers were also more likely to be working on mainframe systems. Interestingly, having to integrate against mainframe systems was not significantly correlated with performance.
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.
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
...more
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 virtualization as a way to test services or components in isolation.
The goal of a loosely coupled architecture is to ensure that the available communication bandwidth isn’t overwhelmed by fine-grained decision-making at the implementation level, so we can instead use that bandwidth for discussing higher-level shared goals and how to achieve them.
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
The orthodox view of scaling software development teams states that while adding developers to a team may increase overall productivity, individual developer productivity will in fact decrease due to communication and integration overheads.
This means infosec experts should contribute to the process of designing applications, attend and provide feedback on demonstrations of the software, and ensure that security features are tested as part of the automated test
What we see here is a shift from information security teams doing the security reviews themselves to giving the developers the means to build security in. This reflects two realities: First, it’s much easier to make sure that the people building the software are doing the right thing than inspect nearly completed systems and features to find significant architectural problems and defects that involve a substantial rework. Second, information security teams simply don’t have the capacity to be doing security reviews when deployments are frequent. In many organizations, security and compliance
...more
Rugged DevOps is the combination of DevOps with the Rugged Manifesto.
Toyota’s commitment to relentless improvement enabled the company to build cars faster, cheaper, and with higher quality than the competition.
Lean Software Development
Book
Limiting work in progress (WIP), and using these limits to drive process improvement and increase throughput Creating and maintaining visual displays showing key quality and productivity metrics and the current status of work (including defects), making these visual displays available to both engineers and leaders, and aligning these metrics with operational goals Using data from application performance and infrastructure monitoring tools to make business decisions on a daily basis
Visibility, and the high-quality communication it enables, are key.
We found that external approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate.
Our recommendation based on these results is to use a lightweight change approval process based on peer review, such as pair programming or intrateam code review, combined with a deployment pipeline to detect and reject bad changes. This process can be used for all kinds of changes, including code, infrastructure, and database changes. What
This idea is a form of risk management theater: we check boxes so that when something goes wrong, we can say that at least we followed the process. At best, this process only introduces time delays and handoffs.
Such teams should be monitoring delivery performance and helping teams improve it by implementing practices that are known to increase stability, quality, and speed, such as the continuous delivery and Lean management practices described in this book.
Ries’ work is a synthesis of ideas from the Lean movement, design thinking, and the work of entrepreneur Steve Blank (Blank 2013), which emphasizes the importance of taking an experimental approach to product development.
Working in small batches enables short lead times and faster feedback loops.
of the points of Agile development is to seek input from customers throughout the development process, including early stages.
To be effective, experimentation should be combined with the other capabilities we measure here: working in small batches, making the flow of work through the delivery process visible to everyone, and incorporating customer feedback into the design of products. This ensures that your teams are making well-reasoned, informed choices about the design, development, and delivery of work, and changing it based on feedback.
The fear and anxiety that engineers and technical staff feel when they push code into production can tell us a lot about a team’s software delivery performance.
We found that where code deployments are most painful, you’ll find the poorest software delivery performance, organizational performance, and culture.
How Painful Are Your Deployments?
If you want to know how your team is doing, just ask your team how painful deployments are and what specific things are causing
aware that if deployments have to be performed outside of normal business hours, that’s a sign of architectural p...
This highlight has been truncated due to consecutive passage length restrictions.
“configuration drift”),
Build systems that are designed to be deployed easily into multiple environments, can detect and tolerate failures in their environments, and can have various components of the system updated independently Ensure that the state of production systems can be reproduced (with the exception of production data) in an automated fashion from information in version control Build intelligence into the application and the platform so that the deployment process can be as simple as possible
Fostering a respectful, supportive work environment that emphasizes learning from failures rather than blaming Communicating a strong sense of purpose Investing in employee development Asking employees what is preventing them from achieving their objectives and then fixing those things Giving employees time, space, and resources to experiment and learn
employee loyalty (as measured by employee Net Promoter Score and identity)
