Profiles, Properties, and CI-Friendly Versions

Environment-specific profiles, -D properties, flatten plugin, and reproducible CI builds.

Intermediate10 min read

Read these first

Dependency Management, BOMs, and Exclusions

Why this matters

This topic directly affects how reliably BookStore reaches production — profiles and ci-friendly versions let bookstore build the same pom in dev, staging, and release pipelines..
Interviewers connect hands-on commands and manifests to real delivery stories, not buzzwords.
Later modules assume you can explain both the why and the concrete file or command involved.
Platform maturity shows up when teams automate this instead of relying on tribal knowledge.

validatePOM checks

compileSource → .class

testJUnit via Surefire

packageJAR / WAR

verifyIntegration tests

installLocal repo

deployRemote repo

Phases run in order. Common goals bind to phases — compiler:compile runs at compile, surefire:test at test.

Profiles for environments

staging vs prod properties: BookStore engineers treat this as part of the standard path from laptop to maven profiles and ci builds readiness. Document decisions in the team runbook so on-call knows which knobs exist.

Key ideas

Profiles for environments — primary idea for maven-profiles-and-ci-builds
BookStore context — catalog API, checkout, and inventory services share the same pattern
Automation — prefer pipeline jobs over manual SSH steps
Verification — staging must prove the change before prod traffic

CI-friendly versions

flatten and -Drevision: When staging matches production architecture, BookStore catches misconfigurations early. Pair this section's practice with observability dashboards to confirm behavior under load.

Key ideas

CI-friendly versions — operational detail
Rollback — know how to revert without rebuilding artefacts
Security — least privilege for deploy roles
Documentation — link runbooks from the service README

Production checklist

Before promoting BookStore changes tied to this topic, run automated tests, inspect artefact immutability (image digest or JAR checksum), execute a staging smoke test on /actuator/health, and watch error-rate dashboards for thirty minutes after prod rollout.

Key ideas

Staging soak — validate under synthetic load
Change ticket — attach pipeline URL and artefact digest
On-call — page owner stays on dashboards during rollout
Post-deploy — record metrics baseline for comparison

Java

mvn -Pstaging -Drevision=1.4.0-rc.1 clean deploy
# flatten-maven-plugin writes resolved version for CI

Quick recall

Everything you need if you only revisit this box.

BookStore uses maven profiles and ci builds as a standard delivery practice.
Prefer automation and versioned config over manual server changes.
Staging proves changes before customer-facing promotion.
Observability confirms success — do not rely on silence alone.
Rollback plans must be tested, not invented during an outage.
Security and least privilege apply to every pipeline and cluster role.

Test yourself

Answer these before moving on — recall is what makes it stick.