> The head of SRE championed Gitlab CI. I resisted this idea because I, the relatively inexperienced manager of a nascent team, was daunted by the prospect of trying to supplant Jenkins, Github, and JIRA all at once.
I think this is a really big scoping mistake. There is a clean glide path, and I have no idea why you'd think you need to replace Jira.
You can use Gitlab Runners in Github (https://docs.gitlab.com/ee/user/project/integrations/github....). Then with your mirrored repo you can try out the Gitlab features and realize it's better to use Gitlab for your repo if you're aso using it for CI. Having switched back and forth over the years (with tens of engineers using the repos), it's really not a lot of work to migrate between Github and Gitlab.
Finally, if you like Jira, just use that? Sure there are advantages to having everything in one place, but if you're already using Jira+Github then you'll get an equivalent experience with Jira+Gitlab.
I think this is one of those things that if you had actually prototyped the migration, you would find that it's much easier than you thought it was going to be.
Our company switched from GitHub / Jira to everything on GitLab because devops had the authority to make the switch and that's what they wanted.
PMs now complain that the GitLab "issue board" is nowhere near a replacement for Jira and us devs complain that GitHub had a nicer UX and less stability issues.
The fact that Gitlab Issues aren't a replacement for Jira is a feature IMO. Jira is surprisingly awful at its main job. For example you can't have more than 2 levels of parent/child tasks (compared to Phabricator which has no limit). Changing an issue to a task or vice versa goes via a complex batch update mechanism. Over-configurability means you end up with a gazillion different task states (Done, Resolved, Finished, Closed, ...). You can't do basic things like reorder the backlog based on priority.
Perhaps most critically the interface is just insanely slow! It regularly causes waits in sprint meetings while we wait for someone to drag & drop an issue or for the page to load.
The only reason it's popular is because PMs like to make engineers do their job for them so they can just click a button and get pretty graphs that they can copy & paste to presentations.
What management and what devs need from an issue manager is very different. Which is why every 5-10 years everyone wants to switch to a simpler tool, then slowly most of the complexity in the first tool gets added back as the people who needed that one feature complain loud enough, until the people who wanted simplicity become the loud voice and you switch to a simpler tool. It is never the tools fault above. (Some tools are better than others, but the real problem isn't the tool)
I’ve threatened to do this to a sales department - send them a bill for lost time, engineers working overtime, etc because they sold shit without a clue if it even was possible.
Lead balloons have flown better than that idea did :)
> Finally, if you like Jira, just use that? Sure there are advantages to having everything in one place, but if you're already using Jira+Github then you'll get an equivalent experience with Jira+Gitlab.
Sometimes you don't adopt X because its likely to make people want to adopt Y
I think this is a really big scoping mistake. There is a clean glide path, and I have no idea why you'd think you need to replace Jira.
You can use Gitlab Runners in Github (https://docs.gitlab.com/ee/user/project/integrations/github....). Then with your mirrored repo you can try out the Gitlab features and realize it's better to use Gitlab for your repo if you're aso using it for CI. Having switched back and forth over the years (with tens of engineers using the repos), it's really not a lot of work to migrate between Github and Gitlab.
Finally, if you like Jira, just use that? Sure there are advantages to having everything in one place, but if you're already using Jira+Github then you'll get an equivalent experience with Jira+Gitlab.
I think this is one of those things that if you had actually prototyped the migration, you would find that it's much easier than you thought it was going to be.