True Git: The Great Migration

  • 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”
Oct 2nd, 2013

Putting It All Together - Utilizing Integrations Between Atlassian Products

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
Oct 2nd, 2013

Orbitz - Flying at the Speed of Git

  • 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
Oct 2nd, 2013

Dev Tools State of the Union

  • 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.
Oct 2nd, 2013

Atlassian Summit 2013

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,1 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.2 There isn't one. It's a stellar platform that "just works" for nearly any engineering (and non-engineering) workflow. Heck, NASA uses it.3

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 Migration4
  • Panel: How to Do Agile the Right Way5
  • Putting It All Together: Utilizing Integrations Between Atlassian Products6
  • 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.


  1. Realistically, any event that gets me more junk mail from HDI is something I’m going to avoid like the plague. ↩

  2. For the record, I don’t actually think their software is over-priced. It’s perfectly positioned such that small teams can afford it, and large organizations can afford to make the investment without an incredible amount of deliberation. It’s a lot easier to budget for a few thousand dollars than tens of thousands of dollars. ↩

  3. Quick aside: My first engineer hire was in December 2007, and he still works for me (which is saying something about him as nobody else that I hired for that team still is, but I digress…). Within days of starting, he was trying to sell me on JIRA, but the company had just finished migrating off of FogBugz to DevTrack (huge mistake, by the way), and so that went nowhere. When we looked to replace DevTrack, there was no discussion about alternatives to what another group at Nuance was using (Test Track Pro, arguably also another big mistake), but he kept bringing it up. When we were forced to use Rational Team Concert (an even BIGGER blunder), he brought it up even more. At one point it was a weekly mention in our team meetings. As soon as the split happened, he walked into my office and said “so can we buy JIRA now”. It was incredible for both of us for me to say “actually, probably”. I have not regretted a single day after using it. ↩

  4. I’m becoming obsessed with Git. More on this at some point. ↩

  5. It’s always nice to hear other people’s ideas on how a team can be and do Agile more effectively. Continuous Improvement is the name of the game. ↩

  6. This is one area my team is actively trying to improve, so I’d like to see for what we could be aiming. ↩

Keith Olbermann on Racism and His Dad

Hat Tip: DF

Aug 29th, 2013

Design Axioms

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

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.

Jun 24th, 2013

Set File Date from EXIF Header Date

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.

May 27th, 2013

Fun Fact

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!

Mar 26th, 2013

The Burning Heart | My Utmost For His Highest

Much of the distress we experience as Christians comes not as the result of sin, but because we are ignorant of the laws of our own nature. For instance, the only test we should use to determine whether or not to allow a particular emotion to run its course in our lives is to examine what the final outcome of that emotion will be. Think it through to its logical conclusion, and if the outcome is something that God would condemn, put a stop to it immediately. But if it is an emotion that has been kindled by the Spirit of God and you don’t allow it to have its way in your life, it will cause a reaction on a lower level than God intended.

Mar 22nd, 2013