Started moving the repositories that are in production from Bitbucket to GitLab over the weekend. Some reasons were:
After moving to GitLab, I took some time to set up an automated build, test and deploy cycle with GitLab CI for this website.
Pretty impressed with the progress the team made over the years.
The code search gap was the one that hurt. When you keep every project for a small team in one place, “which repository had that deployment script” is a question you ask every week, and on Bitbucket in 2016 the answer was to clone everything and grep it yourself. GitLab served that search in the browser, across all projects at once.
Self-hosting closed the other two reasons. A GitLab instance on your own box keeps the repositories on hardware you control, with no per-seat pricing counting your teammates, and the Community Edition source was open, so when the CI runner did something opaque I could read the code instead of guessing at it.
GitLab CI of that era ran off one file in the repository root, .gitlab-ci.yml, and every push sent it to a runner. For a static site like this blog the pipeline comes out small:
stages:
- build
- deploy
build:
stage: build
script:
- bundle install
- bundle exec middleman build
artifacts:
paths:
- build/
deploy:
stage: deploy
script:
- ./bin/deploy build/
only:
- master
A pipeline like that gives a static site the full loop: push a post, the runner builds the site, and if the build fails the old version stays online because deploy never ran. Ten lines of YAML in exchange for never hand-deploying a blog again.
Published on by Stanley