The Great Asterisk Migration: A Year Later

It’s been a full year since we migrated Asterisk to GitHub. It didn’t go perfectly smoothly but knowing what we know now, would we do it again? Hmmm.  Let’s see.

A bit of history…

Back in 2015, we were using Subversion for source control, Reviewboard for code reviews, Bamboo for testing/continuous integration, Jira for issue tracking and Confluence for documentation, all of which was self-hosted. Subversion however had become too cumbersome for distributed development so we decided to move to Git for source control. With that move, Gerrit and Jenkins became the better choices for code review and testing/CI so we moved to them as well and we were fairly happy with the result. Over time though we realized that, for a software development team, we were spending too much time maintaining the infrastructure. We also ran up against licensing issues with Jira and Confluence which forced us to stay on older, insecure software versions. In the mean time, platforms like GitHub and GitLab were maturing into full-service development platforms so we decided to do some research and see if we could migrate the project to a fully-hosted platform. The result of the research was a migration to GitHub for issue tracking, code review and testing/CI in April of 2023.

The Migration

The migration itself wasn’t all that difficult because we really didn’t “migrate” anything. We already had a mirror of the project’s source code on GitHub and we didn’t move any issues or code reviews from Jira or Gerrit, we just started fresh on GitHub. Most of the work was getting the CI workflows up and running. That’s not to say the new issue reporting and code review _processes_ were without problems however. Here are some of the “gotchas” we faced:

• GitHub’s security model is fairly restrictive but also fairly coarse grained. For instance, issue or pull request creators can’t set labels on them unless they’re a member of the Asterisk organization but granting them membership conveys more permissions than we’d like. It’s also an admin burden on the Asterisk team members to maintain.
• The GitHub pull request process doesn’t support cherry-picking. Since Asterisk maintains multiple release branches, most code changes get applied to multiple branches. Gerrit had a nice feature that allowed the user to cherry-pick their change to another branch from the UI. Since GitHub doesn’t have that, we had to write our own cherry-picking facility using specially crafted pull request comments. As it turns out, this would up being easier for the submitter but it required development on the part of the project team.
• GitHub enforces severe restrictions on workflows triggered by pull requests submitted from forked repositories. A workflow triggered this way can’t even set a label on the PR that triggered it. In hindsight this makes sense but it initially caught us by surprise. We had to do some fancy footwork to get around the restrictions while still keeping the project secure.

Those were just some of the issues we faced.

Are We Happy Now?

Not perfectly happy but…

• We have more resources available to us than we did when self hosted.
• Service availability has dramatically increased.
• We no longer pay for the bandwidth required to access the infrastructure.
• We no longer pay for the hardware or its maintenance.
• We no longer pay for the electricity, cooling, floor space.
• We no longer spend time on hardware or software upgrades.
• We pay no software licensing fees.
• We no longer run old/insecure software.

So what do you think? 🙂