Mastering CI Across GitHub, GitLab, Jenkins & CircleCI — Without Losing Your Sanity
CI isn’t just a nice-to-have—it’s your early warning system against code chaos. Think of it as the oracular gatekeeper of your project: it may come with some setup costs, but those are nothing compared to the cost of bugs slipping through unnoticed. With the right CI strategy, we don’t just prevent our codebase from degrading—we actively guide it toward better quality, cleaner structure, and faster feedback. In this article, we’ll walk through how to configure CI across multiple platforms, with patterns you can reuse like building blocks (and yes, a couple of developer jokes along the way—because we’ve all had CI pipelines that felt like they were laughing at us).
🚀 Want to Set Up CI and Boost Code Quality?
Looking to improve your development workflow, catch issues early, and keep your codebase clean and maintainable?
👉 Let’s make it happen. Get in touch at https://rubystacknews.com/get-in-touch/ — and let’s talk about how to bring smart CI strategies into your project.
🔧 The Common CI Recipe
Let’s start with the shared ingredients — the “base dough,” if you will:
A custom Docker image (with love, probably from Docker Hub)
PostgreSQL and Redis services
Environment variables like RAILS_ENV, SESSION_EXP_MINUTES, and MAILER_SENDER
Database setup using db:create db:migrate
RSpec tests, because what’s more satisfying than green dots?
Now let’s slice it platform by platform:
🟦 1. GitHub Actions
📄 File: .github/workflows/ci.yml
🟥 2. GitLab CI/CD
📄 File: .gitlab-ci.yml
Bonus: If .gitlab-ci.yml breaks and you spend 3 hours fixing indentation, congratulations — you’ve unlocked “YAML Warrior” 🥷.
☕ 3. Jenkins (Declarative)
📄 File: Jenkinsfile
Jenkins: because you like your CI with a retro web UI and just the right amount of pain 😅.
🔵 4. CircleCI
📄 File: .circleci/config.yml
CircleCI: for when you want your pipeline to look like a circle, but work like a rocket 🚀.
🟨 5. Bitbucket Pipelines
📄 File:
🗒️ Notes:
Docker image: use your custom image with Ruby, Node, etc.
Services: Postgres and Redis are easily attachable.
ENV vars: you can inject , , etc. via Repository Settings → Repository variables.
Hosts hack: Bitbucket containers sometimes need updated just like the others.
🔁 Key Patterns Across All Platforms
✅ Use custom Docker images with auth
🔧 Spin up Redis and Postgres as services
🧬 Standardize ENV variables
🧠 Use /etc/hosts hack to make your services resolvable
🧪 Setup database, then run tests
🚀 Bonus Tip: Speed Up Builds Like a Pro
💾 Dependency Caching (GitHub Actions Example)
“Caching saves time. And so does skipping meetings. But caching won’t get you fired.”
🧪 Parallel Testing (RSpec Example)
Split tests, conquer time. Why run them one-by-one when your CI runners are just waiting to flex?
And sure, at the end of the process, you might just get an error message in bright red, with a giant ❌ glaring at you like it’s judging your life choices. But hey—it’s better to be warned by your CI than yelled at by a frustrated user when the system goes down. Errors caught early are lessons; errors in production are tickets. Lots of tickets.
🏁 Final Thoughts
CI doesn’t have to be confusing. By unifying your setup across platforms, you can maintain consistent behavior, reduce surprises, and impress that one developer on your team who always says "Did you lint this?"
So plug in your [IMAGE], add your [VERSION], and go forth — because real devs don’t push straight to main without tests. (Right?... Right??)
