CI/CD Pipeline Stages

A CI/CD pipeline is a sequence of automated stages that builds, tests, validates, packages, and deploys software. For a Java backend engineer, the goal is to make changes reproducible, testable, and safely releasable.

A typical pipeline starts when a developer pushes code or opens a pull request. The pipeline checks out the source, resolves dependencies, and runs a build so compilation or dependency problems are detected early.

The next stages usually run automated quality checks such as unit tests, integration tests, static analysis, and formatting or style checks. A failed stage normally prevents later stages from executing, although some pipelines allow independent checks to continue.

After validation, the application can be packaged into a deployable artifact, such as a JAR file or container image. Packaging once and promoting the same artifact through environments helps keep what was tested consistent with what is deployed.

Deployment stages deliver the artifact to environments such as development, staging, or production. Production deployment may include approvals, environment-specific configuration, health checks, smoke tests, rollback mechanisms, or progressive rollout strategies.

The exact stages vary by project. CI emphasizes frequent integration and automated verification of changes, while CD automates delivery or deployment after those checks pass.

Key points

• Build early so compilation and dependency failures are caught quickly.
• Automated tests and quality checks provide evidence that a change is safe to progress.
• Package a reproducible artifact rather than rebuilding differently for each environment.
• Deployment can include approvals, health checks, smoke tests, and rollback mechanisms.
• A failed required stage should normally stop promotion to later stages.

Interview questions

What are the typical stages of a CI/CD pipeline?

A common pipeline checks out source code, builds the application, runs automated tests and quality checks, packages an artifact, and deploys it. Some pipelines also include security scanning, integration testing, approvals, and post-deployment health checks. The exact stages depend on the project and deployment model. The important idea is that later stages are gated by earlier validation.

Why should a CI/CD pipeline run tests before deployment?

Tests provide automated evidence that the change behaves as expected before it reaches a deployed environment. Running them earlier prevents known-bad code from consuming deployment resources or reaching users. Different test types can be placed at different points depending on their speed and purpose. A failed required test should normally block promotion.

What is the benefit of producing one artifact and promoting it across environments?

It reduces the chance that the artifact tested in one environment differs from the artifact deployed elsewhere. For example, a pipeline can build one JAR or container image and then deploy that same artifact to staging and production. Environment-specific settings should generally be supplied through configuration rather than by rebuilding the application. This improves reproducibility and traceability.

How would you design a CI/CD pipeline for a Java Spring Boot service?

I would start with compilation and dependency resolution using Maven or Gradle, followed by unit tests and static analysis. I would then run relevant integration tests, create the JAR or container image, and publish that immutable artifact. Deployment could move the same artifact through staging and production, with health checks and appropriate approval or rollout controls. Secrets and environment-specific configuration should be managed outside the source code.

A deployment succeeded, but the service immediately fails its health checks. What should the pipeline do?

The deployment should treat the health-check failure as an unsuccessful release rather than simply reporting that the deployment command completed. Depending on the rollout strategy, the system can stop further promotion and roll back or prevent traffic from reaching the unhealthy instances. Logs, metrics, and deployment metadata should make diagnosis possible. The exact recovery mechanism depends on the platform and whether the release is rolling, blue-green, or canary.