Post on 17-Jan-2015
description
transcript
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
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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?
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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
©2007Confiden,al&Proprietary.AllRightsReserved.
• Platforms – Linux – Windows – Solaris – 32 and 64-bit
Supported Platforms
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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
©2007Confiden,al&Proprietary.AllRightsReserved.
Attivio Build Directory Structure
A=vio
Common(3rdParty) App Core
Component1
Component2
Modules
Module1 Module2 Module3
Customers
Customer1 Customer2 Customer3
Installer
©2007Confiden,al&Proprietary.AllRightsReserved.
Component
build
classes dist kit doc clover findbugs checkstyle
src
com
a=vio
test
com
a=vio
Attivio Build Directory Structure (Cont.)
©2007Confiden,al&Proprietary.AllRightsReserved.
Branching Methodology
Source:Collabnet
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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
©2007Confiden,al&Proprietary.AllRightsReserved.
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
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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
©2007Confiden,al&Proprietary.AllRightsReserved.
• 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
©2007Confiden,al&Proprietary.AllRightsReserved.
• Why do we do Bamboo? – Quality, quality, quality – Time-to-market – Release Flexibility
Takeaways
©2007Confiden,al&Proprietary.AllRightsReserved.
Questions?