GitHub and Atlassian have been on a crash course for many years now. GitHub is the system of record for code and has expanded slowly into project management (GitHub Projects), knowledge management (GitHub Pages/project wikis), security, and more. On the other hand, Atlassian started with flagship products like Jira and Confluence but expanded into the full lifecycle with code (Bitbucket, 2010) and chat (HipChat, 2012 and Stride 2018) – however, both chat products are now EOL (Atlassian sold Stride for a small chunk of Slack).
Two underlying questions:
- What is a better wedge into a DevOps platform – code or issues? Is project management the source of truth, or is code?
- Do the different parts of the DevOps platform have hard enough API boundaries to separate cleanly? Can best-of-breed solutions integrate, or will a single platform be the one-stop for developers and product managers?
GitLab is the only company that's really publicly executing this strategy.
First – code or issues? As a developer, I'll quickly tell you that code is the source of all truth. Patterns like GitOps put code changes at the initiator of all kinds of workflows – not just developer workflows but also operations. It's natural for issues to reference code but less likely for code to reference issues.
Different parts of the DevOps lifecycle need to track code changes. Pagerduty needs to know when the last changeset was released. Feature flags and CI/CD need to know what changes to roll out and where to roll them out to. Issues can be auto-closed after the corresponding code change is merged. Labels, issue types, and projects are all starting to be configured with code. This makes project migration and maintenance much easier.
Code has been the system of record for developers for ages, but I believe its importance is rapidly expanding.
As for whether or not there can be a single DevOps platform, it's hard to tell. DevOps enthusiasts will tell you that DevOps isn't even a product; it's a culture. Of course, it's a product, but maybe it's so hard to nail down because it's reliant on the current trend, similar to how every new PM director decides to scrape the old project management software for their preferred one.
I think one of the key products needed for a full platform play is great automation. GitHub almost gets there with GitHub Actions, but they aren't accessible to non-technical users and fall short on design. But this is an exciting area to watch.
A quick note about GitLab, the jury is still deciding on their all-in-one DevOps platform. Their products are essentially the opposite of best-of-breed, i.e., good enough but the whole product, as Ted Levitt at HBS would say. Why haven't they taken over the market? One hypothesis is that they lack a system of engagement – issues built into the repository aren't good enough for non-technical contributors. No true Jira replacement, no Slack, and no public issue tracker, where the real discussions are happening. Another hypothesis is based on "DevOps as Culture" – with almost too many products, GitLab doesn't really offer an opinionated path for the opinionated developer.
It was difficult not to squeeze in a good paragraph about GitLab since, as you know, I love writing about GitLab.