If you use Pivotal Tracker for open source projects, and would like to increase visibility into what your team is working on, you can now do so by making your Tracker project public.
As a project owner, you can enable public access for your project on the Project Settings page, by selecting the Public Access checkbox. The public URL to the project is to the right of the checkbox, in the format http://www.pivotaltracker.com/projects/xxx, where xxx is the id of the project. You can also append a dash to that URL, with a more descriptive name of your project, for example http://www.pivotaltracker.com/projects/xxx-My-Cool-Project.
Anyone you give the project URL to will be able view stories in your project, without having to sign in to Tracker. They'll also be able request project membership by clicking the "Join This Project" button.
We've rolled out some new features in Pivotal Tracker.
New API Version
There's a new version of the developer API, with the following changes:
- support for ActiveResource
- responses no longer wrapped in an element, using HTTP return codes instead to indicate success or error
- ability to get a list of your projects
- you can now page through stories with a limit and offset
- it's now possible to obtain an authentication token by specifying a username and password (via basic auth or header parameters). This makes it easier to build interactive clients, for example a mobile app.
The previous API version (v1) is still supported, but will be deprecated at some point in the future. Please see the API Help page for more details.
Ability to change point scale
It's now possible to change your project's point scale, even if you've already estimated stories.
Demo Projects
New Tracker users will now see a link on the Dashboard to create a demo project, with example stories. You can also create a demo project from the My Projects page.
Story Comment Notifications
There's now an option (on the My Profile page to receive new comment email notifications for all stories in you project(s), not just stories you're a requester/owner of.
As always, we look forward to your feedback!
Michael Buffington has posted the first of a what will hopefully be a series of tours on Pivotal Tracker, this one about how Michael uses Tracker as a personal GTD-style task manager.
http://blog.grockit.com/2009/01/14/how-i-use-pivotal-tracker-for-gtd/
If you haven't heard of GTD, it stands for "Getting Things Done", a work-life "action management" method and book by David Allen. Read more about it here.
A lot of us here at Pivotal Labs have been using Pivotal Tracker as a personal productivity tool, and we're definitely getting more things done!
Thanks, Michael, we're looking forward to more tours.
By popular demand, we're working on making the Pivotal Tracker API ActiveResource-compliant.
However, there are some quirks that are required to make ActiveResource happy. For example, when you are doing a 'create' or 'update' request, ActiveResource wants the response location to point to the 'show' URL for the new or updated record. For example, here's an ActiveResource 'create' call:
new_story = Story.create(
:name => "New Story",
:requested_by => "Dan",
:description => "Make API ActiveResource compliant")
On the controller, you must add the :location option to the render - you can't redirect:
render :xml => xml,
:location => service_project_story_url(service_id, project_id, @story),
:status => status
...otherwise, you get this helpful error from ActiveResource:
/Library/Ruby/Gems/1.8/gems/activeresource-2.2.2/lib/active_resource/base.rb:1006
:in `id_from_response': undefined method `[]' for nil:NilClass (NoMethodError)
from /Library/Ruby/Gems/1.8/gems/activeresource-2.2.2/lib/active_resource/base.rb:993:in `create'
This is the type of error which you will only catch through end-to-end testing with a real ActiveResource client hitting the running app. When I did the initial spike to see what problems we would run into, I wrote a simple manual script to run against the local development environment, hacking my way to a point which didn't blow up and I could visually inspect the output:
#!/usr/bin/env ruby
require 'rubygems'
require 'activeresource'
require 'pp'
class Story < ActiveResource::Base
self.site = "http://localhost:3000/services/v1/projects/1"
headers['TOKEN'] = '6cfc2055d1df5605241759014b06b232'
end
p "========================== Stories#create ====================================="
new_story = Story.create(:name => "New Story", :requested_by => "Dan", :description => "Make API ActiveResource compliant")
pp new_story
# etc for all other supported API actions...
However, now that we are doing the real non-spike implementation, we want to automate this end-to-end integration testing as part of our Continuous Integration. That way, we'll ensure that we are fully ActiveResource-compliant (against current and future versions), and that we don't have any inadvertent regressions due to future API bugfixes/enhancements.
Digging through the internets and rubyonrails-talk list archives turns up some discussion, but no good answers:
- Thoughtbot blog post on ActiveResource and Testing
- rubyonrails-talk post on "Testing XML over HTTP in a Rails app"
- rubyonrails-talk post on "Testing ActiveResource models with HttpMock"
All of these mention using ActiveResource::HttpMock. However, as Eric and Xavier point out, there seem to be drawbacks to this approach. Plus, even if we get it to work, I'm worried the usage of HttpMock might mask some other issues related to authentication handling, or who knows what else. That's what real integration tests are for. Finally, HttpMock is an undocumented internal method that seems to exist in order to support Rails' test suite, so it's probably not a great idea to depend on that long term.
So, we don't have a great answer yet, but it seems clear that the highest-value, least-risk approach is to hit a real running app over HTTP with a real ActiveResource client.
The current plan is to leverage our existing Selenium RC test environment, which already has support for spinning up and managing a Rails server with the test environment. We can then port the manual spike tests above to automated ones which run as part of the selenium suite under Continuous Integration, and add appropriate assertions. This isn't optimal, though, because they won't actually use Selenium RC at all, which may confuse people. However, there's no sense reinventing the wheel (and adding time to the overall CI build) by spinning up a separate test server instance when we already spin one up for our selenium suite.
Let us know if you have any clever solutions.
-- Chad
We released the first version of the Pivotal Tracker API a couple of months ago, and already there is a growing list of useful 3rd party tools out there:
Pivotal Tracker for Ruby
This is a ruby wrapper for the API, written by our friends at Mobile Commons.
http://mcommons.com/developers/pivotal-tracker-for-ruby
Email Integration
Also from Mobile Commons, this tool allows your to automatically create Tracker stories from inbound emails.
http://mcommons.com/developers/pivotal-tracker-email-integration
GitHub Post Receive Hook
This is web service that you run on your own server, written by Chris Bailey. It automatically updates stories in your project(s) based on GitHub commit comments:
http://codeintensity.blogspot.com/2008/12/github-post-receive-hook-for-pivotal.html
Pickler
Synchronize stories in Pivotal Tracker with Cucumber features. If you haven't heard of it yet, Cucumber is a really cool app that can execute plain-text documents as automated functional tests.
http://www.github.com/tpope/pickler/tree/master
More Tools
There are more, most of them live in GitHub:
http://www.github.com/search?q=pivotal+tracker
If you have written something you'd like to share, or know of other useful tools, let us know! Also, we're planning on making the API better, and would love your feedback.
Great article comparing Pivotal Tracker to Mingle, as an example of a tool that simplifies things, rather than trying to manage complexity (and getting in the way):
Agile Tool Vendors: Please don’t try to manage complexity - simplify my life!
Thanks for the positive feedback, Matthias!
Nivi, from Venture Hacks, wrote a great article about why Pivotal Tracker is great for startups. It's worth reading even if you're already a fan of Tracker, and nails down the key ingredients to successful project management. Check it out:
We've released the first version of the Tracker API. It's a RESTful HTTP XML interface, uses a simple, token-based authentication mechanism, and allows you to query as well as update stories in your projects.
To get started with the API, read through the API Help page (it includes examples), and create a token on your Profile page.
We plan to enhance the API and add support for more operations and formats (including JSON) based on your feedback. Please let us know what you'd like to see added, either by email or via Satisfaction.
We've decided to share Tracker with the agile community. Details of the launch have yet to be worked out, including an exact date, but please register here if you're interested in participating in the beta.
Stay tuned for more details!