CI/CD

CI/CD connects source code changes to a repeatable process for building, testing, and releasing software. Continuous integration, or CI, means developers frequently merge small changes into a shared codebase and receive automated feedback. A successful integration typically requires the application to build and its automated checks to pass. Simply running a scheduled build does not establish effective CI if developers keep incompatible changes isolated for long periods.

The CD portion has two related meanings. Continuous delivery keeps validated changes ready for production deployment, but a person or business process can still approve the production release. Continuous deployment automatically deploys changes to production after they pass the required checks, without a separate manual production approval. Exam questions often test this distinction: an approval gate is compatible with continuous delivery, but not with fully automated continuous deployment.

A cloud pipeline commonly starts when a developer pushes a change to a source repository. An execution environment retrieves the source, installs dependencies, compiles or packages the application, and runs tests. The resulting artifact might be an application archive or container image. Later stages deploy that artifact to a test environment, run additional checks, and promote the same artifact toward production. Reusing an immutable artifact avoids rebuilding different binaries for each environment; environment-specific configuration should be supplied separately.

For example, a team updating an online checkout API could run unit tests and dependency checks on every proposed change. After merging, the pipeline packages the API, deploys it to staging, and runs integration tests against a test database. A production approval can then authorize deployment. A canary release can expose a small portion of traffic to the new version while monitoring errors and latency before expanding deployment.

Cloud services provide distinct capabilities within this workflow. Pipeline orchestration coordinates stages and approvals; build services execute compilation and tests; deployment services update application targets. Infrastructure as code can provision the networks, permissions, and runtime resources required by the application. Logs, metrics, alarms, and distributed traces help engineers investigate failed builds, deployment failures, and application behavior after release. An orchestrator is not necessarily the service that compiles code or hosts the running application.

Automation introduces trade-offs. Teams must maintain pipeline definitions, reliable tests, build environments, and deployment permissions. Frequent executions consume resources, and slow or flaky tests can undermine confidence. Pipeline identities should use least-privilege permissions, secrets should come from controlled secret storage, and untrusted code should not receive production credentials. Approval requirements and separation between environments can provide additional safeguards.

CI/CD does not guarantee defect-free software, require a particular cloud provider, or mean every commit must reach production. Deployment rollback also requires planning: restoring an earlier application version might not reverse an incompatible database migration. Effective implementations combine automated validation, compatible changes, observable deployments, and a tested recovery strategy rather than treating a successful pipeline execution as proof that a release is safe.