Blog

News from the versioned universe

Moved to GitHub

After the 2.0 release we moved our entire development infrastructure to GitHub. Leaving JIRA and Bitbucket behind, it was an interesting experience that I want to briefly blog about.

Why to move

The first point I want to make is that we were _happy _with Atlassian's tools. Not overly excited but also nothing too serious to complain about. JIRA is often frown upon but apart from having two issues – being slow and being slow – it is a good system, well thought-out, usable, I would even call it simple. We were also happy with Bitbucket, its code reviews, team collaboration features etc.

However, VersionPress will open up to community development one day and it is a simple fact of life that the developer community, including WordPress developer community, is on GitHub. So we needed to move there and wanted to do it sooner rather than later.

JIRA -> GitHub Issues

his was probably the biggest change. While we used JIRA very “lightly”, i.e., no deep issue hierarchies or dependencies, basically just as a glorified table of issues, the switch to GitHub Issues was still quite a change.

The main “issue” with GitHub Issues is that it might be too simple of a system. Don't get me wrong, simplicity is a great value, however, there's a balance and GHI might be crossing it.

For example, you typically want to have priorities for your issues. All traditional issue trackers have that but GHI don't. You can emulate that with labels but that's emulating – every project can do it differently so there's no consistency, GHI labels are sorted by name so maybe you should prefix priority labels with “priority: “, if you rename the labels later they will not be renamed in the issue history etc. Those are all small issues but make you think, unnecessarily.

After living with GHI for a couple of weeks, it is a good enough system. Some things took some getting used to and I still wish GHI labels were better implemented (proper renames, sorting, label descriptions etc.) but generally, it's OK.

One tip here: overv.io is a really nice layer on top of GitHub Issues. I especially like these three things about it:

  • No lock-in. Everything is stored into GHI via the API, we can leave overv.io any time if we wanted to.
  • Kanban board with manual sorting. Good for prioritizing work.
  • Nice Markdown semi-WYSIWYG editor and generally the UI is very polished and pleasant to work with.

I wish those guys had a paid plan, I feel almost bad using this service for free 🙂

Bitbucket code reviews -> GitHub pull requests

What probably surprised me the most is that Bitbucket pull requests and collaboration features are probably a bit better than those on GitHub, despite the fact that GitHub built its reputation around it.

On Bitbucket, we worked like this:

  • For a JIRA issue, someone created a feature branch for it and started hacking.
  • When the code was ready, he opened a pull request on Bitbucket and invited other team members to do a code review. This automatically sent email notifications.
  • Every reviewer did a code review and:

    • Marked the code as OK – there was an “approve” button
    • Added a line or commit comment
    • Created a lightweight task directly inside the PR
  • There was a PR overview page where one could clearly see which PRs are approved, which need further review, how many tasks are still open etc.

Very natural but some steps were surprisingly cumbersome to emulate on GitHub, e.g. 3a or the last one. Eventually, we found workflows that we are quite happy with, for instance, the “approve” button can be emulated with @username inside the first comment and one can then see on the PR overview page which PRs are complete and which need further attention.

Wiki

Wiki in GitHub is really simplistic and feature-wise much inferior to DokuWiki that we used before but I like that it's just a set of Markdown documents versioned by Git. I can pull the repo locally, make some edits and then push again – that is good.

Because we try not to depend on wiki too much (“issues over wiki”), it didn't make much sense to keep a separate system when almost everything else is now on GitHub, I just wish GH wikis would have search.

Overall

While I believe that Atlassian's (and possibly others') tools are slightly superior to GitHub, we are generally happy there. For now, we have made the docs repo public so if you spot some issue in our documentation, send us a pull request. In the future we will be opening up more of VersionPress.

Discuss & subscribe on Reddit:

r/VersionPress