The Pivotal Tracker Rewrite, And Improved Story Linking


If you’re a long time Pivotal Tracker user, you’ve probably noticed that for the last year or so, things have been fairly quiet, in terms of new features. That’s because we spent that time on a complete, but focused rewrite of the core of the Tracker web application, as well building a soon to be public, brand new API.

A year is a long time to hit the pause button, but we think it was a necessary investment given that Tracker has been around for almost eight years, starting as mostly a training project during the early days of Pivotal Labs. And while deceptively simple on the surface, Tracker is actually quite an amazingly complex application under the hood, as we humbly re-discovered over the course of this rewrite.

The Tracker team worked hard to get this done, and we now have a clean, modern codebase, ready for new features, as well as a comprehensive new API that’s about to go into beta. Keep reading for some highlights about the rewrite, as well as the first new feature that we’ve just released!

A Ground Up Rewrite

We completely rewrote the important part of Tracker – the project page, where you spend most of your time.

The rewrite took us from a home grown, OO-based client MVC framework, that used older Prototype and YUI libraries, and many experimental patterns, to a clean and mostly functional, event based client codebase, built on top of Backbone.js and JQuery (that runs exclusively against the new API, of course). We now have almost 40% less JavaScript code (around 18K lines now), with over 2:1 (Jasmine) test to production code ratio. We also reduced the number of project load time requests by 90% by using sprites for all image assets.

This new client and API architecture has made it possible to improve a few things that were quite difficult before. For example, we can now deploy our API and client application independently, with strict versioning and automated integration testing, allowing us to deploy application updates without any disruption (via the new yellow popup messages asking you to reload at your convenience).

Another example is that you no longer lose story changes you might be in the middle of, when someone else moves that story to a different panel, directly or indirectly. Your story simply moves to it’s new place, but stays open and keeps your changes intact.

The new client is mostly identical to the old one (for now), but there is more polish. The charts in the app are now done via HighCharts (and more of them on the way).

Finally, everything that Tracker does is fully supported in the new API, for which beta access begins shortly. Anything that you can do via Tracker’s UI will be available in this new API, including epics and full access to historical project and story activity. It will be JSON based, with cross-domain request capability to allow you to build browser widgets that access Tracker data.

And because Tracker’s own UI runs against this new API, going forward, the API will no longer lag behind new features – support for them in the API will be available immediately.

 

First New Feature – Improved Story Linking

We’re busy working on a number of new features, including a fairly major redesign – which this new codebase and architecture has allowed us to make amazing progress on so far. The first of these improvements – improved story linking, is now available for all projects.

This feature makes it easier to embed story or epic links within story or epic description, tasks, and comments, which can be useful with cross-project story dependencies. For example when you want to indicate that a given story is blocked by another, because the API endpoint that the story depends on is not complete yet.

story link flyovers

Copying and pasting a story or epic URL into the description, task, or comment of another story will show a short form link to that story or epic, with a colored background (blue for stories, purple for epics). Hovering over the link will allow you to see a preview of that linked story, so you can tell whether that story has been accepted yet, for example, without having to load that story’s project.

This works with stories in the same project, as well as with stories from other projects. And clicking on the link will either reveal the story in the current project, or open it in a new tab if it’s from a different project.

Instead of copying and pasting the full story or epic URL, you can also just type # and the story ID (e.g. #123456789), or ## and ID for epics. To get the URL or ID of a story or epic, just click on the “link” or ID button to the left of the ID number, in the expanded story or epic view.

More to come soon! Please let us know what you think of this improved story linking feature, in the comments below or by email to tracker@pivotallabs.com.

 

 

10 Comments

  1. ronp says:

    Sounds like outstanding progress and a leap forward. Looking forward to it! Congratulations to you and the team.

    June 21, 2013 at 12:17 am

  2. Jason Rogers says:

    Have appreciated using Tracker since working at Samasource (a little over a year now). You’re doing a great job. Look forward to access to the new API.

    June 21, 2013 at 3:33 pm

  3. Brendan Loudermilk says:

    Excellent news! Can’t wait to use the more robust API. Congrats, Tracker team.

    June 23, 2013 at 5:44 pm

  4. Shane Hall says:

    This is super handy…but is there a way to override this behavior? We frequently have #’s in comments and descriptions that are not related to stories, ie #000000, and having these auto-linked is not ideal. Would love to be able to escape the # by using ‘# or something else.

    July 1, 2013 at 11:29 am

  5. Dan Podsedly says:

    Shane, we’re making some tweaks to the auto-linking which will at least make it less common of an issue, look for that next week.

    July 3, 2013 at 11:52 am

  6. Chase C says:

    Discovered the linking today and I love it. A couple thoughts:

    1. Will there be a strikethrough (or other visual cue) added for linked stories that are done?
    2. Will there be a way of seeing which stories link to a particular story? I’d like to use it as a dependency graph, i.e., once a story is accepted, say “now I can focus on these other linked stories.”

    July 8, 2013 at 9:58 am

  7. Hunter Gillane says:

    Chase – It doesn’t look like there is a strikethrough but if you expand a story and hover over a story link in the description, a modal appears with the story details. You can see if a story is completed there. I don’t work on Tracker so I don’t know about your second question but my guess is that there is not a way to see the dependencies of the story since referencing another story does not necessarily represent a dependency.

    July 8, 2013 at 2:06 pm

  8. Mike W says:

    With the rewrite, I wonder why it wasn’t considered to move to story IDs that make sense within an account?

    On a new account, new project, the first new story ID should be 1. Not 50487925.

    July 10, 2013 at 8:44 am

  9. Randall Sutton says:

    I would be really interested to hear a few more details about what this statement means, “mostly functional, event based client codebase”. Especially what you mean by “event based”. I know previously you would poll for changes from the server and it would apply those changes to each client. Are you following this same model or are you doing something different and is it related to moving to backbone.js?

    Thanks and I look forward to the update.

    July 25, 2013 at 3:20 pm

  10. Corey says:

    As Shane suggested on July 1, is there a simple way to escape the auto-link to a story? We often reference colors by their hex code (ie #004488) and linking these to random stories could cause confusion.

    November 8, 2013 at 3:14 pm

Add New Comment

Your email address will not be published.