Continuous Integration Improving Software Quality and Reducing Risk

by Duvall, Paul M.; Matyas, Steve; Glover, Andrew

• ISBN13: 9780321336385
• ISBN10: 0321336380
• Edition: 1st
• Format: Paperback
• Copyright: 2007-06-29
• Publisher: Addison-Wesley Professional

Summary

For any software developer who has spent days in "integration hell," cobbling together myriad software components,Continuous Integration: Improving Software Quality and Reducing Riskillustrates how to transform integration from a necessary evil into an everyday part of the development process. The key, as the authors show, is to integrate regularly and often using continuous integration (CI) practices and techniques. The authors first examine the concept of CI and its practices from the ground up and then move on to explore other effective processes performed by CI systems, such as database integration, testing, inspection, deployment, and feedback. Through more than forty CI-related practices using application examples in different languages, readers learn that CI leads to more rapid software development, produces deployable software at every step in the development lifecycle, and reduces the time between defect introduction and detection, saving time and lowering costs. With successful implementation of CI, developers reduce risks and repetitive manual processes, and teams receive better project visibility. The book covers How to make integration a "non-event" on your software development projects How to reduce the amount of repetitive processes you perform when building your software Practices and techniques for using CI effectively with your teams Reducing the risks of late defect discovery, low-quality software, lack of visibility, and lack of deployable software Assessments of different CI servers and related tools on the market The book's companion Web site, www.integratebutton.com , provides updates and code examples.

Author Biography

Paul M. Duvall is chief technology officer of Stelligent Incorporated

Table of Contents

Foreword	p. xiii
Foreword	p. xv
Preface	p. xix
About the Authors	p. xxxi
About the Contributors	p. xxxiii
A Background on CI: Principles and Practices	p. 1
Getting Started	p. 3
Build Software at Every Change	p. 4
Developer	p. 6
Version Control Repository	p. 7
CI Server	p. 8
Build Script	p. 10
Feedback Mechanism	p. 10
Integration Build Machine	p. 12
Features of CI	p. 12
Source Code Compilation	p. 12
Database Integration	p. 14
Testing	p. 15
Inspection	p. 17
Deployment	p. 18
Documentation and Feedback	p. 20
Summary	p. 20
Questions	p. 20
Introducing Continuous Integration	p. 23
A Day in the Life of CI	p. 25
What Is the Value of CI?	p. 29
Reduce Risks	p. 29
Reduce Repetitive Processes	p. 30
Generate Deployable Software	p. 31
Enable Better Project Visibility	p. 31
Establish Greater Product Confidence	p. 32
What Prevents Teams from Using CI?	p. 32
How Do I Get to "Continuous" Integration?	p. 33
When and How Should a Project Implement CI?	p. 35
The Evolution of Integration	p. 36
How Does CI Complement Other Development Practices?	p. 37
How Long Does CI Take to Set Up?	p. 38
CI and You	p. 39
Commit Code Frequently	p. 39
Don't Commit Broken Code	p. 41
Fix Broken Builds Immediately	p. 41
Write Automated Developer Tests	p. 41
All Tests and Inspections Must Pass	p. 42
Run Private Builds	p. 42
Avoid Getting Broken Code	p. 43
Summary	p. 44
Questions	p. 44
Reducing Risks Using CI	p. 47
Risk: Lack of Deployable Software	p. 49
Scenario: "It Works on My Machine"	p. 50
Scenario: Synching with the Database	p. 50
Scenario: The Missing Click	p. 52
Risk: Late Discovery of Defects	p. 53
Scenario: Regression Testing	p. 53
Scenario: Test Coverage	p. 54
Risk: Lack of Project Visibility	p. 55
Scenario: "Did You Get the Memo?"	p. 56
Scenario: Inability to Visualize Software	p. 56
Risk: Low-Quality Software	p. 57
Scenario: Coding Standard Adherence	p. 58
Scenario: Architectural Adherence	p. 59
Scenario: Duplicate Code	p. 60
Summary	p. 62
Questions	p. 62
Building Software at Every Change	p. 65
Automate Builds	p. 67
Perform Single Command Builds	p. 69
Separate Build Scripts from Your IDE	p. 73
Centralize Software Assets	p. 74
Create a Consistent Directory Structure	p. 75
Fail Builds Fast	p. 76
Build for Any Environment	p. 77
Build Types and Mechanisms	p. 78
Build Types	p. 78
Build Mechanisms	p. 80
Triggering Builds	p. 81
Use a Dedicated Integration Build Machine	p. 81
Use a CI Server	p. 85
Run Manual Integration Builds	p. 86
Run Fast Builds	p. 87
Gather Build Metrics	p. 88
Analyze Build Metrics	p. 89
Choose and Implement Improvements	p. 89
Stage Builds	p. 92
Reevaluate	p. 96
How Will This Work for You?	p. 96
Summary	p. 101
Questions	p. 102
Creating a Full-Featured CI System	p. 105
Continuous Database Integration	p. 107
Automate Database Integration	p. 110
Creating Your Database	p. 112
Manipulating Your Database	p. 115
Creating a Build Database Orchestration Script	p. 116
Use a Local Database Sandbox	p. 117
Use a Version Control Repository to Share Database Assets	p. 119
Continuous Database Integration	p. 121
Give Developers the Capability to Modify the Database	p. 123
The Team Focuses Together on Fixing Broken Builds	p. 124
Make the DBA Part of the Development Team	p. 124
Database Integration and the Integrate Button	p. 125
Testing	p. 125
Inspection	p. 125
Deployment	p. 126
Feedback and Documentation	p. 126
Summary	p. 126
Questions	p. 128
Continuous Testing	p. 129
Automate Unit Tests	p. 132
Automate Component Tests	p. 134
Automate System Tests	p. 136
Automate Functional Tests	p. 137
Categorize Developer Tests	p. 138
Run Faster Tests First	p. 141
Unit Tests	p. 141
Component Tests	p. 141
System Tests	p. 143
Write Tests for Defects	p. 143
Make Component Tests Repeatable	p. 148
Limit Test Cases to One Assert	p. 156
Summary	p. 158
Questions	p. 159
Continuous Inspection	p. 161
What Is the Difference between Inspection and Testing?	p. 164
How Often Should You Run Inspectors?	p. 165
Code Metrics: A History	p. 166
Reduce Code Complexity	p. 167
Perform Design Reviews Continuously	p. 170
Maintain Organizational Standards with Code Audits	p. 173
Reduce Duplicate Code	p. 176
Using PMD-CPD	p. 177
Using Simian	p. 178
Assess Code Coverage	p. 180
Evaluate Code Quality Continuously	p. 182
Coverage Frequency	p. 183
Coverage and Performance	p. 184
Summary	p. 185
Questions	p. 186
Continuous Deployment	p. 189
Release Working Software Any Time, Any Place	p. 191
Label a Repository's Assets	p. 191
Produce a Clean Environment	p. 194
Label Each Build	p. 195
Run All Tests	p. 196
Create Build Feedback Reports	p. 196
Possess Capability to Roll Back Release	p. 199
Summary	p. 199
Questions	p. 200
Continuous Feedback	p. 203
All the Right Stuff	p. 205
The Right Information	p. 205
The Right People	p. 207
The Right Time	p. 208
The Right Way	p. 209
Use Continuous Feedback Mechanisms	p. 209
E-mail	p. 210
SMS (Text Messages)	p. 212
Ambient Orb and X10 Devices	p. 214
Windows Taskbar	p. 217
Sounds	p. 218
Wide-Screen Monitors	p. 220
Summary	p. 222
Questions	p. 222
Epilogue: The Future of CI	p. 223
CI Resources	p. 227
Continuous Integration Web Sites/Articles	p. 227
CI Tools/Product Resources	p. 229
Build Scripting Resources	p. 232
Version Control Resources	p. 233
Database Resources	p. 234
Testing Resources	p. 236
Automated Inspection Resources	p. 239
Deployment Resources	p. 241
Feedback Resources	p. 241
Documentation Resources	p. 243
Evaluating CI Tools	p. 245
Considerations When Evaluating Tools	p. 247
Functionality	p. 248
Compatibility with Your Environment	p. 253
Reliability	p. 254
Longevity	p. 254
Usability	p. 255
Automated Build Tools	p. 255
Build Scheduler Tools	p. 263
Conclusion	p. 272
Bibliography	p. 273
Index	p. 275
Table of Contents provided by Ingram. All Rights Reserved.

Excerpts

Early in my career, I saw a full-page advertisement in a magazine that showed one keyboard key, similar to the Enter key, labeled with the wordIntegrate.The text below the key read, "If only it were this easy." I am not sure who or what this ad was for, but it struck a chord with me. In considering software development, I thought,surelythat would never be achievable because, on my project, we spent several days in "integration hell" attempting to cobble together the myriad software components at the end of most project milestones. But, I liked the concept, so I cut out the ad and hung it on my wall. To me, it represented one of my chief goals in being an efficient software developer: automate repetitive and error-prone processes. Furthermore, it embodied my belief in making software integration a "non-event" Fowler on a project--something that just happens as a matter of course. Continuous Integration (or CI) can help make integration a non-event on your project. What Is This Book About? Consider some of the more typical development processes on a software project: code is compiled, data is defined and manipulated via a database; testing occurs, code is reviewed and ultimately, software is deployed. In addition, teams almost certainly need to communicate with one another regarding the status of the software. Imagine if you could perform these processes at the press of a button. This book demonstrates how to create a virtualintegrate buttonto automate many software development processes. What's more, we describe how this integrate button can be pressed continuously to reduce the risks that prevent you from creating deployable applications, such as the late discovery of defects and low-quality code, to name a few. In creating aContinuous Integrationsystem, many of these processes are automated and they run every time the software under development is changed. What Is Continuous Integration? The process of integrating software is not a new problem. Software integration may not be as much of an issue on a one-person project with few external system dependencies, but as the complexity of a project increases (such as adding one more person) there is a greater need to integrate and ensure that software components work together--earlyand often.Waiting until the end of a project to integrate leads to all sorts of software quality problems, which are both costly, and often lead to project delays. CI addresses these risks more quickly and in smaller increments. In his popular Continuous Integration article, Martin Fowler describes CI as: . . . continuous integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily--leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly." Fowler In my experience, this means that: Each developer runs a private build 1 on his workstation before committing his code to the version control repository to ensure his changes don't break the integration build Developers commit their code to a version control repositoryat leastonce a day Integration builds occur several times a day on a separate build machine 100 percent of tests must pass for every build A product is generated (e.g., .war, assembly, executable, etc.) that can be functionally tested Fixing broken builds is of highest priority Some developers review reports generated by the build such as coding standards and dependency analysis reports to seek areas for improvement We spend much of our time in this book describing