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.

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 [email protected].