Moving and Consolidating: Ticketing

Continuing on with our Moving and Consolidating, today we're going to cover our process of choosing a ticketing system. We've already covered code hosting in a previous post.

Criteria

• Integration with source control (specifically GitHub)
• Support for multiple projects
• Fine-grained access controls
• Agile tools (scrum-style sprint planning)

This wasn't an exclusive list, nor was it really a list of hard requirements.  We were willing to accept a system that was missing some of the features if it excelled in areas we get more value.

Starting Point

We started by using Redmine. On the surface it met all of our needs but in practice it was found wanting.  To be fair, some of these shortcomings may have stemmed from a lack of attention in setup, maintenance and updating.  Regardless of the reason it was our assessment that it was time for a change.

One caveat: We are still using Redmine for some of our older projects.  They will eventually be transitioned.

The Search

There are a lot of ticketing options out there.  They range from startlingly simple to confusingly aimless.  A few weeks were spent evaluating and experimenting. We ended up settling on two candidates: entp's Lighthouse and Atlassian's JIRA.

Lighthouse

Lighthouse is sold as "beautifully simple" issue tracking.  It provides a few simple and well-executed features. Ticket entry is quick and easy.  You can organize your tickets into milestones and tie things into your GitHub projects.

We often found ourselves frustrated with Lighthouse, however. While it delivered what it promised, we repeatedly bumped up against difficulties:

• Stability: Lighthouse was unavailable quite a few times during our work day
• Markdown: We were really spoiled by GitHub's markdown rendering
• Almost Enough: The "simple" approach didn't implement quite enough for us

That last bullet warrants some explanation.  Many on our team were used to more featured systems and we seemed to be running into the edge of Lighthouse's features quite often.  We should've written up a summary at the time so that we could cite specific examples.  Having made this change months ago, they have escaped me.

JIRA

JIRA was always in the running because a few of our team had considerable experience with it.  We hesitated becasue there is a considerable cost involved.  While JIRA is certainly worth that price to many organizations, it was worthwhile to try the competition's offerings before we settled on paying the premium.

It should be noted that Atlassian has recently revamped their hosted offerings. In our opinion the previous "Studio" product was many steps behind the equivalent downloadable offerings and too expensive to boot.  The new OnDemand product is much better and we applaud Atlassian's decision to revamp the line.

To JIRA

Moving to JIRA involved a few perl scripts and a few days of shuffling. Since we opted for the download versions, we had to stand up a new server to run things.  JIRA is memory hungry and I recommend that you run it on a machine that has at least 1.5G of RAM.  This is laughable for real hardware, but an expense to consider if you are using VMs.

We obviously make heavy use of JIRA's projects.  Some of the deeper features such as versions and components have been a bit slower in adoption.  We are, however, refining our procedures and getting people up to speed.

The biggest problem we've had is that JIRA ships with a very austere default dashboard.  Users are often paralyzed when they log in for the first time because there is no obvious call to action.  This can be helped by setting a different default dashboard for your users, but this is difficult when your users are working on wildly different things.

We solved some of the adoption issues by setting up screen sharing calls (using the join.me service with great results) where we walked through JIRA's features and showed people how to use them.  This was very successful and many users reported being really happy with JIRA after this.

Not All Rainbows and Unicorns

Atlassian has proven to be a worthy steward for your development needs.  Each new release provides a mix of fixes and new features that improve your experience.  Looking back over the years I am happy with their progress.  They may be a bit slower than your average OSS project, but they also have a real customer base and a large organization.  Their work is commendable.

Summary

There is a fine line when choosing new tools.  Users will complain quite loudly about new features, but it's very difficult to find the time to solicit feedback from everyone about a new tool.  Finding the time to allocate toward product evaluation for a useful number of people is challenging, especially in a consultancy.  If you have someone who can put themselves in your user's shoes and make a recommendation, that's your best bet.

Many of our projects have adopted custom workflows that reduce the work our developers and management have to perform. Once you teach your users what JIRA is capable of they begin to ask great questions and suggest improvements. This change has resulted in a much more organized and efficient organization.

Moving And Consolidating: Code Hosting

We started an initiative at Infinity Interactive a few months ago to consolidate and simplify the various support systems we use in our work.

Criteria

The first step in our journey was to make a list of the features we needed so we could measure how well each possible provider fit the bill.  Our requirements were:

• Git support
• Subversion support
• Simple administration
• Support for at least a hundred repositories

The combination of Git and Subversion was the most restrictive.  Many of our clients still prefer Subversion so it was important that we be able to work with either system.

The simple administration was important to decrease the internal bottleneck of system administration.  We were specifically looking to decrease the number of machines and services we were managing internally.

While we were happy to decrease our administrative overhead, we also realized that hosting code externally could be problematic for a few of our projects.  We sometimes manage large files in the repositories and hosting our code externally would create slowness in checkouts of these large files.  We decided this was a limitation we could factor into our plans or mitigate with separate tools later.

The Players

After evaluating various providers we first settled on Beanstalk.

The Good

The honeymoon with Beanstalk was pleasurable. We began to spin up lots of repositories and use them in day-to-day projects. The interface was simple and effective.  We made use of the deployments feature to push code out to our QA instances. The color-coding of repos was somewhat useful and the availability of an API was handy.

The Bad

The downtime.  It wasn't frequent that Beanstalk would have trouble, but it was often enough that it became frustrating.  We were using it with Lighthouse – which is a whole different post – and each of these products had occasional, middle-of-the day outages.

And it wasn't as nice as GitHub.

GitHub's Subversion support was announced on April Fool's Day, but it wasn't a joke.  A month later they announced write support. This feature isn't advertised much on their website, so it is understandable that we missed it initially and why we were hesitant to depend on it.  Eventually we tested it more extensively and found that it worked well.  Recently they announced even more features.

When comparing Beanstalk to Github we constantly found Beanstalk coming up short.  First, we all have GitHub accounts for our personal code. Second, we missed some of the features that had become so helpful for our personal use: Markdown rendering, super easy forking and pull requests and wide integration with other products.

Home Sweet GitHub

After suffering another outage or two with Beanstalk and realizing that Subversion worked well with GitHub, it became obvious that switching to a GitHub Business Plan was the right thing to do.  We opened an account and added everyone's personal accounts to our Organization.

Many of our repositories were moved very quickly after opening our account.  The Subversion-based repos were a bit slower to migrate, the last one being moved just today.

We've been very happy with this change.  Everyone loves having their work and personal repositories separated, but in the same general place. Much of our work involves other open-source repositories and the convenience of GitHub has been a huge boon.

Not All Roses

That being said, GitHub isn't perfect. We often hear complaints about the "context" switching as users switch between their personal account and the organizations they are in.  We quickly blew past the smaller accounts and had to upgrade to their biggest one.  We have a small number of employees compared to the number of repositories we have.  The price, however, is reasonable for the features they provide and the steady march of new ones they debut.

One little complaint: We miss pre-commit hooks.  We'd love to be able to reject commits that don't reference a ticket.

Success All Around

While we ultimately ended up choosing GitHub, we likely appreciated it more because of our experience with Beanstalk.  All of our developers are more efficient and our interactions with external projects and developers work better.  Thanks, GitHub!

Welcome To Our New Site!

Infinity interactive has been really busy.  So busy, in fact, that we've neglected our website for many years.

No longer!

Not only have we revamped our website look and feel, we've added search capability and this blog to help you stay informed about the things Infinity Interactive is up to.

We look forward to sharing our work with you!