Continuous Integration Improving Software Quality and Reducing Risk

by ; ;
  • ISBN13:


  • ISBN10:


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

Note: Supplemental materials are not guaranteed with Rental or Used book purchases.

Purchase Benefits

  • Free Shipping On Orders Over $35!
    Your order must be $35 or more to qualify for free economy shipping. Bulk sales, PO's, Marketplace items, eBooks and apparel do not qualify for this offer.
  • Get Rewarded for Ordering Your Textbooks! Enroll Now
  • We Buy This Book Back!
    In-Store Credit: $4.79
    Check/Direct Deposit: $4.56
    PayPal: $4.56
List Price: $59.99 Save up to $15.00
  • Rent Book $44.99
    Add to Cart Free Shipping

    *This item is part of an exclusive publisher rental program and requires an additional convenience fee. This fee will be reflected in the shopping cart.

Supplemental Materials

What is included with this book?


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, , provides updates and code examples.

Author Biography

Paul M. Duvall is chief technology officer of Stelligent Incorporated

Table of Contents

Forewordp. xiii
Forewordp. xv
Prefacep. xix
About the Authorsp. xxxi
About the Contributorsp. xxxiii
A Background on CI: Principles and Practicesp. 1
Getting Startedp. 3
Build Software at Every Changep. 4
Developerp. 6
Version Control Repositoryp. 7
CI Serverp. 8
Build Scriptp. 10
Feedback Mechanismp. 10
Integration Build Machinep. 12
Features of CIp. 12
Source Code Compilationp. 12
Database Integrationp. 14
Testingp. 15
Inspectionp. 17
Deploymentp. 18
Documentation and Feedbackp. 20
Summaryp. 20
Questionsp. 20
Introducing Continuous Integrationp. 23
A Day in the Life of CIp. 25
What Is the Value of CI?p. 29
Reduce Risksp. 29
Reduce Repetitive Processesp. 30
Generate Deployable Softwarep. 31
Enable Better Project Visibilityp. 31
Establish Greater Product Confidencep. 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 Integrationp. 36
How Does CI Complement Other Development Practices?p. 37
How Long Does CI Take to Set Up?p. 38
CI and Youp. 39
Commit Code Frequentlyp. 39
Don't Commit Broken Codep. 41
Fix Broken Builds Immediatelyp. 41
Write Automated Developer Testsp. 41
All Tests and Inspections Must Passp. 42
Run Private Buildsp. 42
Avoid Getting Broken Codep. 43
Summaryp. 44
Questionsp. 44
Reducing Risks Using CIp. 47
Risk: Lack of Deployable Softwarep. 49
Scenario: "It Works on My Machine"p. 50
Scenario: Synching with the Databasep. 50
Scenario: The Missing Clickp. 52
Risk: Late Discovery of Defectsp. 53
Scenario: Regression Testingp. 53
Scenario: Test Coveragep. 54
Risk: Lack of Project Visibilityp. 55
Scenario: "Did You Get the Memo?"p. 56
Scenario: Inability to Visualize Softwarep. 56
Risk: Low-Quality Softwarep. 57
Scenario: Coding Standard Adherencep. 58
Scenario: Architectural Adherencep. 59
Scenario: Duplicate Codep. 60
Summaryp. 62
Questionsp. 62
Building Software at Every Changep. 65
Automate Buildsp. 67
Perform Single Command Buildsp. 69
Separate Build Scripts from Your IDEp. 73
Centralize Software Assetsp. 74
Create a Consistent Directory Structurep. 75
Fail Builds Fastp. 76
Build for Any Environmentp. 77
Build Types and Mechanismsp. 78
Build Typesp. 78
Build Mechanismsp. 80
Triggering Buildsp. 81
Use a Dedicated Integration Build Machinep. 81
Use a CI Serverp. 85
Run Manual Integration Buildsp. 86
Run Fast Buildsp. 87
Gather Build Metricsp. 88
Analyze Build Metricsp. 89
Choose and Implement Improvementsp. 89
Stage Buildsp. 92
Reevaluatep. 96
How Will This Work for You?p. 96
Summaryp. 101
Questionsp. 102
Creating a Full-Featured CI Systemp. 105
Continuous Database Integrationp. 107
Automate Database Integrationp. 110
Creating Your Databasep. 112
Manipulating Your Databasep. 115
Creating a Build Database Orchestration Scriptp. 116
Use a Local Database Sandboxp. 117
Use a Version Control Repository to Share Database Assetsp. 119
Continuous Database Integrationp. 121
Give Developers the Capability to Modify the Databasep. 123
The Team Focuses Together on Fixing Broken Buildsp. 124
Make the DBA Part of the Development Teamp. 124
Database Integration and the Integrate Buttonp. 125
Testingp. 125
Inspectionp. 125
Deploymentp. 126
Feedback and Documentationp. 126
Summaryp. 126
Questionsp. 128
Continuous Testingp. 129
Automate Unit Testsp. 132
Automate Component Testsp. 134
Automate System Testsp. 136
Automate Functional Testsp. 137
Categorize Developer Testsp. 138
Run Faster Tests Firstp. 141
Unit Testsp. 141
Component Testsp. 141
System Testsp. 143
Write Tests for Defectsp. 143
Make Component Tests Repeatablep. 148
Limit Test Cases to One Assertp. 156
Summaryp. 158
Questionsp. 159
Continuous Inspectionp. 161
What Is the Difference between Inspection and Testing?p. 164
How Often Should You Run Inspectors?p. 165
Code Metrics: A Historyp. 166
Reduce Code Complexityp. 167
Perform Design Reviews Continuouslyp. 170
Maintain Organizational Standards with Code Auditsp. 173
Reduce Duplicate Codep. 176
Using PMD-CPDp. 177
Using Simianp. 178
Assess Code Coveragep. 180
Evaluate Code Quality Continuouslyp. 182
Coverage Frequencyp. 183
Coverage and Performancep. 184
Summaryp. 185
Questionsp. 186
Continuous Deploymentp. 189
Release Working Software Any Time, Any Placep. 191
Label a Repository's Assetsp. 191
Produce a Clean Environmentp. 194
Label Each Buildp. 195
Run All Testsp. 196
Create Build Feedback Reportsp. 196
Possess Capability to Roll Back Releasep. 199
Summaryp. 199
Questionsp. 200
Continuous Feedbackp. 203
All the Right Stuffp. 205
The Right Informationp. 205
The Right Peoplep. 207
The Right Timep. 208
The Right Wayp. 209
Use Continuous Feedback Mechanismsp. 209
E-mailp. 210
SMS (Text Messages)p. 212
Ambient Orb and X10 Devicesp. 214
Windows Taskbarp. 217
Soundsp. 218
Wide-Screen Monitorsp. 220
Summaryp. 222
Questionsp. 222
Epilogue: The Future of CIp. 223
CI Resourcesp. 227
Continuous Integration Web Sites/Articlesp. 227
CI Tools/Product Resourcesp. 229
Build Scripting Resourcesp. 232
Version Control Resourcesp. 233
Database Resourcesp. 234
Testing Resourcesp. 236
Automated Inspection Resourcesp. 239
Deployment Resourcesp. 241
Feedback Resourcesp. 241
Documentation Resourcesp. 243
Evaluating CI Toolsp. 245
Considerations When Evaluating Toolsp. 247
Functionalityp. 248
Compatibility with Your Environmentp. 253
Reliabilityp. 254
Longevityp. 254
Usabilityp. 255
Automated Build Toolsp. 255
Build Scheduler Toolsp. 263
Conclusionp. 272
Bibliographyp. 273
Indexp. 275
Table of Contents provided by Ingram. All Rights Reserved.


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

Rewards Program

Write a Review