Summary
This tutorial starts from nothing: a generated Quarkus application, a GitLab repository, three Heroku apps for staging, pre-production and production, and a single pipeline to serve them all. The aim is to show, step by step, how a serious pipeline is built, not only how it deploys.
The heart of the set-up is the mapping between sources and environments: the staging branch deploys to the staging app, master to pre-production, and only protected tags starting with v reach production. The Heroku variables are protected and masked, so they are injected into protected branches and tags only; nobody can deploy to production from an arbitrary branch or remove a tag once it is set.
The rest is pipeline hygiene: build, test and deploy stages on a Java 11 image, a hidden deploy job that three jobs inherit while changing only the target app and the trigger rule, a Maven cache keyed by project so that later pipelines download nothing again, and the GitLab templates for secret detection and static analysis that come without a paid licence.
The companion repository keeps one branch per step, so the pipeline can be followed as it grows. The next steps are named: publishing artifacts to a registry, building and storing a container image.
Key ideas
- One pipeline, three environments: the staging branch, the master branch and protected tags decide the target of each deployment.
- Protected and masked variables are injected only into protected branches and tags, which locks down the production deployment.
- A hidden deploy job, inherited three times, keeps the pipeline short: only the target application and the trigger rule change.
- The per-project Maven cache and GitLab’s free security scans make the pipeline faster and safer without an extra licence.
Why I wrote this
The goal of this tutorial is to build and deploy, step by step, a simple application with Quarkus, using a GitLab-CI pipeline and Heroku’s managed services.