has now been live for one month.

With the aim of “building in the open”, let's have a quick look at what's changed, what's planned, and what surprised me.

March 2020 Stats

First, the stats:

Total Installations: 3
PRs Merged: 1

What's Changed

This month I did a lot of rework of the code. I had a self-imposed deadline of launching by the time my article was up on the Honeybadger Blog, reasoning that this was a potential source of traffic and I wanted to be able to direct that traffic to GitArborist.

This deadline, however, meant focusing on the minimum to get things working and installable (i.e. listed on the Github marketplace). I had a single class handling all String parsing for incoming commands. Another class had a large number of interactions with other classes.

Spring Cleaning ๐Ÿงน

March, then, was a time to get things truly production-ready and tidy up all this code. I set up a logdrain, added some performance monitoring, and refactored the command parsing.

I'm building in Ruby on Rails using the interactor pattern, so I re-shuffled a lot of this logic into interactors and organizers (an organizer is a list of interactors that execute in order but stop if any of them fail).

This is a “nights and weekends” project, so this cleanup took some time. I still have parts I want to tidy up, but the code is in a much better place as a result of this effort.

Focus ๐Ÿ”ญ

There are two large chunks of work that I have deliberately avoided; UI and server-executed Git commands. Adding a UI is virtually impossible to avoid, particularly as the number of options in the application grows. Nevertheless, UIs take time to design and code up, time that could be spent adding more features. As a result, I'm pushing the UI work off the table for now.

The other chunk of work are things that require running Git on the server. Things like rebasing pull requests or synchronising forks. This is undoubtedly possible but requires some time to work out the infrastructure, so it too has become a “soon but not yet” item.

New Features In March ๐ŸŽ‰

I was able to launch two new features this month:

  • Scheduled pull request merging

This was a ‘scratch my own itch’ feature. This blog is a static site stored in Github, automatically built and deployed by Netlify. By creating a PR with the new blog post I can schedule when I want it to go live. This allows me to more heavily dogfood my own app, and should also reduce the friction of publishing a post. If you're reading this at all, it means that GitArborist was able to merge it at a scheduled time ๐Ÿ˜„

  • Evergreen help comments

One of the earliest commands I implement was the help command (via @GitArborist help). The app will respond with a markdown formatted comment listing out the commands and syntax it supports.

The trouble is, these comments could hang around for a long time. What if someone stumbles across an old version? No longer an issue - there is now a scheduled job to update the content of any out-of-date help comments when the help message changes.

Surprises โ—

The first thing that surprised me is that people who have installed the app do not seem to be using it. After some thought this made sense, the installations thus-far have been single-user accounts, but the features I'm providing are much more applicable to organisations. I have no doubt that my lack of onboarding plays a part here, but overall I'm not too concerned yet. It's also possible they are waiting for new features (the website is teasing auto-merging dependabot PRs).

The other surprise was the high latency when the app receives an installation request. This can creep into double-digit seconds in some cases. It turns out this is due to users signing up with all their repositories, whereas for testing I only use one or two. Part of the installation is storing the repositories in my database, so lots of repositories = lots of DB calls. In future, I'll probably move this to a background job, but it still works as-is for now.

April Roadmap ๐Ÿงญ

Over the next month I'm hoping to complete at least 2/3 of the following (not listed in a particular order):

  • Mark PR dependencies (just status, no auto-merge)
  • Merge a PR once CI completes
  • Auto-merge PRs by dependabot

These three features, particularly the first, are what I would consider a “Minimal Marketable Product”. I'm not really comfortable promoting GitArborist heavily until it can do at least 2/3 of these things.

I also have some rework of how PR statuses are being handled so they are better at handling different status strings rather than the current one which is largely hard-coded.