From commit to container with GitHub Actions.

The pipeline is part of the product

If a service can only be built on one laptop, it is not ready. GitHub Actions gives the repository a repeatable machine: clone, build, test, and package.

For a Spring Boot service, the first useful pipeline is deliberately small.

A minimum useful workflow

On each relevant push or pull request:

1. Check out the code
2. Set up the JDK
3. Run tests
4. Build the application
5. Build a Docker image when the branch should be releasable

The image is the artifact you promote. Avoid rebuilding the application with a different local JDK at deploy time.

Docker as the runtime unit

A Dockerfile should describe how the service runs, not how your machine happens to work. Keep configuration in environment variables. Do not copy secrets into the image.

Local Compose files are useful for running PostgreSQL and the API together. They should not become the only undocumented way the system starts.

Secrets stay outside Git

Cloud credentials, registry tokens, and private connection strings belong in GitHub Actions secrets or in the target environment. If they appear in a workflow file, they will eventually appear in history.

This is one of the few delivery rules that should be treated as non-negotiable.

Azure comes after the pipeline exists

Deploying to Azure is easier when the pipeline already produces a tested image. The cloud target should consume an artifact, not invent a new build process.

Once that split is clear, changing the hosting service later is an operations change instead of an application rewrite.