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

1. Peer Code Review:
In a Nutshell
Matt Quail, Atlassian
Patrick Coleman, Dash Navigation

2. 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

3. Introduction

4. Fisheye & Crucible
At Dash Navigation
Patrick Coleman

5. 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)

6. 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

7. 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)

8. 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

9. 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

10. 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

11. Review Example

12. 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

13. Fisheye - Release Management Code
Review
Use Fisheye to approve each code
submission into weekly QA Build

14. Fisheye – Build to Build Reviews
Use Fisheye to bracket changes from build to
build
Identify likely sources of defects by inspecting
code changes

15. Build Automation: How to do Bamboo
Rik Tamm-Daniels
VP, Engineering
June 2nd, 2009

16. About Attivio
• Located in Newton, MA
• Founded August 2007
• 45+ Employees
• What we do: Unified Information Access
© 2007 Confiden,al & Proprietary. All Rights Reserved.

17. 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.

18. 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.

19. 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.

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

21. 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.

22. 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.

23. 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.

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

25. 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.

26. 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.

27. 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.

28. 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.

30. 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.

33. 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.

35. 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.

37. 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.

39. 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.

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

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