another man's ramblings on code and tech

Final Directions on GitLab

So, at this point, I’ve worked with GitLab for about three weeks straight making demo after demo to compare features to Bitbucket. The biggest thing I learned about GitLab is that it’s really easy to get running fast with. It's definitely a powerful framework with some serious DevOps chops. Here’s the direction our company took after my work and research..

Comparable or better features…

Really, GitLab and Bitbucket are pretty similar. They’re both highly tuned for integration with DevOps platforms with an emphasis on the “dev” side quite well. GitLab has a lot more “support” for different technologies than Bitbucket, but it seems some features are quite duct taped together or rather paper thin in some ways after playing with it; I’ll dive more into this in a later section. While GitLab might work with more tools overall, Bitbucket seems to have fewer but better made tools. This makes Bitbucket a little more rigid and GitLab a little more flexible. So, in categories of “total integration capability” GitLab would win, but it would also win “the most paper thin claims to supporting a feature possible” award. So, they’re both quite competitive.

For a worse price

Everything at the bronze and silver tier from GitLab are quite basic. Really, most people could live off of the GitLab core app and be fine. The price really jumps when you get into Environments and Deploy Boards, going from $4 per user to $20! If all of the features offered were fully developed and robust, then it might be worth a jump like that. But they’re not, which we’ll dive into next section. Compare this to Bitbucket’s much cheaper group plans, and the value proposition for GitLab seems to equalize.

Some feature claims are paper thin at best

Now, this is not representative of all of GitLab. Most of their features are quite robust and easy to use. A common theme I ran into with my testing, however, was that the GitLab advertising for a tier would include a set of features, and when I went to test them I found the bare amount necessary to consider it a feature. Here’s three examples from my research

“Container scanning”

I expected there to be a container scanning job or step that I could slot into my .gitlab-ci.yml that would automatically do the work for me. However, that is wrong. Here’s what GitLab itself tells you to add to your pipeline file to get it working:

  image: docker:stable
    DOCKER_DRIVER: overlay2
    ## Define two new variables based on GitLab's CI/CD predefined variables
  allow_failure: true
    - docker:stable-dind
    - docker run -d --name db arminc/clair-db:latest
    - docker run -p 6060:6060 --link db:postgres -d --name clair --restart on-failure arminc/clair-local-scan:v2.0.1
    - apk add -U wget ca-certificates
    - wget
    - mv clair-scanner_linux_amd64 clair-scanner
    - chmod +x clair-scanner
    - touch clair-whitelist.yml
    - while( ! wget -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; done
    - retries=0
    - echo "Waiting for clair daemon to start"
    - while( ! wget -T 10 -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; echo -n "." ; if [ $retries -eq 10 ] ; then echo " Timeout, aborting." ; exit 1 ; fi ; retries=$(($retries+1)) ; done
    - ./clair-scanner -c http://docker:6060 --ip $(hostname -i) -r gl-container-scanning-report.json -l clair.log -w clair-whitelist.yml ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG} || true
      container_scanning: gl-container-scanning-report.json

Yeah, that’s right. It’s just a huge fucking script they wrote to download Clair and run it. In my opinion, to call this “easy container scanning” integration is a scam. The worst part is this snippet didn’t even work for me the first time because of Docker in Docker issues on the Kubernetes executor. The only way GitLab can justify this as a feature is that their frontend can show you some details about Clair reports. You’ll see “stick a label in the UI” is a common definition of “easy integration” here.

“Error metrics”

You enter a link to your Jeiger instance. Then that link is available in the “Operations” tab. When you click the link, you go to your Jeiger instance. Not what I was expecting exactly.

“Environment, Canary, Deployment Integration”

OK, to be fair, these features are meant to run more in symphony with GitLab’s AutoDevops based features. However, I believe it’s safe to assume that most companies are going to need some sort of control over their DevOps pipeline, so I think it’s safe to assume that a lot of companies will be totally ignoring AutoDevops. So, in my experience integrating these, they’re just labels in the Environments section of the UI. There are some neater elements, like being able to dive into a pod’s logs or console for a given env pretty easy. However, these are cantrips. You can do the same thing on your GCP dashboard quite easily. Otherwise, it’s just UI elements with pictures and links to your env.

Wrapping it all up

So, rereading this article, it seems that I really hate GitLab. That is not the case. I consider the core app and the Enterprise free and bronze tier quite powerful. Where I start to question their abilities is for the silver and above Enterprise tiers. GitLab and Bitbucket, otherwise, are quite similar, and both powerful in their own ways. So GitLab is a valuable, robust platform, but some features are a facade for PMs to better sell the product with new buzz words.

Overall, my time playing with GitLab has been valuable. I’ve set up a couple of repos, played around with some different build and deploy pipelines, and gotten a good feel for their app and workflow. However, I won’t be extending my free Gold tier trial anytime soon. I think our app can stay on Bitbucket until better reasons are presented to migrate the infrastructure.

Date: Mar 01 2019