Peer Code Review: In a Nutshell and The Tantric Team: Getting Your Automated Build Groove On

Matt Quail, Atlassian Patrick Coleman, Dash Navigation

Peer Code Review: In a Nutshell

Agenda

  Introduction (Matt) o Code Review, Crucible and Atlassian

  Code Review at Dash (Patrick) o Introduction of Crucible to SW Engineering o Addition of Fisheye for Code Reviews

  Q & A

Introduction

Patrick Coleman

Fisheye & Crucible At Dash Navigation

Tools Used By Dash Prior to Adding Crucible   Source Control – Perforce   Issue Tracking – JIRA   Wiki – Confluence   Repository Viewer – Fisheye   Continuous Build – Pulse   Static Code Analysis – Coverity   Code Coverage - Clover   Code Review – Manual (i.e. no SW Tool)

Objectives for Adding Crucible to Dash   Increase Code Quality

o Catch Defects in the source versus QA filing bugs

o Facilitate non-defect code improvements by engaging more than one SW Engineer on a piece of SW

  Minimize Impact to SW Engineers o Reviews take place when Engineers want o Remote Engineers are not penalized

Step 1 – Crucible Evaluation

  Installed a 30 day evaluation of Crucible   Recruited a handful of Senior Engineers to

use Crucible   Performed real reviews on current projects   Discussed with trial users what they liked/

disliked o  From this feedback we identified points of

confusion that needed documentation on our Wiki o  Found task of creating a pre-commit review to be

too time consuming (i.e. engineers wouldn’t do it)

Step 2 – Prepare for Team Wide Rollout   Created Wiki Page with basic

instructions on how to create and participate in a Crucible Review

  Created a script to simplify the task of creating a diff file for pre-commit reviews

Step 3 – Crucible Rollout

  Announced to Entire SW Team the Addition of Crucible

  Intentionally did not have SW Managers create reviews

  Senior Engineers who participated in evaluation created reviews against their own submissions (this was not planned it just occurred organically)

  Most of the time an engineer was introduced to Crucible as a reviewer rather than having their own code reviewed

Crucible – 12+ Months Later

  Crucible is broadly viewed as an effective way to review both code changes and new code

  Majority of reviews are created by the author   Release Managers selectively create reviews

for changes made near to release points   Marking reviews as complete has never fully

taken hold but does not appear to detract from the value of conducting reviews in Crucible

Review Example

Fisheye - Continuous Code Review via Email Notifications   Hyperlink to Changelist in Fisheye   Hyperlink to Issue in JIRA   Submission Comment   Magnitude of Change   Hyperlink to File by File Diffs   Superior to SCM Notifications for above reasons

Fisheye - Release Management Code Review

  Use Fisheye to approve each code submission into weekly QA Build

Fisheye – Build to Build Reviews

  Use Fisheye to bracket changes from build to build

  Identify likely sources of defects by inspecting code changes

Build Automation: How to do Bamboo

Rik Tamm-Daniels VP, Engineering June 2nd, 2009

©2007Confiden,al&Proprietary.AllRightsReserved.

•  Located in Newton, MA •  Founded August 2007 •  45+ Employees •  What we do: Unified Information Access

About Attivio


•  Attivioʼs Active Intelligence Engine –  Unified Information Access Platform –  Query Unstructured and Structured Information with

the Precision of SQL and the Fuzziness of Search •  Shipped Product (OEM and Direct)

–  Maintenance Release Window at the end of each sprint

–  Minor Release every 3-4 months –  Major Releases Every 12-18 months

What are we building?


•  Automate Everything •  Everything builds off of Bamboo •  Maintain High-Quality

–  8000+ Automated Tests –  Code coverage using Clover –  Static Analysis: Findbugs

•  Source code insight/Build Failure Investigation –  Fisheye

Builds @ Attivio


•  Our Code Base •  100% Java (core product; 95% including add-on

modules) •  Grails •  Flex •  C++ (3rd Party Code + Wrappers)

•  Installer (Install4J) –  Java based installer –  XML configuration + Graphical UI

Key Product Stats


•  Platforms –  Linux –  Windows –  Solaris –  32 and 64-bit

Supported Platforms


•  ANT –  Heavy Use of MacroDefs –  Custom Ant Tasks –  Custom JUnit Wrappers for Testing –  Generalized Model (Maven like Ant Structure) –  Heavy use of AntCall and Ant tasks –  Top – Level directory build-import.xml defines all the tasks

that are used by sub-projects –  Dependency management MacroDef at top level inherited

by sub tasks •  Source Control

–  Subversion

Build System


Attivio Build Directory Structure

A=vio

Common(3rdParty) App Core

Component1

Component2

Modules

Module1 Module2 Module3

Customers

Customer1 Customer2 Customer3

Installer


Component

build

classes dist kit doc clover findbugs checkstyle

src

com

a=vio

test

com

a=vio

Attivio Build Directory Structure (Cont.)


Branching Methodology

Source:Collabnet


•  We use the Unstable Branching Strategy –  Fits with the agile methodology better that the Agile

Branching strategy •  No need to deal with too many branches •  Since our modules are already self contained we are

continually integrating all modules right in trunk •  Less merging more branching •  Ready to release code at any time without merging or

branching –  In large part because of our test coverage –  Having system, integration, smoke and performance testing as

part of our daily activity

Branching Methodology


•  We use Bamboo for Continuous Integration, Nightly Builds and System Test Builds –  Continuous Builds run on each check-in –  Nightly Builds of each Branch are scheduled –  System Test Builds depend upon Nightly Builds

•  All Bamboo Agents run on VMWare Virtual Machines

Bamboo


Linuxx64VM

DefaultAgent

Linuxx64VM

Con,nuousTrunkBuild

FullNightlyBuild

Linuxx64VM

OldVersionCon,nuous

Linuxx64VM

QAInstall/SystemTests

Linuxx86VM

FullNightlyBuild

Windowsx86VM

CodeCheck

FullNightlyBuild

Windowsx64VM

FullNightlyBuild

Solarisx64VM

FullNightlyBuild

Build Agent Configuration BuildAgent

BuildType


•  Trunk Continuous – check-in triggered •  Trunk Nightly Full (Windows, Linux, Solaris) •  Code Check – Clover, Findbugs, Corbertura,

FlexCover •  System Test •  QA –Product Installer is run on isolated VMs •  Supported Version Continuous •  Support Version Full •  Move Head Tag – ensures consistent SVN version

for all nightly builds

Build Plans


•  Nightly builds are scheduled •  Version Consistency

–  An SVN tag is built using a “Move to Head Tag” Plan –  OS Specific builds are kicked off on the tag –  Code coverage Plan is kicked off on the tag –  System Test Plan kicked off on the tag

•  Artifacts –  Short-circuit default behavior –  Send to NFS mount via symbolic link

Nightly Builds


•  Run separately from other builds to reduce build times

•  Produces Code Coverage Artifacts –  Clover –  Cobertura –  Findbugs

•  We donʼt use Bambooʼs integrated Clover Report because it doesnʼt ft our build directory structure (each module built separately)

Code Coverage Build


•  Runs system tests –  Installs our product to one or more nodes –  Runs functional and/or performance tests –  Tests produce JUnit-like output

System Test Build


•  QA picks up the latest successful build artifacts –  Post Build plug-in called to tag successful,

unsuccessful and unsuccessful builds that just had test failures.

•  QA runs multiple Plans testing customer specific, system, performance and scalability tests from Bamboo

•  All QA tests are written using a custom JUnit framework

QA Builds


•  Java Docs automatically generated via ANT task and written to the Confluence Wiki

•  Hotfixes are posted on and linked from Confluence to the Artifact Repository

Post-Build Automation


•  Why do we do Bamboo? –  Quality, quality, quality –  Time-to-market –  Release Flexibility

Takeaways


Questions?

Date post:	17-Jan-2015
Category:	Technology
Upload:	atlassian
View:	1,164 times
Download:	1 times

Peer Code Review: In a Nutshell and The Tantric Team: Getting Your Automated Build Groove On

Technology