A deployment pipeline turns a code change into a tested release candidate and, when configured to do so, deploys it. A CI pipeline builds and tests regularly; a CI/CD pipeline can continue through packaging and deployment. Production deployment need not be automatic: deploying continuously to pre-production can keep the latest features ready without releasing them to users. section 11.0 section 16.0
Docker gives different projects a common pipeline shape. A code change or schedule triggers the job; containers compile and test the code; the resulting Docker images are pushed to a registry. The build server needs Docker rather than every project's language SDK. A source repository, automation server, and image registry still hold the process together. section 11.1 section 11.4
A practical pipeline can be assembled in stages:
- Keep the job definition beside the application code. A Jenkinsfile or GitHub Actions YAML workflow starts the job, while reusable scripts hold most of the build logic. section 11.4 section 16.1
- Build with a multi-stage Dockerfile and run unit tests during the build. Stop the job when a test fails; use Docker Compose to start the whole application for end-to-end or smoke tests. section 11.1 section 16.5
- Package and push tested images to a registry. For a production-oriented pipeline, consider vulnerability checks and image signing before deployment. section 11.1 section 11.5
Run the same build locally and in CI
Put `docker compose -f docker-compose.yml -f docker-compose-build.yml build --pull` in a build script, then call that script from a Jenkinsfile. The `--pull` flag checks for newer base images, including security fixes; it can also reveal a base-image change that breaks the application. Jenkins captures the Docker output in its build logs. section 11.4
Listing 11.5 Jenkinsfile build step that describes the CI job
# the build stage in the Jenkinsfile- it switches directory, then runs two
# shell commands - the first sets up a script file so it can be executed
# and the second calls the script:
stage('Build') {
steps {
dir('ch11/exercises') {
sh 'chmod +x ./ci/01-build.bat'
sh './ci/01-build.bat'
}
}
}
# and this is what's in 01-build.bat script:
docker compose
-f docker-compose.yml
-f docker-compose-build.yml
build --pull
The Jenkinsfile stage and its script show how a CI job delegates the build to an ordinary Docker Compose command. section 11.4
Keep scripts runnable by developers as well as the CI service so a failing build can be reproduced locally. In GitHub Actions, a push starts a fresh runner that checks out the repository and runs the workflow; the runner is removed afterward. Private repositories and packages need additional authentication configuration. A single workflow can make job dependencies easier to see, but separate stages may be easier to run independently. section 16.1 section 16.5
