In this tutorial, we’ll go over how we use Tickets, Revisions, and Releases here at Shotgun to manage our own software development process. We’ll first go through some out-of-the-box functionality, and then show you how we’ve customized our own Shotgun around our current workflow.
First, you will need to enable the entities Tickets, Revisions, and Releases. You can also optionally enable the Tool entity. Enabling Tool is useful if you’d like to organize various projects by Tool or Application, such as “Shot submit tool”, “Hair Pipeline”, etc. For those of you who use scrum, you can use a custom entity for sprints. Enable one of the custom entities, and rename it “Sprint”.
You will need a project to contain all your Releases, Tickets, and Revisions (and Tools, Sprints, etc.). You can create a project per Software project, or make a single project for all your development projects. A few of our clients have a “R&D” Project that they use to track all development.
Now let’s create a Ticket page and put it inside our “Shotgun” project. If you decide to organize your work into multiple projects, create a Tickets page per project.
Tickets come with some basic default fields:
- Assigned To
Let’s take a look at a populated Ticket page to get a better feel for how we use each of these fields:
The Related Tickets, Releases, and Revisions fields are “multi-entity”, meaning a Ticket can have many Related Tickets, be related to multiple Releases, and include many Revisions.
Click on a Ticket and look at its detail page to see all these fields in context of a bug ticket:
The Ticket detail page has a configurable header and side panel, and a threaded reply section where you can turn events on or off. Above we see the first event, where Nephi Sanchez created the ticket.
One feature of Tickets is that if you type prefix a Ticket reference with a “#” anywhere in the description or a reply, Shotgun will automatically create an entry for that ticket in the “Related Tickets” field. The text will convert itself into a link to the ticket it references, show its current status, and reciprocally create a link in the referenced Ticket’s “Related Tickets” field to the current ticket:
Similar to auto-linking related Tickets, adding a lowercase “r” in front of a Revision will automatically convert that text to a link, and create an entry in the “Revisions” field:
In Ticket #8131 we see two code revisions that were checked in by the developers. Let’s click on one of them to take a closer look:
Our Revision detail page shows some metadata in a configurable header. We also have a tab that has been integrated with Trac, our web-interface that we use with Subversion. To accomplish this integration, we wrote a simple script using Shotgun’s API to make the check-in process trigger the creation of a Revision in Shotgun and update all relevant metadata.
The tab called “Trac Details” receives the Revision number (“code”) as an argument so that we can access Trac from within our Revision detail page. Here’s what the tab’s configuration looks like:
Revisions come with the following default fields:
- Related Revisions
- Revision Name
Related Revisions and Tickets are both multi-entity fields: A Revision can have multiple Related Revisions and multiple Tickets.
Releases come with the following default fields:
- Release Name
The Tickets field is multi-entity, so Releases can have multiple Tickets, as we see in this Releases page:
Let’s click into a Release detail page:
Again we see that the top section has been configured to show some key metadata, and then we have a whole bunch of tabs. All of these tabs, except the Revisions tab, are Ticket tabs. Each tab filters Tickets in various ways using their tags, statuses, and other fields to show us what we want. The Revisions tab, however is configured to show all the Revisions in the Release, by querying through the Revision’s Ticket field to see which of those Tickets are linked to the Current Release:
Essentially this query examines each Revision’s Tickets, and if any of them are linked to the Current Release, it shows them in the tab.
Now let’s go through some customizations we’ve added here at Shotgun to enhance our process. You will, of course, want to customize things your own way for your process. Hopefully this will give you some good ideas.
At Shotgun, we want to organize our Tickets into Sprints, so we enable one of our custom entities and name it “Sprint”:
Our new Sprint entity comes with the following fields:
Next we add some custom fields:
- Expected Date
- Velocity Notes
Each of our Releases may have multiple Sprints.
Now, on Tickets we add an entity field called “Sprint”.
This allows us to assign each Ticket to a Sprint, so we can group, filter, and sort our Tickets by Sprint.
And now we’re ready to track our software development!