Scribblings and Geekery

Yesterday I spent all day talking about Atlassian software, where my team was struggling, where we were succeeding, and what we wanted to do next. For the most part, the ways in which we are struggling are small and easy to identify:

1. We have infrastructure problems, so linking the applications together is a major challenge as the hosts cannot all see each other.
2. We have no solution for Requirements and Test Case management. The former is currently handled in disparate Word documents, and the latter in disparate Excel spreadsheets. The act of creating a traceability matrix means R&D has to marry up a manually generated spreadsheet of requirement IDs with a list of user stories so that QA can then marry up test cases. It takes person-weeks.
3. We are going to ramp up from a user base of a dozen to a user base of ten dozen in about 5 months.
4. We're using SVN, and many of the nifty Development Workflow innovations coming out of Atlassian now are git-based.¹

There is no Atlassian solution to #1. (Sorry, self.) I spoke with the Product Manager for Development Tools Integrations last night on the bus to the "Summit Bash", and she had no suggestions. I don't blame her for this, of course. I work for a software company also, and we can't magically solve infrastructure problems either.² She, and the Product Manager for Stash, both told me that there was a lot I could still do with linking between the Dev Tools (JIRA, Bamboo, Crucible, etc.) and our SVN repository. No awesome branching, but that's an SVN problem, not an Atlassian problem.

I'm going to need to write up an entirely different post for #2. It's a big challenge for us.

Other customers with whom I spoke had different suggestions for ramp-up training:

• Do this in stages and hold a brief trainging session for each stage.
• Conduct training exactly once and record it.
• Hire one of the many Atlassian Expert consulting partners to hold training.³

I'm not sure what we'll do yet. Consulting-based training is expensive, though less so than I had imagined.⁴ I only employ two Operations Engineers, and this isn't my full-time job (some days, though...), so we'll have to see what the company is willing to spend money on.

Sessions From Day 2

I had intended to hit up four⁵ different sessions yesterday:

True Git: The Great Migration

This presentation was given by Stefan Saasen, a Developer Advocate at Atlassian. The general topic was about how the teams there made the decision to switch from SVN to Git in 2011, and have had incredible benefits as a result. He showed us several good resources for research and several good resources on how to do the conversion itself. It was a nice primer, and answered questions I would have had to ask in subsequent sessions.

So, you know, good programming decision.

Panel: How to Do Agile the Right Way

The panel was so full I got kicked out due to fire code concerns. So I went and did an on-camera interview for Atlassian about how we do Agile, what issues we're having, etc. I got a(nother) free T-Shirt out of the deal, so you know that's cool and all.

Putting It All Together: Utilizing Integrations Between Atlassian Products

This presentation was really less helpful than I was expecting. While it's a big concern for us, I already knew everything that was presented. Once we solve our internal issues, we'll reap some great benefits.

Flying at the Speed of Git

Best presentation of the day. Alex Holtz, from Orbitz, went through their entire migration strategy and execution from a commercial VCS to Git over the course of 11 months. Great anectdotes, great war stories, etc. He showed us the why and the how and explained some of the pitfalls associated with git and how you could (easily) avoid them. They chose an open-source git server called Gitorious, and were just starting their migration when Stash was announced last year. They plan to move to Stash in the future.

Dev Tools State of the Union

Given by two of the Dev Tools Product Managers, it was more of a deep dive into things covered in the keynote about development process and the concept of taking the "work" out of "workflow". Nicely, though, they also talked about being productive with SVN in the meantime, which I really appreciated since, well, my team has to be.

Sessions from Day 3

So today, my plan is to try to get to these:

• Seven Ways to Make Good Teams Great⁶
• I Work in Pajamas: Winning at Remote Distributed Teams
• Git Workflows a la Carte
• Large Scale JIRA Administration
• I might nap from 2-3, as there's really nothing I want to attend at the time.
• Inside JIRA Bug Processes: JIRA Best Practices

Hopefully today is as productive as yesterday was. Hopefully there are no more T-Shirts. My bag is full. I'm going to have to start handing them out to strangers, which might be a good idea anyway.

• In 2011, Atlassian moved their teams from SVN to Git
• SCM (SVN/Git) use by year across atlassian customers (%, actual and surveyed):
  • 2011: 78/20
  • 2013 (projected): 68/41
  • 2013: 70/49
  • 2015 (projected): 55/68
• Why git?
  • Branching
    • Branching is fast, cheap and simple
    • Branching is a first class concept within git
    • Value of good branching/merging is that it is the foundation for new workflows
  • Speed. It’s really really fast.
    • git log on confluence - 2 seconds
    • svn log on confluence - 9 minutes
    • Speed leads to innovation
    • git bisect lets you find a particular commit / range of commits, then presents commits to you and asks “is this good or bad?” until you find what you’re looking for.
    • Fast graph traversal, fast checkout
    • Speed enables entirely new features (e.g. pickaxe to find the history of a specific string)
    • Speed improves basic featues
  • Local commits
    • Create and Share. Choose when to publish.
    • Gives flexibility in workfows… This means there is no “should have”
• Git does what you are doing today, only better
  • SVN has a very narrow way of how you work.
    • You commit to the trunk
    • Branching is often too painuful
  • Git is a superset of what is possible in SVN plus new ways of collaborating, new branching workflows, etc.
• Stash
  • Release branch for every version released to customers.
  • Master is always the next version to be released
  • To fix a bug, they go back to the oldest version on which they want to fix it.
  • They create a pull request, discuss, and merge up.
  • In stash 2.8 they built a feature to do this automatically – trickle merge.
• Paradigm Shift - So you’ve decided to migrate!
  • Inception
    • Is git suitable?
      • One disadvantage is that you are storing an entire repo on your machine. This could be huge!
    • Test the conversion
      • Size
      • How does it feel?
    • Identify the repositories that need to be converted
      • e.g. they only migrated the pieces that needed to be moved
    • Identify the tools that will need to be updated along the way
      • CI
      • Issue tracking
      • IDE
      • Scripts/build tools
      • Deployment tools
      • etc.
    • Create a migration plan
  • Adoption
    • You need to answer: “What’s in it for me?”
    • Make sure tooling is ready and can be used by everyone
    • Identify the git champions - they will be thrilled to help!
    • Don’t expect to win everyone over immediately
    • Teach and Communicate!
  • Conversion
    • Go here: bit.ly/go-dvcs
    • git-svn tool used - this is a git client for svn repositories
      • THIS IS NOT A PRODUCTION TOOL
      • This is for advanced git users
    • Preparation
      • Map SVN users names to git identies (matt = Matt Shelton matt.shelton@nuance.com)
      • Identify the SVN repository layout
    • Conversion process
      • git svn clone –authors-file=<> –trunk=/trunk –tags=/tags –branches=/branches
        • THIS TAKES A LONG TIME. The jira project took 3 days!!
      • After initial clone, you need to git svn fetch to sync changes
      • Ends with you having a full git repository on your local machin
    • Infrastructure first!
      • Minimizes downtime
      • set up a git repos that was read-only from SVN
      • Set up the tooling one by one
      • job to sync the git repository every minute from SVN, so devs are not affected by this
    • Final Cleanup
      • cleanup branches
      • remove unused files
      • create git tags
      • remove commit metadata
      • These are DESTRUCTIVE changes - but remember you can try locally
    • After this, everybody uses git. SVN becomes read-only for legacy / leftover tools
  • Other Tools
    • SubGit - works pretty well for simpler cases, not so much for long/rich history in some projcts
• That’s it... or is it?
  • Collaboration Model?
  • Branching Model?
  • From SVN-like (git cherry-pick) to git branch (git merge)
    • cherry picking loses git’s ability to track changes properly
  • Forks can be very useful!
    • Atlassian has ship-it days, and these can be fairly volatile
    • You can accept changes from outside of the core team
• Conclusion
  • Huge push towards git, and not just among Atlassian’s customers
  • “svn is being threatened by git for the de facto tool in the scm space”

Connecting Applications

• Create Application Links
• JIRA, Confluence, Stash, Bamboo, FishEye
• Hipchat/BitBucket some day, not now
• Not 1:1. You can create links from multiple JIRA to one Confluence, vice versa

Life of a PM at Atlassian

• Product Manager
• Conduit for all decisions
• To some, he’s the person who fights for the user.
• To the CEO, he thinks the PM is the person to whom he handed the keys to the product
• No matter what, they have a lot of stuff in the air. Lots of signal, even more noise.
• On top of that, they’re trying to plan your backlog
• “If a major project is truly innovative, you cannot possibly now its exact cost and its exact schedule at the beginning.”
• One of the most valuable things to Atlassian has been the Agile manifesto, specifically valuing responding to change over following a plan.
• JIRA Dashboard - three tabs - New is a constant
  • Popular tab
  • Consistent gardening
  • Internal Marketing
• How do PMs use this to get their ideas out there?
  • Announcements block
  • re Confluence Answers, he tosses out a humble blog post about the idea
  • post gets 105 likes and 44 comments, mostly very valuable
  • Creates a confluence space for the project
    • Faces of the people involved
    • Links to the JIRA project

Confluence to JIRA and Back

• 1:1 mapping of project to space
• pasting in of JIRA issue links to Confluence become JIRA macros
• communication enablement

Developers at Atlassian

• Wired In! Laser focus.
• Search in JIRA -> Context everywhere
• Focus: Agile backlog

JIRA Meets Stash

• issue key mentioned the issue in his commit
• this becomes a link within stash
• issues in stash are transitionable from stash and it moves along in jira

• Overview
  • The proespect of switching to git does not need to seem like a deep chasm
  • in reality, it’s a bit like skiiing. There are obstacles to avoid, but mostly it’s just FAST (Dave would appreciate this)
  • Migration of 600 repos at Orbitz only took 3 months
• History
  • 2000–2006: CVS
  • 2006–2012: Commercial VCS with great branching, 597 Repos
  • 2012+: Git
  • Not using git is slowing us down!
  • Every time we looked at a new tool, we faced the fact that it would take 100s of hours of work to integrate with the current VCS
  • Missing out on a lot.
• Overcoming Inertia
  • Progressive teams were running git on their own servers
  • Git Champions guding the process from start to finish
  • Internal buzz for git was high (90% of dev team in favor!)
• Where do you start?
  • Github:enterprise -> Github you host
  • Gitorious -> OSS you install yourself, but you can buy support
  • They picked Gitorious, mostly because of strict hardware requirements
  • In the middle of their migration, Stash was announced. (jerks!)
• Importing history
  • Leverage git fast-import for transferring VCS history
  • You can either take only the current branch (this is what the linux kernel did) or use one of the many tools to migrate
• How we switched
  • Champions built new tols and were early adopters
  • Existing VCS -> Release Scripts -> Artifactory
  • Git -> Jenkins -> (Same) Artifactory
• Tools in Orbitz Build Chain
  • Proprietary CLI/Proprietary GUI + Custom Ruby Scripts + Apache/custom rails app
  • CLu, IDEs, SourceTree, More! + Jenkins + Artifactory
• We held training, not on Git, but on Git at Orbitz
  • What the new publishing path would look like
  • What kind of branching mdoel we would use
• Approach
  • Repo-by-Repo basis
  • Tools + Docs = Good Luck!
  • 30 minutes, most of the time, for small projects
  • There was a group out of Sydney whose tool took greater than 24 hours to migrate, across the world
• Proprietary System
  • Over 100Gb in 597 repos
  • Chose to migrate 329. 180 were closed and 88 were deprecated
  • Boiled down to only 20 GB in git!
  • Old system left around for up to 5 years just in case
  • each repo set to r/o after migration
• Timeline
  • Sep 2011 - tool eval
  • Mar 2012 - building tools/testing
  • Jun 2012 - migrations in full sitng, several teams every week
  • aug 2012 - final repos migrated, ols system r/o
  • 11 mos from start to finish
  • Stash was announced in May, right before final migration
    • Decided they wanted it, but as a phase 2.
• Costs
  • 2500 man-hours across the company!!
  • Decreased license costs paid for this in less than a years (damn)
• Immediate benefits
  • 20% faster builds across the board
  • Remote teams finally felt like normal/first-class customers
  • Self-service
• Why do we love git?
  • Distributed - equal performance regardless of locatoin
  • Cheaper, faster, less administrative overhead
  • No more custom integration!!
• What could we have done better
  • NFS and hard links do NOT get along
    • git uses hard links when you create a fork
    • ~400 repositories at 20 GB turned into ~3000 developer forks at 80 GB
  • Stash does 2 things to avoid this problem
    • pull requests between branches
    • uses git alternates to share object space between repos so that there’s no duplication.
      • means there are some other things you have to worry about, but Stash handles them behind the scenes
      • totally FS and OS agnostic
• Hindsight is 20/20
  • Locking and moving repos one at a time was easy
  • Same process for mega repos and some of our tools were tightly coupled to our vcs, which was hard
  • Migrating history was useful for some, but not as a standard process
• In the last year
  • Migrating to Stash because of JIRA
  • Stash Hooks
    • Automated SOX controls
    • Automated deployments
    • 3–4 other teams who have already built stash hooks because they love it so much

• Jens Schumacher, Atlassian, @jensschumacher
• Surveyed current FishEye customers
  • SCM Usage Today
    • 69% SVN
    • 49% Git
  • What are you planning to use in 2 years?
    • 55% SVN
    • 68% Git
• 22,000 JIRA customers!
• Stash
  • Introduced at Summit 2012
  • Git management tool
  • Vision was a lot bigger. They wanted it to become a collaboration platform for developers
  • 11 major releases in the past year. 1 every 5 weeks!
  • 69 Add-ons in the Marketplace
    • e.g. AwesomeGraphs (6,000 customers using this!), SC editor, gamification of commits (e.g. JS Ninja!)
  • a lot of big customers using this
• More productive with Subversion
  • FishEye + Crucible
    • Performance and Usability - how did we do?
  • Performance
    • Looked at increasing performance on the most used pages - huge gains
    • Looked at improving indexing performance - 38x performance
    • FishEye search is 2.2x faster
  • Usability
    • Improve the pre-commit review experience
    • Previously you create a diff and upload this
    • Created a cmd line tool to create a pre-commit review based on your current working copy
      • crucible.py –title “review title goes here” @reviewer
      • crucible.py
        • Review latest set of changes in existing review
    • JIRA Integration. Once FishEye linked to JIRA, everything else is MAGIC
    • Re-vamped the dashboard experience
• Getting Started with Git
  • Justin Stepka, Product Manager for BitBucket/SourceTree, @jstepka
  • Stash - You host
  • BitBucket - Atlassian hosts
  • New great features of BitBucket
    • unlimited private repos
    • tutorials there on how to get started
    • 1mil users as of June 2013!
    • 100k teams
    • BitBucket + JIRA is even better!
    • Branching
      • now integrated, and part of the top-level navigation
      • plus a new branches tab
      • displays any existin pull requests and branch statuses
    • Online Editing!
      • If you dont have permission to push your change, your change gets auto-forked and a pull request is created.
      • “The ability on @bitbucket to edit any file in someone else’s repo and automatically send a pull request makes collaboraiton dead simple.”
    • Notifications now moved to watching scheme like other Atlassian projects
      • @mention other developers
  • SourceTree - GUI on top of git
• Software Devlopment Workflow
  • Back to Jens!
  • Found two things:
    • Complicated Workflows
    • Lack of integration
  • Goal has been to both optimize the development workflow and take the ‘work’ out.
  • Core of this is the pull request / feature branches
    • Branch
    • Code/Review
    • Merge
  • (Same as what they covered in the keynote, which is pretty awesome)
  • Also talk about the reviews happening before merge, which is also great, and all still within source control so there’s none of this pre-commit manual diff crap
  • Merges are so easy in git that in Stash there’s a single button to accept the pull request and merge.
  • In Stash 2.8 you can trickle merge up from far-back bugfix branches. Killer.
    • if a merge fails, you get a pull request to review/address, and it will finish the trickle thereafter!
    • You can also specify special branches, branch prefixes for various categories.
  • Deploy!
    • Build -> Artifacts -> Release -> Deploy to various environments (QA, Staging, Production)
    • For instance, the stash team has a rule that auto-deploys builds from the master which are green to their internal environment. This means it goes down a few times a day, but it keeps them dogfooding.
    • Tasks get executed just like the do in Bamboo. (This is sick, btw…)
    • Can watch the whole thing execute in real-time in Bamboo.
• Other Notes
  • One thing I’m noticing in all of this is that there’s no itegration between Stash/SourceTree and major IDEs. I can’t perform SourceTree operations in Eclpise, though I could with a 3rd party plugin. I suppose, then this is ok. After the branch is created, one need only copy the repository URL and have a developer check that out in said tool, but it’s an extra step. My team is used to Eclipse, and they’re not going to leave it any time soon. It’s far too powerful.

The last time I went to a tech conference, it was 2005 in Atlanta, GA for the annual ResNet Symposium. I loved that group of people. Over three years of attending, I had developed a network of about a half-dozen academic technology peers who faced all of the same challenges I did in that job. We kept up throughout the year, supported each other's presentations at subsequent conferences, and generally enjoyed each other's company when we had the opportunity to connect.

I left the world of academic technology later that year, and as such never had the resaon to attend again, and in my following positions, there had not been any opportunity to meet up with peers in whichever role I had. As a technical support engineer and manager, the available conferences all felt stale and boring,¹ so I never even tried. As an engineering manager who was never a software engieer, I've often felt a bit out of place a technical conferences. I'm super happy to send my engineers to No Fluff Just Stuff any chance I get, or send my UI lead to the Rich Web Experience. They always come back with a slew of ideas, and it's well-worth company dollars to send them. Sending me, though, would not be quite as useful.

This year, though, that got to change. My department within Nuance Healthcare went through a massive re-organization several months ago which separated us from our ancestral department. As a result, we took the opportunity to look for ways to be more efficient in our day-to-day operations that were not necessarily tied to the tools and methodologies of the previous organization. That org had moved all engineering teams to Rational Team Concert about a year beforehand, and while some were finding it useful, my team found that it just got in their way any time that it could. So, I set out to replace this with something else. After (some) deliberation, we pitched moving to the Atlassian tool suite, namely JIRA and GreenHopper Jira Agile.

The Atlassian Suite is really easy to swallow as an investment: It has a huge community, has great name recognition, works well, looks good, is constantly being improved, and has a price tag that makes most corporate entities chuckle and as what the catch is.² There isn't one. It's a stellar platform that "just works" for nearly any engineering (and non-engineering) workflow. Heck, NASA uses it.³

We're working towards rolling out most of the suite to our entire department, which is about 290 people, with an expanded group of "external" users, getting us up into the 400ish range on JIRA and Confluence, with our engineers on Crucible as well. We tie all of these tools together to our Active Directory using the Crowd tool for Single Sign-On. It's smooth, usable, intuitive and functional. So incredibly funtional.

Anyway, back to the point. Atlassian hosts an annual user's conference called the Atlassian Summit, to which I was incredibly fortunate to be allowed to attend this year. I flew in yesterday, registered and wandered around the vendor booths for a bit before the opening reception. Today is when the main event kicks off, but I already feel like I've been exposed to enough to have been worth the price of admission. What I learn today and tomorrow should be enough to convince the company to send more than just me back next year, or so I hope. I'm planning on attending the following sessions today:

• True Git: The Great Migration⁴
• Panel: How to Do Agile the Right Way⁵
• Putting It All Together: Utilizing Integrations Between Atlassian Products⁶
• Dev Tools State of the Union

More to follow, I imagine. As for now, I'm still operating on Eastern Daylight, so I've been awake for almost four hours already and it's not even time for breakfast here. Sigh.

Hat Tip: DF

The Design Axioms describe the minimal rule set for designing interfaces: the 16 foundational concepts that are required knowledge for engineers and designers to create usable and elegant interfaces. The design of the content (and book) will follow the same tenets outlined within it. Diagrams, screenshots, and pictures (the visual story) dominate the content; text-based descriptions are short and to the point...

Our User Experience lead got a set of these from a conference she recently attended, and I fell in love with the cards so much that she got me a set. This one is my favorite because in no uncertain terms, I hate Gantt Charts. They are terrible, horrible, no good and very bad.¹

These guys are very creative. I love that they publish a free iOS app to view the axioms in all their beautiful, phone-sized glory.

I know I'm going to need to remember this some day:

1

exiftool "-filemodifydate<datetimeoriginal" FILE

This sets the modification (and possibly creation, depending on OS/FS versions) dates of a given photo to the EXIF Date/Time header. So, if you have an EXIF header like this (via jhead output):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

File name    : P1060634.JPG
File size    : 5041027 bytes
File date    : 2013:05:26 12:02:35
Camera make  : Panasonic
Camera model : DMC-ZS7
Date/Time    : 2013:05:24 19:56:14
Resolution   : 4000 x 3000
Orientation  : rotate 90
Flash used   : Yes (auto)
Focal length :  4.1mm  (35mm equivalent: 25mm)
Exposure time: 0.033 s  (1/30)
Aperture     : f/3.3
ISO equiv.   : 400
Whitebalance : Auto
Light Source : Flash
Metering Mode: pattern
Exposure     : program (auto)
GPS Latitude : N 42d 53m  6.41s
GPS Longitude: W 77d 14m 26.93s
JPEG Quality : 97

You can use the above command to set the File date to match the date/time that the photo was taken, rather than when it was copied to the computer. This is super helpful when trying to look through photos from multiple cameras in order by date taken. Even better is to sync up all of the EXIF dates to adjust for different camera settings. For the mac, ShootShifter (free) is fantastic for this.

If you have:

1. A WordPress site, using a theme based on the Responsive parent theme
2. The Sermon Manager sermon management plugin
3. A sermon series called "none", for when your pastor preaches a sermon outside of a series

You then get...

An invisible sermon! Phantom sermon! The ghost of sermon present!

See, the default stylesheet for Responsive has this very handy class:

1
2
3

.none {
    display: none;
}

You set a class of none on an element and BAM! It's gone. Very handy.

Unfortunately, the Sermon Manager plugin assigns the sermon series' slug (in this case "none") as a class to its container, except on the archive page, so...

Voila!