Chapter 3 Reducing Risks Using CI

Chapter 3
Reducing Risks Using CI
Catherine Leclercq Ruiz
Jherson Martelo Medina

Quality means doing it right when no one is looking.
—Henry Ford
In this chapter, we cover risks that CI can mitigate,
such as late discovery of defects, lack of project
visibility, low-quality software, and the inability to
create deployable software.

CI helps you identify and mitigate risks when they
occur, making it easier to evaluate and report on the
health of the project based on concrete evidence

How much of the software have we implemented?
Answer: Check the latest build
How much test coverage do we have?
Who checked in the latest code?

Using CI, you can build a
“quality safety net” and
deliver software faster. When
you press the “Integrate
button” at every change, you
build a foundation for
reducing risks early and often

If you can
reduce certain
software risks,
you can improve
software quality.
In describing the
risks in this
chapter, we use
this template:
An introduction and description
of the software risk
A scenario based on our
experiences
A solution to mitigate the risk
using an aspect of CI

CI cannot directly assist with the business challenges
of eliciting requirements from your customer,
understanding the customer’s industry, funding, or
resource management, but by using CI you can
discover problems with the software faster—while
it’s under development

Risks
• Lack of deployable software
• Late discovery of defects
• Lack of project visibility
• Low-quality software

Lack of Deployable Software
• Integration hell
• The lack of automation increased the overhead of running the build.
Because we were not performing the build in a clean environment on a
separate machine, we had no confidence we were building the software
correctly. The effects of all these were threefold:
• Little or no confidence in whether we could even build the software
• Lengthy integration phases before delivering the software internally
(i.e., test team) or externally (i.e., customer), during which time nothing
else got done
• Inability to produce and reproduce testable builds

Scenario: “It Works on My Machine”
• John (Technical Lead): We’re having a problem with the
latest build on the test server.
• Adam (Developer): That’s funny; it was working when I built
it on my machine. Let me see… Yeah, it’s still working.
• John: Oh, I see the problem. You didn’t commit your new
files into the Subversion repository

Solution
• Use a separate machine solely for integrating the software
• Create a CI system
• CruiseControl tools Ant, NAnt, or Rake
• build run through tests
• perform inspections
• deploy the software in the development and test environments

Scenario: Synching with the Database
• Lauren (Developer): I’m having a lot of problems testing on v1.2.1.b1 of the
database using build 1345.
• Pauline (Database Designer): Oh no, with build 1345, you should use v1.2.1.b2,
but I also need to make a few changes to it first.
• Lauren: I just spent four hours for nothing.
• Pauline: Well, you should have checked with me first.

Solution
• Place all database artifacts in your version control
repository
• Rebuild the database and data from your build script
• Test (and inspect) your database

Scenario: The Missing Click
• Rachel (Developer): Is the latest build updated to the development server? Where is John?
• Kelly (Developer): Oh, John is at lunch. He’s supposed to have posted the update to the server.
• Rachel: Well, I’ll just wait for John to get back.
Later, John arrives…
• Rachel: John, what happened with the latest build? It looks like the JSPs weren’t precompiled, so
we’re receiving runtime errors now.
• John (Technical Lead): Oops, sorry about that. I must have forgotten to select that option when I
deployed with the Web tool yesterday.

Solution
• Automate the deployment process by adding it to the Ant build
scripts that use the application server command-line options.

Late Discovery of Defects
The latest changes to the software caused other problems

Scenario: Regression Testing
• Sally (Technical Lead): I noticed that the latest version deployed to
the test environment has the same bug that we had two months ago.
Why is that?
• Kyle (Developer): I’m not sure. I tested all of my latest changes.
• Sally: Did you run all of the other tests for the other parts of the
system?
• Kyle: No, I didn’t have time to manually run through those tests.
That’s probably why I didn’t find the bug before we went to test.

Solution
The following steps demonstrate how you can use the CI system to enable
automated regression testing on your project.
• Write test code for all of your source code (an xUnit frameworkis a good place to
start).
• Run tests from your build script (Ant or NAnt are the most common).
• Run tests continuously as a part of your CI system so that they are executed at
every checkin to the version control repository (using CruiseControl or a similar CI
server).

Scenario: Test Coverage
• Evelyn (Manager): Did you run unit tests before you committed your changes to
the repository?
• Noah (Developer): Yes.
• Evelyn: Great. How’s it going on the other feature you are implementing?
• What didn’t Evelyn ask? Let’s try it again.
• Evelyn: Did you write new tests or update existing tests for your new code?
• Noah: Yes.
• Evelyn: Did all the tests pass? Noah: Yes. Evelyn: How did you determine whether
enough of the code was tested adequately?

Solution
• Run a code coverage tool to assess the amount of source code that is actually
executed by the tests
• Using CI can ensure this test coverage is always up to date.

Lack of project visibility
Scenario: “Did You Get the Memo?”
There are many different scenarios for this risk; here’s just one.
Evelyn (Manager): What are you working on, Noah?
Noah (Tester): I’m waiting for the latest build to be deployed to QA in order to start
testing.
Evelyn: The latest build was deployed to the test server two days ago. Didn’t you
hear?
Noah: No, I’ve been out of the office the past few days.

Solution
• They installed and configured a CruiseControl CI server.
• They added SMS notifications.
• They installed automated agents to check availability of the servers.

Scenario: Inability to Visualize Software
• Maile (Developer): Hi. I’m new to the project and I’d like to review the design. Are
there any UML or other diagrams I can see?
• Allie (Developer): Grr. We don’t do the UML here. All you have to do is read the
code. If you can’t read the code, then maybe you don’t belong here.
• Maile: That’s okay; I was just hoping I could see the big picture and determine the
overall architecture rather than slowly interrogating the code. I’m more of a visual
person.

Solution
• They began generating diagrams of the design using the CI system.
• They ran an automated code documentation tool, Doxygen.
• They also chose to create a simple one -or two- page architecture document.

Low-Quality Software
• Scenario: Coding Standard Adherence
Here is a typical interaction concerning adherence to a coding standard.
Brian (Developer): I’m finding it difficult to read your code. Did you read the 30-page coding
standards document when you started last month?
Lindsay (Developer): I am using the style I used in my previous job. The code I write is kind of
complex so it may be difficult for you to grasp it.
Brian: Writing code that others can’t work with doesn’t make you smarter; it makes you a less
valuable resource. It’s taking me longer to review and update the code. Please review the coding
standards document as soon as you can. First, you can retrofit your existing code, and then get back
to new code using the guidelines.

Solution
• Instead of 30-page standards document, they created one.
• They used automated inspection tools as a part of the build scripts initiated by CruiseControl.
• They used Checkstyle and PMD to report.

Scenario: Architectural Adherence
• Jenn (Architect): Are you guys following the architecture? I found some problems in
one of the controllers in which one of you is calling a component in the data layer
directly.
Mark and Charlie (Developers): (Perplexed expressions)
• Jenn: The reason I created all of those UML diagrams is so that everyone will follow
the established software architecture. You’re not following the established protocol
that has been in place for months.
• Charlie: I looked at those at the beginning of the project, but the architecture has
changed a few times since then and it’s difficult to keep up.

Solution
• Add automated inspection tools to assess adherence to the project's architectural
standards.
• You can use dependency analysis tools such as JDepend6 or NDepend to create
reports for architectural adherence.

Scenario: Duplicate Code
• Mary (Developer): Do you know how I can iterate over a collection of User
objects?.
• Adam (Developer): Yes, I wrote some code for that last week. You can find it in the
User package.
• Mary: Great! I will copy it out of there and use it. Thanks.

Solution
• Analyze the code using a code duplication analyzer such as Simian or PMD’s CPD. Incorporate this
into your build script.
• Reduce the duplicated code by refactoring9 the code into a single method or component that is
called by the classes where it used to appear.
• Run code duplication inspections continuously by incorporating a code duplication inspector into
your CI system. This gives you the capability to determine code duplication over time.

Questions
What risk talk about the problems can cause the latest
changes to the software
Answer: Late Discovery of Defects
What risk contains duplicate code?
Answer: Low-Quality software
What risk contains integration hell?
Answer: Lack of Deployable Software

Chapter 3 Reducing Risks Using CI

More Related Content

What's hot (20)

Similar to Chapter 3 Reducing Risks Using CI (20)

Recently uploaded (20)

Chapter 3 Reducing Risks Using CI

Editor's Notes