Accu Continuous Integration Best Practises

8/6/2019 Accu Continuous Integration Best Practises

1/31

2/13/2008 Copyright 2007 Viewtier Systems Inc. 1

Continuous IntegrationBenefits, Challenges and Best Practices

ACCU

Silicon Valley Chapter

February 13, 2008

Presented by

Slava Imeshev

Viewtier Systems, Inc.


2/31


Introduction

Slava Imeshev

XP practitioner

President of Viewtier Systems, makers of Parabuild


3/31


Notion Of Software Build

Process of transforming project code base into ausable application

Traces its roots to 1952 when the first compiler wasdevised by Grace Murray Hopper

Also is used as a communication pattern to define:

1. Current state of the code base (build is broken)

2. Actual results of build process (build #650 is inproduction)

3. Build tools and scripts (run build at 2:00am)

Broken build means no product


4/31


Story of a Broken Build

Real-life, unfortunately

A software company:

30 software developers

5 QA engineers

1 release engineer

Source control system and issue tracking in place

Is moving fast towards the release date


5/31


Monday Evening

Richard:

Finishes a critical chunk of work

Runs local build and tests cleanly Submits changes to CVS

Marks the issue closed

Goes home, proud of his work and happy for meeting animportant deadline


6/31


Tuesday Morning, 9:15AM

Sandeep, Jason, Eric, and Chris: cvs update to integrate with the new Richards code.

Run ant all.clean

Expecting to see BUILD SUCCESSFUL

but instead see

[javac] 131. return new Layout(0, 0, 1, 1);[javac] ^----^

[javac] *** Semantic Error: A candidate for type "Layout" was found, but it

[javac] Found 5 semantic errors compiling "D:/bt/src/viewtier/au

[javac] 3. import viewtier.ui.*;[javac] ^---------^[javac] *** Semantic Error: You need to modify your classpath, sourcepath,

BUILD FAILEDfile:D:/bt/build-prod.xml:45: Compile failed; see the compiler errorTotal time: 21 seconds


7/31


8/31


The End

Results

Sandeep, Jason, Eric and Chris couldnt work till 1PM

when Richard arrives and submits the missing lib The release engineer spent 4 hours trying to fix nightlybuild because it failed, too.

Five QA guys couldnt test a new critical feature till 2PM

when new QA build is finally ready Consequences single broken build

Money: 45 man-hours($4,500) went south at one shot

Time: Project time line slipped 5 hours priceless

($100,000 fine for missed contract date) Team spirit: you @#$%$%%!!!


9/31


Spreading Build Breakage


10/31


Broken Code


11/31


Broken Codebase


12/31


Checking Out Broken Codebase


13/31


Work Stopped


14/31


The Problem

1. Broken builds increase risk of project failure:

Schedule slips, one day per broken nightly build

Time and money losses grow linearly with the number

of engineers, double for distributed teams2. Broken builds mean no product

A build transforms project source code to a product

No successful build - no product to ship

3. Broken builds are dangerous

A team can be paralyzed in a matter of minutes bychecking out broken codebase


15/31


The Solution - Continuous Integration

Do frequent check-ins and integrate into the codebase:

Finish working on the feature

Run successful build and test locally

Update from the latest clean state of the codebase Run successful build and test locally again

Check In

Set up integration build:

Is a process of clean rebuilding of project code base upondetecting new changes

Is run by a dedicated build management server

Ensures that new changes integrate well into the existingcodebase

Provides feedback on quality of new changes Helps to deliver timely fixes if the changes break the build

Supposedly introduced by IBM OS/360 software team in early60-s

Integration builds are also known as Continuous Integration


16/31


Everyone Is Notified That The Build Is Broken


17/31


Build Breaker Checks In Fix


18/31


Everyone Is Notified That Codebase Is Clean


19/31


Spreading Of Build Breakage Prevented


20/31


Benefits Of Continuous Integration

Most of the software projects fail because they miss deadlines,cannot stay in budget, or are unable to meet therequirements. Continuous Integration allows to reduce

risk of project failure by: Reducing slipping of schedule caused by significant time

losses

Reducing and oftentimes eliminating loss of productivity

caused by code base breakage

Increasing team morale and helping to maintain capableengineers on board

Reducing development time and hitting the market beforecompetitors


21/31


Hitting The Market Before Competitors

High quality software gets developed faster than usualbecause the major cause of slipping schedule, missed budgetand loss of key people are eliminated.

We have seen triple reduction of project delivery time.

Many our customers hide the fact that they use our productbecause it gives them unfair advantage over

competition.


22/31


Reducing Significant Time Losses

One day schedule delay for broken nightly build

Single build breakage went into a codeline undetected costs

about one hour of time losses per a member ofengineering team; may double or triple for distributed oroffshore team.

Quick feedback on quality of new changes prevents

spreading build breakage by giving build breakers a chanceto deliver timely fixes.

For a team of ten, Continuous Integrations saves 80 hoursper months minimum that are lost otherwise


23/31


Reducing Loss Of Productivity

Undetected build breakage is often a subject of dominoeffect once codeline is broken, QA, PM, OPS and otherorganizations run idle.

Continuous Integration helps stay in budget, saves $8,000per months for a team of 10;

This saving doubles when advanced servers like Parabuild

are used.


24/31


Increasing Team Morale

There is nothing worse than checking out latest and greatestcode from VCS and finding that it doesnt compile. For mostit just turns the thought flow off.

When (and if) found, build breakers are hated. Constantly broken codebase creates a deserved sense of

doom.

Continuous Integration eliminates all of this becausebuild breakage is getting fixed immediately after detected,and may even be unnoticed by the rest of the team.

A happy team loves developing great code uninterrupted and

enjoys sense of smooth process as compared to a doomedsweat-shop. Their resumes are collecting dust.


25/31


Addressing Challenges

Introducing Continuous Integration to organization, withall benefits it brings, may face some challenges. Hereare the ways to address some them:

1. Release Engineering AKA Mr. Nightly Build resists RE has to become an owner of the infrastructure

Show that this is a relief, not a burden (lesser chances ofbroken nightly builds or even practically unbreakablebuilds with Parabuild)

Get her production-grade tools

2. Builds are still constantly broken

Show management the benefits (reduced risk of failure)

Educate your team to respond to breakage immediately

See, I have broken the build, fixed it right away and noone even noticed!

Follow best practices


26/31


Best Practices For Avoiding Broken Builds

Infrastructure

Get a production-grade software build management system. A buildserver that need CPR every hour is no good.

Dedicate the fastest hardware money can buy for the build sever. Fast

hardware produces quicker response about quality of changes. Make sure your product can be build from the command line. It should

be able to build in an unattended, batch mode.

Build scripts and dependencies should be under version control. Everyoneshould be able to reproduce build breakage any time.

People

Remember -you dont break the build only if you dont do anything.It OK to break a build from time to time. It is NOT OK to leave it broken.

Always claim build breakage. People will appreciate knowing that the

build is being taken care about, and will do same for you. Avoid build breakage patterns: Five Oclock Checkin, Spoiled Fruit and

Small Change. This alone will reduce build breakage by 50%!

Establish fun, non-insulting ritual for hailing build breakers. Buyingdonuts to the team works well!


27/31


Parabuild Server

Continuous Integration and Software Release ManagementSystem

Developed By Viewtier Systems

For software companies who suffer from code base breakage

To help them reduce risk of failure of software projects By offering them feedback on changes and providing practically

unbreakable scheduled builds.

Key benefits

Reduces risk of failure of software projects Continuous Integration

Killer feature

Practically unbreakable scheduled builds


28/31


Build Breakage Distribution


29/31


Time To Fix


30/31


Q & A

Q & A

Continuous Integration


31/31


Continuous IntegrationBenefits, Challenges and Best Practices

Thank You

Visit Us At

www.viewtier.com

Slava Imeshev

Viewtier Systems, Inc.

[email protected]

Documents

Accu Continuous Integration Best Practises