Atnaujinkite slapukų nuostatas

Continuous Delivery 2.0: Business-leading DevOps Essentials [Kietas viršelis]

5.00/5 (2 ratings by Goodreads)
  • Formatas: Hardback, 332 pages, aukštis x plotis: 254x178 mm, weight: 793 g, 12 Tables, black and white; 240 Line drawings, black and white; 19 Halftones, black and white; 259 Illustrations, black and white
  • Išleidimo metai: 30-Dec-2021
  • Leidėjas: CRC Press
  • ISBN-10: 0367490471
  • ISBN-13: 9780367490478
Kitos knygos pagal šią temą:
Continuous Delivery 2.0: Business-leading DevOps EssentialsDidesnis paveikslėlis
  • Formatas: Hardback, 332 pages, aukštis x plotis: 254x178 mm, weight: 793 g, 12 Tables, black and white; 240 Line drawings, black and white; 19 Halftones, black and white; 259 Illustrations, black and white
  • Išleidimo metai: 30-Dec-2021
  • Leidėjas: CRC Press
  • ISBN-10: 0367490471
  • ISBN-13: 9780367490478
Kitos knygos pagal šią temą:
Pastovi nuoroda: https://www.kriso.lt/db/9780367490478.html
Raktažodžiai:
The agile transformation is an act of transforming an organizations form or nature gradually to one that can embrace and thrive in a flexible, collaborative, self-organizing, and fast-changing environment. It seems like most of the companies starting an agile transformation never reach the goal of agility, but there are those few that truly become agile and reap incredible benefits by utilizing DevOps as well.

This book introduces the theory and practice of the "double-flywheels model" of Continuous Delivery 2.0: Discovery Loop, which allows information technology (IT) organizations to help businesses figure out the most efficacious ways to develop. Additionally, it explores applications of the Verification Loop that allows IT organizations to deliver value quickly and safely with high quality. Along the way, the book provides an array of insights and case studies that dive into all the aspects of software delivery, and how to implement Continuous Delivery in the most economical way for long-run business development.

Features











Organization culture and software architecture





Business requirement management





Pipeline and tooling





Branching and releasing strategy





Automation strategy





Configuration and artefacts management





Deployment and production healthy

The case studies at the end of the bookscenarios in which the author was personally involvedare explored in depth and meticulously detailed in order to represent typical agile transition scenarios that will benefit all readers.
Foreword xv
Target Readers xvii
Content xix
How to Read This book? xxi
Preface 1 xxiii
Preface 2 xxv
Acknowledgement xxvii
Author's Note xxix
1 Continuous Delivery 2.0
1(14)
1.1 Overview of Software Engineering Development
1(6)
1.1.1 Waterfall Model
1(1)
1.1.2 Agile Method
2(1)
1.1.3 The DevOps Movement
3(1)
1.1.4 Continuous Delivery 1.0
4(3)
1.2 Continuous Delivery 2.0
7(5)
1.2.1 Lean Thinking
7(2)
1.2.2 Double-Flywheels Model
9(1)
1.2.3 Four Core Principles
10(1)
1.2.3.1 Doing less
11(1)
1.2.3.2 Continuous decomposition of problems
11(1)
1.2.3.3 Insistence on fast feedback (FFB)
11(1)
1.2.3.4 Continuous improvement and measurement
11(1)
1.2.4 Tangram of Continuous Delivery
12(1)
1.3 Summary
12(3)
2 Value Discovery Loop
15(22)
2.1 Significance of Discovery Loop
15(1)
2.2 Four Key Steps in Discovery Loop
16(8)
2.2.1 Questioning
17(1)
2.2.2 Targeting
18(2)
2.2.3 Co-creation
20(1)
2.2.3.1 Measurable Impact Mapping
20(2)
2.2.3.2 User Journey Mapping
22(1)
2.2.4 Refining
23(1)
2.3 Working Principles
24(3)
2.3.1 Decomposition and Quick Trial and Error
25(1)
2.3.2 Verify Only One Point at a Time
25(1)
2.3.3 Allow Failure
26(1)
2.4 Common Methods for Co-Creation and Refining
27(5)
2.4.1 Decorative Window
27(2)
2.4.2 Minimum Viable Feature
29(1)
2.4.3 Special Zone
30(1)
2.4.4 Directional Explorer
30(1)
2.4.5 Corn Dolly
31(1)
2.4.6 Minimum Viable Product
32(1)
2.5 Matters Needing Attention
32(3)
2.5.1 Multi-Role Participation
32(1)
2.5.2 A Cyclic Process
32(1)
2.5.3 Risk Is Not Equivalent
33(1)
2.5.4 Be Aware of God's Perspective
33(1)
2.5.5 All Is Number
34(1)
2.5.6 Snake Crawler Effect
34(1)
2.6 Summary
35(2)
3 Fast Verification Loop
37(8)
3.1 Goal of Verification Loop
37(1)
3.2 Four Key Steps in Verification Loop
37(3)
3.2.1 Building
38(1)
3.2.1.1 Timeboxing
38(1)
3.2.1.2 Task decomposition
39(1)
3.2.1.3 Continuous Verification
39(1)
3.2.2 Running
39(1)
3.2.3 Monitoring
40(1)
3.2.4 Decision-Making
40(1)
3.3 Working Principles
40(4)
3.3.1 Building Quality in
40(1)
3.3.2 Eliminating Waiting
41(1)
3.3.2.1 Make value flow through "pull"
41(1)
3.3.2.2 Self-service tasks
42(2)
3.3.3 Automating Routine Work
44(1)
3.3.4 Monitoring Everything
44(1)
3.4 Summary
44(1)
4 A Suitable Organizational Culture for Continuous Delivery 2.0
45(14)
4.1 Security, Mutual Trust, and Continuous Improvement
45(1)
4.1.1 Don't Be Afraid of Failure
45(1)
4.1.2 Mutual Trust
46(1)
4.1.3 Continuous Improvement
46(1)
4.2 Four Steps in Culture Shaping
46(4)
4.2.1 Behavior Determines Culture
47(1)
4.2.2 Google's Engineer Culture
48(1)
4.2.3 Etsy's Continuous Testing Culture
49(1)
4.3 Action Guide
50(5)
4.3.1 Value Orientation
50(1)
4.3.2 Fast Verification
51(1)
4.3.3 Continuous Learning
51(1)
4.3.3.1 Regular retrospective
51(1)
4.3.3.2 Event-replay mechanism
51(4)
4.4 Importance of Measurement
55(2)
4.4.1 Four Attributes of Measurement Indicators
55(1)
4.4.1.1 Leading and lagging indicators
55(1)
4.4.1.2 Observable and actionable indicators
55(1)
4.4.2 The Goal of Measurement Is to Improve
56(1)
4.5 The "Improvement Kata" for Continuous Improvement
57(1)
4.6 Summary
58(1)
5 Software Architecture for Continuous Delivery
59(12)
5.1 Dividing The System into Modules
60(1)
5.1.1 Requirements for a Continuous Delivery Architecture
60(1)
5.1.2 Principles for System Decomposition
60(1)
5.2 Common Architectural Patterns
61(4)
5.2.1 Microcore Architecture
61(1)
5.2.2 Microservice Architecture
62(1)
5.2.3 Monolithic Architecture
63(2)
5.3 Architecture Transformation Patterns
65(5)
5.3.1 Demolisher Pattern
66(1)
5.3.2 Strangler Pattern
67(1)
5.3.3 Decorator Pattern
68(1)
5.3.4 Database Sharding
69(1)
5.4 Summary
70(1)
6 Collaborative Management around Business Requirements
71(22)
6.1 Overview of Software Release Life Cycle
71(3)
6.1.1 Inception Period
71(2)
6.1.2 Delivery Period
73(1)
6.2 Pros and Cons of Requirements Decomposition
74(5)
6.2.1 Benefits of Requirements Decomposition
76(1)
6.2.1.1 Build consensus and coordinate work
76(1)
6.2.1.2 Small-batch delivery to speed up the flow of value
77(1)
6.2.1.3 Embrace change at a low cost
77(1)
6.2.1.4 Multiple integrations and timely feedback on quality
77(1)
6.2.1.5 Boost the morale of team members
78(1)
6.2.2 Costs of Requirements Decomposition
78(1)
6.2.2.1 Explicit cost arising from requirements decomposition
78(1)
6.2.2.2 Iterative cost arising from small-batch development, testing, and deployment
79(1)
6.3 Way of Requirements Decomposition
79(5)
6.3.1 Sources of Requirements
79(1)
6.3.2 Technical Debts Are Another Requirement
80(1)
6.3.3 Roles Involved in Requirements Decomposition
81(1)
6.3.4 The Unequal "INVEST" Principle
81(1)
6.3.5 Five Ways to Split User Stories
82(1)
6.3.5.1 Splitting by path
82(1)
6.3.5.2 Splitting by contact point
83(1)
6.3.5.3 Splitting by data type or format
83(1)
6.3.5.4 Splitting by rule
83(1)
6.3.5.5 Splitting by exploration
84(1)
6.3.6 Seven Components of Each User Story
84(1)
6.4 Requirements Analysis and Management Tools
84(3)
6.4.1 User Story Mapping
85(1)
6.4.2 User Story Tree
85(1)
6.4.3 Dependency Graph
86(1)
6.4.4 Digital Management Platform
86(1)
6.5 Tools for Team Collaboration
87(4)
6.5.1 Shared Calendar
87(1)
6.5.2 Retrospective Meeting
87(2)
6.5.3 Visualized Story Wall
89(1)
6.5.4 Definition of "Done"
90(1)
6.5.5 Continuous Integration
90(1)
6.5.6 Story Verification
90(1)
6.6 Summary
91(2)
7 Principles for Deployment Pipeline and Tool Design
93(22)
7.1 Simple Deployment Pipeline
93(3)
7.1.1 Simple Development Process
93(1)
7.1.2 Initial Deployment Pipeline
94(2)
7.1.3 Execution of the Deployment Pipeline
96(1)
7.2 Design and Use of Deployment Pipeline
96(2)
7.2.1 Principles for Designing a Deployment Pipeline
96(1)
7.2.1.1 Build once, run anywhere
96(1)
7.2.1.2 Loosely coupled with business logic
97(1)
7.2.1.3 Parallelization
97(1)
7.2.1.4 Quick feedback to take precedence
97(1)
7.2.1.5 Important feedback to take precedence
97(1)
7.2.2 Principles for Teamwork
98(1)
7.2.2.1 Stop the line
98(1)
7.2.2.2 Security audit
98(1)
7.3 Composition of A Deployment Pipeline Platform
98(3)
7.3.1 Overall Architecture of the Platform
98(1)
7.3.1.1 True north source
99(1)
7.3.1.2 Deployment pipeline platform
99(1)
7.3.1.3 Infrastructure service layer
100(1)
7.3.2 Basic Capabilities of the Platform
100(1)
7.3.3 Strategy for Tool Chain Construction
101(1)
7.4 Cloudification of Infrastructure Services
101(6)
7.4.1 Interpretation of the Collaboration Process of Infrastructure Services
102(2)
7.4.2 Build System
104(1)
7.4.3 Automation Test System
105(1)
7.4.4 Deployment System
106(1)
7.4.5 Environment Management System
106(1)
7.5 Management of Artifact Repository
107(2)
7.5.1 Classification of Artifact Repository
107(1)
7.5.1.1 Internal artifact repository A (temporary)
108(1)
7.5.1.2 Internal artifact repository B (formal)
108(1)
7.5.1.3 Artifact repository X (external)
108(1)
7.5.1.4 Temporary mirror C, formal mirror D, and external mirror Y
108(1)
7.5.2 Principles for Management of Artifact Repository
108(1)
7.6 A Variety of Deployment Pipelines
109(2)
7.6.1 Multi-Component Deployment Pipeline
109(1)
7.6.2 Individual Deployment Pipeline
109(1)
7.6.3 Evolution of Deployment Pipeline
110(1)
7.7 Build Self-Service Tools for Engineers
111(2)
7.8 Summary
113(2)
8 Branch Strategy Conducive to Integration
115(20)
8.1 Purpose of The Version Control System
115(3)
8.1.1 CVCS
115(1)
8.1.2 DVCS
116(2)
8.1.3 Basic Concepts in VCS
118(1)
8.2 Common Branching Modes
118(8)
8.2.1 Trunk-Based Development and Release
119(1)
8.2.2 Trunk-Based Development & Branch-Based Release
120(2)
8.2.3 Branch-Based Development & Trunk-Based Release
122(2)
8.2.3.1 Feature-based branch
124(2)
8.2.3.2 Team branch
126(1)
8.3 Evolution of Branch Modes
126(2)
8.3.1 Troika
126(1)
8.3.2 Git Flow
127(1)
8.3.3 GitHubFlow
128(1)
8.4 How to Choose a Suitable Branching Strategy?
128(5)
8.4.1 Release Pattern
129(1)
8.4.1.1 Project release pattern
129(1)
8.4.1.2 Release train pattern
129(1)
8.4.1.3 Intercity express pattern
130(2)
8.4.2 Relationship Between Branch Strategy and Release Cycle
132(1)
8.5 Summary
133(2)
9 Continuous Integration
135(18)
9.1 Origin and Definition
135(2)
9.1.1 Original Definition
136(1)
9.1.2 Integration Process
136(1)
9.2 Six-Step Check-In Dance
137(5)
9.2.1 Four Key Points of Check-In Dance
138(1)
9.2.1.1 Effect of the three times of verification
138(1)
9.2.1.2 Twice personal verifications are a necessity
139(1)
9.2.1.3 Ensure the performance of a personal build before code submission
139(1)
9.2.1.4 The contents of quality verification to be included in each build
139(1)
9.2.2 Synchronous and Asynchronous Modes
140(1)
9.2.3 Self-Check Sheet
140(1)
9.2.3.1 Trunk-based Development and frequent submission
141(1)
9.2.3.2 Content of each submission is a complete task
141(1)
9.2.3.3 Finish check-in build within 10 minutes
141(1)
9.2.3.4 After a failed check-in build, do not submit new code or check out the problematic code
141(1)
9.2.3.5 Fix the check-in build or roll back within ten minutes
141(1)
9.2.3.6 Passing the automation build will boost up the confidence in software quality
142(1)
9.3 Trade-off Between Speed and Quality
142(4)
9.3.1 Staging Build
142(1)
9.3.2 Builds Submitted by Multiple People at the Same Time
143(1)
9.3.3 The Power of Cloud Platform
144(2)
9.4 Implement CI Practices in the Team
146(5)
9.4.1 Quickly Establish a CI Practice for the Team
146(1)
9.4.1.1 Scripted build and setup CI tool
147(1)
9.4.1.2 Add an existing automation verification script to the build
147(1)
9.4.1.3 Choose a branch strategy that is conducive to CI
147(1)
9.4.1.4 Adopt the six-step check-in dance
147(1)
9.4.1.5 Continuous optimization
147(1)
9.4.1.6 Engineers change habits and improve skills
148(1)
9.4.2 Branch Strategy and Deployment Pipeline
148(1)
9.4.2.1 Trunk-based Development & Release
148(1)
9.4.2.2 Trunk-based Development & Branch-based Release
149(1)
9.4.2.3 Branch-based Development & Trunk-based Release
149(1)
9.4.2.4 Multi-component integration
150(1)
9.5 Common Problems in Implementation
151(1)
9.5.1 Work Habits of Engineers
151(1)
9.5.2 Code Scanning is Often Ignored
151(1)
9.5.3 Lack of Automation Testcases
152(1)
9.6 Summary
152(1)
10 Automation Test Strategies and Methods
153(22)
10.1 Self-Positioning of Automation Test
153(3)
10.1.1 Advantages of Automation Test
154(1)
10.1.2 Investment Required for Automation Test
155(1)
10.2 Break Through the Dilemma of Traditional Automation Test
156(7)
10.2.1 Characteristics of Traditional Automation Test
156(1)
10.2.2 Layering of Automation Test
157(3)
10.2.3 Different Types of Test Pyramid
160(1)
10.2.3.1 Test Pyramid of Microcore Architecture
161(1)
10.2.3.2 Test Pyramid of Microservice Architecture
161(2)
10.3 Implementation Strategy of Automation Testing
163(5)
10.3.1 Add Starting Points for Automation Testcases
163(1)
10.3.1.1 Write tests for code hotspots
163(1)
10.3.1.2 Write tests side by side with new features
163(1)
10.3.1.3 Expand up and down from the middle layer of the test pyramid
163(1)
10.3.1.4 Quality of automation tests is more important than quantity
164(1)
10.3.2 Increase the Execution Frequency of Automation Testing
164(1)
10.3.2.1 Share automation testcases
164(1)
10.3.2.2 Developers are the first users of automation tests
164(1)
10.3.3 Characteristics of Good Automation Testing
165(1)
10.3.3.1 Testcases must be independent of each other
165(1)
10.3.3.2 The testcases must be stable
165(1)
10.3.3.3 The testcases must run fast
165(1)
10.3.3.4 The testing environments should be unified
165(1)
10.3.4 Share Responsibilities for Maintenance
165(1)
10.3.5 Test Coverage
166(2)
10.4 Key Points of User Acceptance of Automation Tests
168(4)
10.4.1 Build a Layered Framework in the First Place
168(2)
10.4.2 The Total Number of UAT should be as Small as Possible
170(1)
10.4.3 Reserve API for Automation Testcases
170(1)
10.4.4 Prepare for Debugging
171(1)
10.4.5 Prepare Test Data
171(1)
10.5 Other Quality Inspection Methods
172(2)
10.5.1 Diff-Approval Testing
172(1)
10.5.2 Code Style Check and Code Dynamic/Static Analysis
173(1)
10.5.3 Application of Artificial Intelligence (Al) in the Field of Testing
174(1)
10.6 Summary
174(1)
11 Software Configuration Management
175(34)
11.1 Put Everything Under SCM
175(5)
11.1.1 Goals of SCM
175(1)
11.1.2 Scope of SCM
176(1)
11.1.3 Principles of SCM
176(1)
11.1.3.1 Everything has a unique identifier
177(2)
11.1.3.2 Sharing the True North source
179(1)
11.1.3.3 Standardization and automation
180(1)
11.2 Versioning of Software Artifacts
180(4)
11.2.1 Anti-Pattern of Package Management
180(1)
11.2.2 Centralized Package Management Service
181(1)
11.2.3 Meta Information of Packages
182(1)
11.2.3.1 Unique ID
182(1)
11.2.3.2 Source
182(1)
11.2.3.3 Dependency
183(1)
11.3 Management of Package Dependency
184(6)
11.3.1 Explicit Declaration of Dependencies
184(2)
11.3.2 Automatic Management of Dependencies
186(1)
11.3.3 Reduction of Complex Dependencies
186(1)
11.3.3.1 Too many dependencies or over-long chains
187(1)
11.3.3.2 Dependency conflict
188(1)
11.3.3.3 Circular dependency
189(1)
11.4 Management of Environmental Infrastructure Management
190(7)
11.4.1 Four States of Environment Previsioning
190(1)
11.4.1.1 "Wilderness" featured by "human brain + handwork"
191(1)
11.4.1.2 "Normalization" characterized by "document + private script"
191(1)
11.4.1.3 "Standardization" characterized by "paperless off icing"
192(2)
11.4.1.4 "Automatic state" characterized by "controlled automation script"
194(1)
11.4.2 DSL Application
195(1)
11.4.3 Infrastructure as Code
196(1)
11.5 Management of Software Configuration Items
197(4)
11.5.1 Separation of Binary and Configuration
197(1)
11.5.2 Version Management of Configuration
198(1)
11.5.3 Storage of Configuration Items
199(1)
11.5.4 Configuration Drift and Governance
200(1)
11.6 Immutable Infrastructure and Cloud Applications
201(4)
11.6.1 Implement Immutable Infrastructure
201(1)
11.6.1.1 Physical machine mirroring technology and virtual machine mirroring technology
201(2)
11.6.1.2 Docker container technology
203(1)
11.6.2 Cloud Native Application
203(1)
11.6.3 Advantages and Challenges
204(1)
11.7 Data Version Management
205(1)
11.7.1 Changes of Database Structure
205(1)
11.7.2 Data File
206(1)
11.8 Association Between Requirements and Source Code
206(1)
11.9 Summary
207(2)
12 Low-Risk Release
209(18)
12.1 High-Frequency Release is a Trend
209(4)
12.1.1 High-Frequency Release by Dot-Com Companies
209(3)
12.1.2 Coexistence of Benefits and Costs
212(1)
12.2 Ways to Mitigate Release Risk
213(4)
12.2.1 Blue-Green Deployment
213(1)
12.2.2 Rolling Deployment
214(1)
12.2.3 Canary Release
214(2)
12.2.4 Dark Launch
216(1)
12.3 High-Frequency Release Support Technology
217(6)
12.3.1 Feature Toggle
217(2)
12.3.2 Data Migration
219(1)
12.3.2.1 Fields only to be added instead of being deleted
219(1)
12.3.2.2 Data migration
220(2)
12.3.3 Branch by Abstraction
222(1)
12.3.4 Fix-Forward Instead of Rollback
223(1)
12.4 Factors Affecting Release Frequency
223(2)
12.5 Summary
225(2)
13 Monitoring and Decision-Making
227(14)
13.1 Scope of Production Monitoring
227(2)
13.1.1 Monitoring of Backend Services
228(1)
13.1.2 Monitoring of Consumer-Host Software
228(1)
13.2 Data Monitoring System
229(3)
13.2.1 Collection and Processing
229(1)
13.2.2 Standardization
230(1)
13.2.3 Monitoring Data System and Its Ability Measurement
230(2)
13.3 Issue Handling System
232(3)
13.3.1 Alarm Storm and Intelligent Management
233(1)
13.3.2 Problem Solving Is a Learning Process
234(1)
13.4 Test in Production
235(2)
13.4.1 Flattening Trend of Testing Activities
235(1)
13.4.2 Testing in Production
236(1)
13.4.3 Chaos Engineering
237(1)
13.5 Eastward or Westward
237(1)
13.6 Summary
238(3)
14 Large Internet Teams to Become Feature Teams
241(20)
14.1 Case Profile
241(3)
14.1.1 State before Improvement
242(1)
14.1.1.1 Team organization structure
242(1)
14.1.1.2 Development process and rhythm
242(1)
14.1.2 State after Improvement
243(1)
14.1.2.1 Team organization structure
244(1)
14.1.2.2 Workflow and rhythm
244(1)
14.2 Improvement Methodology
244(1)
14.2.1 Guiding Ideology
244(1)
14.2.2 Improvement Steps
244(1)
14.3 The Journey
245(13)
14.3.1 Architecture Decoupling
245(2)
14.3.2 Organization Decoupling
247(2)
14.3.3 R&D Workflow Reengineering
249(1)
14.3.3.1 The purpose and principles of multi-version release
250(1)
14.3.3.2 Hybrid branch of virtual trunk
251(2)
14.3.3.3 Create a unified product library
253(1)
14.3.3.4 Two-level release
254(1)
14.3.3.5 Quality assurance mechanism
255(1)
14.3.3.6 Multipartite collaborative release
256(1)
14.3.3.7 A build cloud for compilation
257(1)
14.3.4 Optimization for Automation Efficiency
257(1)
14.4 Summary
258(3)
15 How Can Small Teams Implement a "Counter Attack"?
261(22)
15.1 Background
261(3)
15.1.1 A "Death March" before Improvement
263(1)
15.1.2 Zero-Defect Delivery after Improvement
263(1)
15.2 Improvement Methodology
264(1)
15.2.1 Guiding Ideology
264(1)
15.2.2 Selection of the Pilot Team
264(1)
15.3 Stage 1: Preparation
265(4)
15.3.1 Feature Introduction and Requirements Decomposition
266(1)
15.3.2 Architecture Design and Requirements Dependency Identification
267(1)
15.3.3 Workload Estimation and Scheduling
267(2)
15.4 Stage 2: Delivery
269(10)
15.4.1 Improve Workflow with Kanban
269(1)
15.4.1.1 Identify bad smells
269(1)
15.4.1.2 Let the value flow
270(1)
15.4.1.3 Standard definition of done in explicit declaration
271(1)
15.4.1.4 Graffiti design, eliminate waste
272(1)
15.4.1.5 Clarify state and care about rapid flow of requirements
273(1)
15.4.1.6 Avoid unnecessary task switching
273(1)
15.4.1.7 No feedback is a "risk"
274(1)
15.4.1.8 Limit the quantity of WIP
275(1)
15.4.2 Bug-Free Delivery
276(1)
15.4.3 Trunk-Based Development and CI
276(1)
15.4.4 Shift-Left Testing
277(1)
15.4.5 Code Review
278(1)
15.4.6 Care More about Process in Addition to Results
279(1)
15.5 Summary
279(4)
16 DevOps Driven by Developers
283(26)
16.1 Background
283(1)
16.2 Original Working Mode
284(1)
16.3 Key Points of Improvement
285(2)
16.3.1 Improvement Methodology
285(1)
16.3.2 Define Goals of Improvement
285(1)
16.3.2.1 Expectations of department director
286(1)
16.3.2.2 Delivery pressure of team manager
286(1)
16.3.2.3 Annoyances of project leaders
286(1)
16.4 Stage 1: Agile 101
287(13)
16.4.1 Make a Trustable Plan
287(1)
16.4.1.1 Requirements decomposition
288(1)
16.4.1.2 Relative estimation
288(1)
16.4.1.3 Initial plan
289(2)
16.4.2 Start the Development Stage
291(1)
16.4.2.1 Selection of iteration interval
291(1)
16.4.2.2 Team collaboration process
292(1)
16.4.3 Constraints on Process Quality
293(1)
16.4.3.1 How to consciously abide by CI discipline?
293(1)
16.4.3.2 How to shorten the build time?
294(1)
16.4.3.3 Developers cannot run automated tests
295(1)
16.4.3.4 Automation testing strategy
295(1)
16.4.3.5 What to do in case of insufficient environments for automation tests?
296(1)
16.4.3.6 How to determine a requirement can be tested?
297(1)
16.4.3.7 How to do performance and stress testing?
297(3)
16.4.4 Summary of Stage One
300(1)
16.5 Stage 2: DevOps Transformation
300(6)
16.5.1 "Conflict" with Ops Engineers
301(1)
16.5.2 Specific Obstacles in High-Frequency Deployment and Release
302(1)
16.5.3 Overall Solution Design
302(1)
16.5.3.1 Adjustment of automation testing strategy
302(1)
16.5.3.2 Convenience of running tests
303(1)
16.5.3.3 Put test code with product code
303(1)
16.5.3.4 SCM optimization
303(1)
16.5.3.5 Package management
304(1)
16.5.3.6 Optimization of deployment and monitoring
305(1)
16.5.4 Team Changes in the DevOps Stage
305(1)
16.6 Summary
306(3)
Appendix A Three Evolutions of Software Engineering 309(14)
Appendix B User Story Estimation by Relative Size 323(6)
Index 329
Qiao Liang is an author, lecturer & consultant who helps organizations understand and use the concepts, principles and practices of Agile, Lean & DevOps to improve business value delivery. He is also the CTO of Minster Consulting Co.,Ltd.