I’ve relied on Phabricator and Arcanist for the last 8 years at all my places of employment, after having been introduced to these tools by an ex-Facebook employee. Hence, last year’s news that Phacility would stop developping phabricator where saddening to me.
Reflecting on the particular development process that the arc+phab combo advocated for, it is clear that most of its benefits can be emulated with a little bit of tooling. Exactly why the principles advocated by Phab' are benefitial for a development team will be the subject of another post.
This note goes into what to consider if you are looking for a phabricator and/or arcanist replacement and concrete starting points if you want to port the arc workflow on Github or Gitlab.
Principles
Very roughly, arc
and phabricator
pushed for:
- Trunk based development
- Strong guardrails around the process of collaboratively writing code
- Early Feedback
- Developper Responsibility
What I particularly liked was the focus on the CLI, where the review process started and ended, generally leaving your workspace in a clean state1. Plus, the CLI tooling provided you with a standard process that was pretty hard to sidestep, enforcing all conventions rather than depending on the goodwill of the devs.
Hence, for my future coding endeavors in the enterprise landscape, I will continue pushing for the above and emulate the best of arcanist through some ad-hoc tooling.
Introducing Pseudo-Arc
The first version comes in the form of two bash scripts that replace arc
’s basic functionality: they will let you diff
and land
things to GitLab.
Combined with the propper merge commit template and pre-commit for linting, this already provides for a developper experience that hits surprinsingly close to home if you’re missing arcanist.
If you’re considering replacing Phabricator, I encourage you to try a similar approach: adapting it to GitHub or any other code hosting solution is relatively easy, while it can be adopted by individual developpers without much impact on the rest of the organisation.
Reminiscence
Observing how Evan Priestley managed the development was enriching in itself. As some random commenter put it (can’t remember where):
Thanks for all the fish.
The product the small team at Phacility built was truly impressive, and they kept a razor sharp focus on the most important thing: build a tool to write great code as a team.
Contrasting Phabricator with alternatives such as GitLab and GitHub, which have gained most of the mindshare, as shown by the JetBrains survey, one sees different product development strategies.
GitLab, for example, feels to me as a huge collection of features glued together too quickly with the only goal of satisfying every possible feature request. That’s probably a viable strategy, especially as their main competitor is GitHub.
GitHub, on the other hand, has established the de-facto standard way to collaborate in an open-source setting: lots of repositories, lots of branches.
With the room these two alternatives take, it’s easy to overlook development processes and methods that get way less exposure and generally tend to happen behind the closed doors of the enterprise.
Phabricator provided an easy way to onboard onto such conventions: now we’re left only with our own experience.
-
It always amazes me that the standard github and gitlab workflows make it extremely easy to forget some changes on a local branch, and leave the responsibility to clean up local branches (once they are merged) to the developper. ↩︎