Peer Code Review: In a Nutshell and The Tantric Team: Getting Your Automated Build Groove On
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 2,340 views

Peer Code Review: In a Nutshell...

Peer Code Review: In a Nutshell

Development is inherently collaborative. So why aren't you doing code review? This session discusses the importance of collaboration around your source code, the impact code review can have on development teams, and offers guidance on how to get started.

Atlassian Speaker: Matt Quail

Customer Speaker: Patrick Coleman of Dash
Key Takeaways:

* Peer code review explained
* Benefits and approaches to effective code review

The Tantric Team: Getting Your Automated Build Groove On

Want to take your build automation to the next level? This session explains the process of setting up an automated software development infrastructure using the Atlassian tools, focusing on continuous integration. This session outlines key steps involved in automating a typical Java project using Ant, Bamboo, FishEye, Clover, JIRA and a large cast of other supporting tools.

Customer Speaker: Rik Tamm-Daniels

Key Takeaways:

* Continuous integration how-to
* Integrating multiple Atlassian tools, along with other development infrastructure

Statistics

Views

Total Views
2,340
Views on SlideShare
2,329
Embed Views
11

Actions

Likes
1
Downloads
49
Comments
0

3 Embeds 11

http://www.slideshare.net 7
file:// 3
http://192.168.15.219:8090 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • Peer Code Review: In a Nutshell Matt Quail, Atlassian Patrick Coleman, Dash Navigation
    • 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
    • Fisheye & Crucible At Dash Navigation Patrick Coleman
    • 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
    • About Attivio •  Located in Newton, MA •  Founded August 2007 •  45+ Employees •  What we do: Unified Information Access ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • What are we building? •  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 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Builds @ Attivio •  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 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Key Product Stats •  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 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Supported Platforms •  Platforms –  Linux –  Windows –  Solaris –  32 and 64-bit ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Build System •  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 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Attivio Build Directory Structure A=vio
 Common
 App
 Core
 Modules
 Customers
 Installer
 (3rd
Party)
 Component
 Component
 Module
1
 Module
2
 Module3
 Customer
1
 Customer
2
 Customer
3
 1
 2
 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Attivio Build Directory Structure (Cont.) Component
 build
 src
 test
 classes
 dist
 kit
 doc
 clover
 findbugs
 checkstyle
 com
 com
 a=vio
 a=vio
 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Branching Methodology Source:
Collabnet
 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Branching Methodology •  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 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Bamboo •  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 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Build Agent Configuration Build
Agent
 Linux
x64
 VM
 Build
Type
 Default
 Agent
 Linux
x64
 Linux
x64
 Linux
x64
 Linux
x86
 Windows
 Windows
 Solaris
x64
 VM
 VM
 VM
 VM
 x86
VM
 x64
VM
 VM
 Con,nuous
 Old
Version
 QA
Install/ Full
Nightly
 Full
Nightly
 Full
Nightly
 Code
Check
 Trunk
Build
 Con,nuous
 System
Tests
 Build
 Build
 Build
 Full
Nightly
 Full
Nightly
 Build
 Build
 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Build Plans •  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 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Nightly Builds •  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 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Code Coverage Build •  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) ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • System Test Build •  Runs system tests –  Installs our product to one or more nodes –  Runs functional and/or performance tests –  Tests produce JUnit-like output ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • QA Builds •  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 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Post-Build Automation •  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 ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Takeaways •  Why do we do Bamboo? –  Quality, quality, quality –  Time-to-market –  Release Flexibility ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.

    • Questions? ©
2007
Confiden,al
&
Proprietary.
All
Rights
Reserved.