How do you build CI/CD and rollback pipelines for Java web apps?

Long Answer

Building CI/CD for Java web applications requires a pipeline that is deterministic, automated, observable, and reversible. The goal is to make releases routine and fail-safe, while preserving system integrity and minimizing downtime.

1) Build and artifact management

• Use Maven or Gradle to produce immutable JAR/WAR/ZIP artifacts.
  
• Enforce dependency locking and checksum verification to prevent supply-chain vulnerabilities.
  
• Run static code analysis (SonarQube, SpotBugs, Checkstyle) during build to catch code smells and violations.
  
• Containerize the application with multi-stage Docker builds: compile, test, and package in a slim image with JDK + required libs. Sign images for provenance verification.
  
• Tag artifacts with semantic version and Git SHA for traceability.
  

2) Layered automated testing

• Unit tests: JUnit/JUnit5, Mockito; fast execution per PR.
  
• Integration tests: spin up dependent services (databases, caches, queues) using Testcontainers or docker-compose; verify repository queries, transactions, and external API integration.
  
• Contract/API tests: use Spring REST Docs or Pact to verify API responses against schema; fail pipeline if breaking changes occur.
  
• End-to-end tests: Selenium or Playwright for critical user flows (login, transactions, form submissions) in ephemeral environments.
  
• Performance smoke: optional lightweight JMeter/K6 tests for throughput/latency checks.
  

3) Environment management and promotion

• Use immutable artifacts and promote between dev → staging → production; avoid rebuilds per environment.
  
• GitOps approach (Argo CD, Flux) ensures declarative infrastructure and consistent environment configuration.
  
• Secrets management via Vault/KMS; no secrets baked into images.
  

4) Deployment strategies

• Blue/green: deploy new version alongside current, warm caches, run smoke tests, and switch load balancer. Rollback is instantaneous by reverting the LB.
  
• Canary: route small % traffic to the new version, evaluate SLO metrics (p95 latency, error rate, resource usage), gradually increase exposure, and automatically pause or rollback if thresholds are breached.
  
• Rolling updates: replace pods gradually in Kubernetes with readiness probes; allow for graceful termination of in-flight requests.
  

5) Database migrations and rollback

• Use expand–migrate–contract for schema changes: add new columns/tables first, dual-write logic, backfill asynchronously, then remove legacy columns after verification.
  
• Migration scripts should be idempotent and safe to rerun.
  
• Keep DB changes backward-compatible with last good app version to enable rollback without data loss.
  

6) Observability and promotion gates

• Instrument services with OpenTelemetry, Micrometer, or Prometheus; collect traces, metrics, and logs.
  
• Gate promotions on SLOs: error <1%, p95 latency < threshold, CPU/memory utilization < saturation.
  
• Alert on anomalies; integrate synthetic checks for critical endpoints.
  

7) Rollback strategies

• Artifact rollback: re-deploy the last known good image or artifact.
  
• Configuration rollback: revert environment manifests or Helm charts.
  
• Database safety: schema changes are backward-compatible; contract steps delayed until stable.
  
• Feature flags: decouple risky features from code deploy, allowing toggling to mitigate live issues.
  

8) Developer ergonomics and speed

• Cache Maven/Gradle dependencies; parallelize tests.
  
• Keep CI pipelines fast (<15 min) by running lightweight tests on every PR; run heavy integration/E2E in nightly or staged pipelines.
  
• Provide scripts to reproduce builds and rollbacks locally.
  

Summary: A Java web CI/CD pipeline standardizes build, test, promotion, and rollback, enforces zero-downtime deployment, ensures observability, and integrates schema-safe database evolution, making releases predictable and reliable.

‍

Table

‍

Common Mistakes

• Rebuilding artifacts per environment instead of promoting immutable images.
  
• Skipping integration tests with real DB/cache services.
  
• Performing destructive DB migrations first; rollback becomes unsafe.
  
• Hard restart of application servers; drops in-flight requests.
  
• Canary deployment without SLO-based gating; exposing users to errors.
  
• No contract/API verification; breaking consumers undetected.
  
• Ignoring observability; errors are detected too late.
  
• No feature flags; mitigating risky features requires hotfix redeploy.
  
  

Sample Answers

Junior:
“I run JUnit/Pest unit tests on push, build the WAR/JAR artifact, and deploy using blue/green via Deployer. If errors appear, I switch back to the previous release.”

Mid:
“I create a signed Docker image with Maven/Gradle, run unit, integration, and contract tests, and deploy using canary behind the load balancer. Migrations use expand–migrate–contract. Observability via OpenTelemetry gates promotions. Rollback is re-pinning the last good artifact and disabling risky features with flags.”

Senior:
“I enforce build-once-promote pipelines: static analysis, unit/integration/E2E, contract verification. Deployments use blue/green or canary with SLO-based promotion, database migrations follow expand–migrate–contract, backfills monitored. Observability via traces, metrics, logs, and synthetic checks. Rollback is immediate: re-pin artifact, revert config, and toggle feature flags. CI pipelines are optimized for speed with caching and parallelization.”

‍

Evaluation Criteria

Interviewers expect:

• Immutable artifacts built once; no env-specific rebuilds.
  
• Layered testing: unit, integration, E2E, contract/API verification.
  
• Zero-downtime deployment using blue/green, rolling, or canary with probes and SLO gates.
  
• Safe database migrations using expand–migrate–contract.
  
• Observability to detect regressions early (OpenTelemetry, Prometheus, logs).
  
• Fast rollback mechanisms (artifact, config, feature flags).
  
  

Red flags: manual deploys, destructive migrations first, skipping integration tests, lack of observability, or rollbacks requiring rebuilds.

‍

Preparation Tips

• Set up Maven/Gradle CI with static analysis (SonarQube, PHPStan equivalent for Java), Pest/JUnit tests.
  
• Add integration tests with Testcontainers (DB, cache, queue).
  
• Generate OpenAPI and verify contracts; block breaking changes.
  
• Build Docker images, sign them, and promote via GitOps (Argo CD, Flux).
  
• Implement blue/green and canary deployments with SLO-based gates.
  
• Apply expand–migrate–contract DB migrations; queue backfills and monitor progress.
  
• Instrument OpenTelemetry; centralize logs; create dashboards for p95 latency, error rate, and throughput.
  
• Practice rollback drills: re-pin artifact, revert config, disable risky feature flags.
  
  

Real-world Context

A fintech team introduced immutable artifacts and GitOps; rollback of a failed canary took under two minutes. An e-commerce platform added integration tests with Testcontainers; a misconfigured DB migration was caught pre-deploy. Another SaaS org used blue/green; a performance regression at 5% traffic triggered auto-pause and immediate rollback. Observability dashboards revealed a N+1 query that increased p95 latency by 25%; the issue was fixed before full rollout. Feature flags helped disable a risky payment feature without redeploy.

‍

Key Takeaways

• Build once; deploy immutable artifacts.
  
• Layered tests: unit, integration, E2E, contract verification.
  
• Use blue/green, rolling, or canary for zero-downtime.
  
• Database migrations must be expand–migrate–contract.
  
• Observability (traces, metrics, logs) gates promotion.
  
• Rollback via re-pin, config revert, and feature flag disable.
  
• CI pipelines optimized for speed with caching and parallel tests.
  
  

Practice Exercise

Scenario:
You maintain a Java web application with PostgreSQL and Redis. A new “subscription tiers” feature adds columns and a caching layer. Deploy weekly with zero downtime and instant rollback.

Tasks:

1. CI: Run static analysis (SonarQube), JUnit/Pest unit tests, integration tests with Testcontainers (DB + Redis).
   
2. Contracts: Verify OpenAPI endpoints; fail pipeline on breaking changes.
   
3. Build artifact: Docker multi-stage image with signed JAR/WAR; cache dependencies; pre-compile assets.
   
4. Database: Apply expand–migrate–contract for new subscription columns; dual-write; queue backfill; monitor progress.
   
5. Deploy: Blue/green or canary deployment behind LB; warm caches; smoke tests; probe readiness.
   
6. Observability: Collect traces, metrics, and logs; SLO gates: p95 latency <300 ms, error <1%, CPU <75%.
   
7. Feature flags: Enable new tiers for employees first; kill switch ready.
   
8. Rollback drill: Trigger error at 25% canary; auto-pause, re-pin last good image, disable flag, confirm dashboards recover.
   
9. Post-mortem: Document timeline, metrics, added tests to prevent regression.
   
   

Deliverable:
Repo and runbook demonstrating Java CI/CD with immutable artifacts, layered tests, zero-downtime deployment, SLO-gated canaries, expand–migrate–contract DB changes, and reliable rollback strategies.