• Trigger - what starts it: a push, a merge request, a tag, a schedule, a manual click, another pipeline.
• Stage - a group of jobs that run at the same point in the flow (build, test, package, deploy). Stages usually run in order.
• Job - one unit of work with a script, running on a runner / agent / executor (a VM or container).
• Artifact - a file a job produces and later jobs or humans consume (a JAR, a test report, a container image).
• Gate - a condition that can stop the flow: failing tests, a quality gate, a security scan, a manual approval.
• Environment - a place the artifact is deployed to (dev, staging, production), often with its own secrets and approvals.

• Fast, reliable CI. If the pipeline takes 40 minutes and fails randomly, nobody will merge small and often.
• Feature flags (also called toggles) so that incomplete features can be merged but stay dark. The flag is removed when the feature is finished; a flag that lives forever is a hidden branch.
• Branch by abstraction for large refactors: introduce an interface, switch callers one at a time, delete the old path.
• Pre-merge checks: the merge request pipeline runs build and tests, and the target branch refuses red merges.
• Small changes. Large changes are the real reason branches live long.

• -B (batch mode) removes interactive prompts and colour. -ntp (--no-transfer-progress) removes the download progress noise that floods logs.
• Use the Maven Wrapper (./mvnw) so the pipeline and developers use the same Maven version, and pin the JDK in the image or the setup step, not "whatever the agent has".
• Surefire runs unit tests during test (default patterns include *Test, Test*, *Tests, *TestCase); Failsafe runs integration tests during integration-test and checks the result in verify (default patterns include *IT, IT*, *ITCase). Naming decides which plugin picks a test up.
• Make the build reproducible: no SNAPSHOT dependencies in release builds, and set project.build.outputTimestamp so the JAR does not change byte-for-byte on every build.
• Produce test reports as XML (Surefire and Failsafe write JUnit-format files under target/surefire-reports and target/failsafe-reports) and have the CI tool publish them.

Without a cache every job downloads the entire Maven dependency tree from the repository again. A cache stores ~/.m2/repository (or a project-local directory) between runs. The principle is the same in every tool:

• Key the cache on a hash of the files that define the dependencies (pom.xml). When the POM changes the key changes and a fresh cache is built; otherwise it is reused.
• Provide a fallback key (a prefix match) so that a changed POM still starts from the previous cache and only downloads what is new.
• Do not cache build output (target/) as if it were a dependency. Pass build output between jobs as an artifact: a cache is a best-effort speed-up that may be missing, an artifact is a guaranteed hand-off.
• Treat the cache as untrusted input for release builds: a poisoned or corrupted cache should not be able to change what you ship. Many teams build releases with a clean or read-only cache.

• Immutable tags: configure the registry so a pushed tag cannot be overwritten (Amazon ECR calls this tag immutability; other registries have an equivalent). Without this, "the same tag" can silently mean different bytes.
• Deploy by digest (image@sha256:...) when you need an absolute guarantee. A tag is a label that points to a digest; the digest identifies the content.
• Snapshots stay out of production. A Maven -SNAPSHOT version is mutable by design. Release builds use fixed versions.
• Record provenance: the commit SHA, pipeline URL and build time belong in the artifact's metadata (an image label, META-INF/MANIFEST.MF, or Spring Boot's build-info), so a running instance can answer "what exactly am I?".

A flaky test passes and fails on the same code. Each one teaches the team that red does not mean broken, and people start clicking "re-run" instead of reading failures. That destroys the value of the whole pipeline.

• Quarantine, do not ignore. Move a known-flaky test to a separate, non-blocking job with a ticket and a deadline, so it stops blocking everyone but is not forgotten.
• Retry is a smell, not a cure. A bounded retry on infrastructure steps (network downloads) is reasonable; retrying a failing assertion hides real race conditions.

A quality gate is an automated pass/fail decision based on measurements. If the gate fails, the pipeline stops and the change does not merge or ship. Typical conditions:

• Tests pass and the number of tests did not silently drop.
• Coverage on new code does not fall below an agreed level. Measure it with a coverage tool such as JaCoCo. Treat coverage as a smoke alarm, not a goal: a high number with weak assertions proves little.
• No new serious issues from static analysis (bugs, vulnerabilities, code smells) in the code that was just changed.
• No known critical vulnerabilities in dependencies or the container image (below).
• License checks if your organisation requires them.

SonarQube is a common tool for the analysis part. Its quality gate is a set of conditions evaluated on new code or on overall code during each analysis; the default built-in gate is called Sonar way, and you can define your own. The "new code" focus matters in older codebases: you do not have to fix ten years of history to stop things getting worse. The exact default thresholds change between versions, so read them in your own SonarQube instance instead of quoting a number.

The three flags used above exist in the Trivy CLI: --severity restricts what is reported, --ignore-unfixed hides vulnerabilities with no available fix, and --exit-code sets the process exit code when issues are found (so the job fails). Checked against trivy image --help, Trivy 0.76.1, 2026-10-31.

The old way is to create an IAM user, generate an access key and store AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the CI system. Those keys do not expire, live in a third-party system, and must be rotated by hand. OpenID Connect (OIDC) federation removes the stored key altogether.

• The CI platform acts as an identity provider. For each job it can issue a signed JWT that states who the job is (repository, branch or environment, pipeline) and for whom it is meant (the audience).
• In AWS you register that platform as an IAM OIDC identity provider, and create an IAM role whose trust policy says: "principals authenticated by this provider, with this audience and this subject, may call sts:AssumeRoleWithWebIdentity".
• During the job, the token is exchanged with AWS STS for temporary credentials. Nothing long-lived is stored in the CI system. Only the role ARN, which is not a secret, is in the pipeline file.

The provider URL for GitHub is https://token.actions.githubusercontent.com, and for the official AWS action the audience is sts.amazonaws.com. The **sub** (subject) condition is the part that matters for security: without it, any repository on GitHub that obtains a token for that provider could try to assume the role. GitHub subjects look like repo:ORG/REPO:ref:refs/heads/main for a branch and repo:ORG/REPO:environment:NAME when the job uses a GitHub environment. For GitHub, the job must also have the permission id-token: write before it can request the token. Checked against docs.github.com (OIDC in AWS and OIDC reference), 2026-10-31.

On the GitLab side the id_tokens keyword creates a JWT in the variable you name, and aud sets its audience claim; GitLab's AWS guide uses aws sts assume-role-with-web-identity with that token and scopes the trust policy with claims such as sub (and, on GitLab.com, namespace_id and project_id). Checked against the GitLab CI/CD YAML reference and the "Configure OpenID Connect in AWS" page, 2026-10-31.

Two details are worth knowing. The cache is best-effort and keyed, while artifacts are guaranteed hand-offs (chapter 03). And rules replaced the older only/except, which should not be used in new pipelines.

• Trigger: on lists events (pull_request, push to main). Jobs run on fresh runners; needs orders them.
• **permissions:** the file starts with contents: read for the whole workflow (least privilege) and the deploy job additionally requests id-token: write, required for OIDC.
• **cache: maven** on actions/setup-java caches the Maven repository, keyed on the POM files (documented in the setup-java README). No separate cache step is needed.
• **environment: staging** links the job to a GitHub environment, where you can configure required reviewers, wait timers and environment-scoped secrets.
• **concurrency** with cancel-in-progress cancels superseded runs on the same ref and saves runner minutes.
• **timeout-minutes** stops a stuck job from burning minutes.

An environment is a named target with its own configuration, secrets, access rules and (often) its own cluster or account. Promotion means moving the same artifact from one environment to the next after checks pass.

• Approvals are gates for people: a required reviewer on a GitHub environment, a when: manual job or protected environment in GitLab, an input step in Jenkins. Use them where the business or regulation requires a human decision, not as a substitute for tests.
• Separation of duties: the person who wrote the change should not be the only approver of its production deploy, if your compliance rules say so. Most CI systems can enforce who may approve or deploy.
• Deployment windows and freezes can be enforced in the pipeline (a schedule or a manual job) as well as by policy.
• Serialise deployments to one environment (a GitLab resource_group, a GitHub concurrency group, Jenkins disableConcurrentBuilds) so that two pipelines cannot deploy to production at once.

A deployment is only safe if you can undo it quickly. The common approaches are:

GitOps applies the pipeline idea to deployment: the desired state of the environment (Kubernetes manifests, Helm values, Kustomize overlays) lives in a Git repository, and an agent running inside the cluster continuously compares it with the live state and makes them match. The diagram at the top of this chapter shows the difference from a classic push deploy.

• source is the Git repository, revision and path that hold the manifests; destination is the cluster and namespace. The apiVersion: argoproj.io/v1alpha1 / kind: Application form is the one in the Argo CD documentation.
• syncPolicy.automated makes Argo CD apply changes by itself. By default automated sync does not delete resources removed from Git; prune: true enables deleting them, and selfHeal: true makes it revert manual changes to the cluster (documented in the Argo CD automated sync page).
• Without automated, Argo CD shows the application as OutOfSync and waits for someone to press Sync. That is the GitOps version of a manual approval.
• Flux takes the same approach with separate controllers: a source controller fetches Git or OCI sources, and Kustomize and Helm controllers apply them (a notification controller sends events). Pick one and learn its model; the concepts transfer.

A typical split is two repositories: the application repo (code, tests, Dockerfile) and a config repo (manifests or Helm values per environment). The application pipeline builds the image, pushes it, and commits the new image tag to the config repo (or opens a pull request there). The GitOps controller does the actual deployment. This also gives promotion a natural form: a promotion from staging to production is a pull request that changes the tag in overlays/prod.

A slow pipeline is a tax on every developer and a reason to batch changes, which makes failures harder to diagnose. A pipeline that uses too many minutes is a bill. The levers are similar in every tool:

Your pipeline compiles other people's code (dependencies), runs scripts and holds deploy credentials. An attacker who compromises any of these ends up in production. Defences are mostly about knowing and pinning what you run:

• Pin versions. Do not use floating references such as latest for base images, build tools or CI actions. Pin images to a tag or digest, and pin third-party actions to a full-length commit SHA, which GitHub's security guidance recommends because a tag can be moved to a different commit.
• Automate updates with Dependabot or Renovate so pinned versions do not rot, and review the pull requests.
• Lock dependencies. Use a lockfile or a controlled Maven repository manager (Nexus, Artifactory) as a proxy so builds do not pull directly from arbitrary sources.
• Least privilege. Default workflow permissions to read-only; give each job the minimum; separate roles for plan and apply, for build and deploy.
• Isolate runners. Prefer ephemeral runners (fresh VM or container per job). A long-lived shared runner can leak files and credentials between jobs.
• Do not run untrusted code with secrets (forks, untrusted merge requests), and avoid interpolating untrusted input (branch names, PR titles) into shell commands in workflow files.
• Produce an SBOM and sign artifacts where your organisation requires it. The SLSA framework (Supply-chain Levels for Software Artifacts, slsa.dev) is a specification that defines progressively stronger levels of build integrity and provenance; use it as a vocabulary for how far along you are.