Just want to vent here - sorry for wasting valuable bandwidth.
(Rant-mode enabled)
Last two weeks we have been busy migrating away from the terminated on-prem versions of Atlassian products for SCM and CI/CD (BitBucket, JIRA, Crowd and Bamboo).
These products have served us well during the last 10+ years but Atlassian’s move to the cloud and with that the price hike we started looking at options. We are a small team of 2 developers and have thus managed to be on Atlassian’s lowest tier for JIRA and Bitbucket ($10/year) but for Bamboo we have used the $750/year tier to get the integration to AWS, total of $770.
Getting the same functions in Atlassian’s cloud offering would cost us $384 (JIRA) + $180 (Bitbucket) + $1200 (Data Center Bamboo, still on-prem) = $1764/year.
Looking for alternatives we settled for GitLab Premium self-hosted on-prem (yes, we are still old-style 
…). Costs on par with what we previously paid Atlassian at $696/year for two full users.
We have now been busy migrating code, issue-tracking and build pipelines for 12 projects that comprise the parts of our largest product. It has been a frustrating process wasting much time and efforts! Our thoughts so far:
(Worst) Issue tracking
Issue-tracking GitLab is a joke compared to JIRA and we are worse off since we are tracking multiple projects as one release. This was no problems in JIRA but with GitLab’s approach to issues only tied to a project keeping track of the full release is hard. GitLab’s half-baked function of Project Groups takes us only so far, but only hides the problem. We are currently investigating setting up a project just for issue tracking but that will leave us without trace between code commits and issues.
Understand where GitLab comes from with “projects” containing a single (hehe) Project this probably works fine (as shown in GitHub for example) but for our purposes it’s not working.
Speaking to other commercial devs using GitLab it seems like they use other tools and we are currently investigating YouTrack.
(Bad) GitLab’s CI/CD pipelines
Having heard so much praise over how good it is to integrate the CI/CD-pipeline into the source we set out with great hopes. However, we are still struggling with this. Our Bamboo build pipeline is not rocket science - mayly buld a front/end combination (JavaScript and PHP) and package it as a Docker image for upload to AWS provate repository. To make development easier we have split front- and back-end projects into separate repositories but since Bamboo’s pipeline isn’t tied to a project, this has worked well.
Two days into to process from deep frustration we simply gave up on the idea of having split projects and combined front- and back-end into one project.
Laugh or cry?? Since the pipeline needs to be uploaded to the repo to be able to execute there is no way to squash commits because they are pushed to origin…
The YAML style of .gitlab-ci.yml has caused us huge grief with many simple syntax errors that are only caught when running the pipeline after commiting the file, messing up the repos. Due to the fact the pipeline is inside the repo, several functions that we use in Bamboo are missing - most notably the way to clone to a separate directory, instead complex find or mv batch commands have to be used…
(Excellent) Managing source-code
Luckily GitLab at least delivers value managing the source-code! We are using both GitKraken and the builtin SCM client in JetBrains’ IDEs. We get much better performance than from BitBucket and also greater visibility with merge requests etc.
(The ugly) True-up licensing
There’s a built-in Administrator account that during the first two days did not take a seat. However, three days ago it started to count towards our license of 2 seats, bringing the number of billable users up to 3! GitLab’s true-up function means that we will be automatically charged for this user on an annual basis ($348/year). I currently have a discussion with GitLab’s support and accounting team but it seems to be an issue they won’t fix (Administrator account on self-managed instance should not be counted as a seat (#6527) · Issues · GitLab.org / GitLab · GitLab) This was hidden during the evaluation period because the eval license is 100 seats. If you consider GitLab - make sure you disable the Administrator user, even if it currently doesn’t count towards your seats!
(Rant-mode disabled)
Anyone else gone through such migration and what are your thoughts and experiences?
Thanks you for listening,
/Mattias