Analyzing Docker CI/CD Practices: Build‑Ship‑Run Trade‑offs and Source Mounting

I encountered a PHP‑based Docker CI example where the code was mounted from the host into the container, which runs quickly but deviates from Docker's "build, ship, run" philosophy; rebuilding the image for each change adds significant delay, contradicting the usual productivity gains of new technology.

Docker images are compressed archives, so even minor source changes require rebuilding the entire image, reducing productivity during frequent development; mounting the source directly into a container leverages Docker's environment consistency while avoiding costly rebuilds.

The author notes Docker's CI support is limited and proposes using Vagrant for local testing, illustrating a clever workaround (image omitted).

Extending the discussion to CD raises further questions about whether source code should reside in the image, highlighting conflicts among Docker's build, ship, and run stages.

Build: While Docker promotes embedding source in the image, traditional installers already packaged code; Docker simplifies environment setup, making source mounting viable without affecting the environment.

Ship: Images are stored in registries, but constantly changing source code may not benefit from immutable image distribution, so packaging source in the image isn’t always optimal.

Run: Deploying a new image requires stopping the old container, which can cause service interruption unless a graceful rollout strategy is used.

These modest concerns illustrate that Docker usage requires thoughtful consideration; blindly adopting Docker can cause more trouble than benefit, and the community should discuss and resolve such issues together.