The Bigger Picture

How does Docker fit into the software development lifecycle, particularly at modern tech companies?

The Deployment Process

While no two companies have identical processes, a common Continuous Integration / Continuous Deployment (CI/CD) pipeline looks like this:

1. A developer writes new code and pushes a branch to GitHub.
2. The developer opens a Pull Request (PR) to the main branch.
3. A teammate reviews and approves the PR.
4. The developer merges the PR.
5. Upon merging, an automated script (like a GitHub Action) triggers.
6. The script builds the code.
7. The script builds a new Docker image with the latest compiled program.
8. The script pushes the new image to a registry (Docker Hub, ECR, etc.).
9. The production server (perhaps a Kubernetes cluster) is notified of the new version.
10. The cluster pulls down the latest image.
11. The cluster gracefully shuts down old containers as it spins up new containers using the latest image.

It’s Never Exactly the Same

Instead of GitHub, a company might use GitLab. Instead of Docker Hub, they might use AWS ECR. Instead of Kubernetes, they might use Docker Swarm, AWS ECS, or a simpler managed service.

However, the core concept remains the same: code is built into an immutable image, pushed to a registry, and then pulled down and run in production. This guarantees that the exact environment tested in CI is the exact environment deployed to production!