Docker and CI/CD Explained Through One Application
Connect reproducible environments, automated checks and controlled releases.
Part of the DevOps track: modules, projects and first roles →
By the GullyMentor team · 5 min read · Published 2026-10-18 · Updated 2026-11-06 · Sources listed at the end. Not a promise about mentorship outcomes.
Docker packages an application and its runtime so it runs the same way on different machines. Continuous integration, or CI, runs automated checks whenever code changes. Continuous delivery then prepares or releases the checked build. They solve different problems, and one small application is enough to see how they connect.
How do I start?
1. Write a small web application with one route that returns a greeting, plus one test that checks the response text. Keep the dependency list short and write the start command in the README.
2. Add a container definition that installs the dependencies and starts the app. Build it with docker build, giving the image a version tag, and run it with docker run, mapping a port so you can open it in a browser.
3. Add a pipeline file for your hosting platform. On GitHub Actions this is a YAML file under .github/workflows. Trigger it when a pull request is opened, and have it install dependencies and run the test.
4. Only after those work, add the release step that builds the image and publishes it somewhere you control.
What does each stage prove?
| Stage | Question it answers | Evidence you keep |
|---|---|---|
| Test in CI | Does this change still behave correctly? | A passing and a failing run |
| Image build | Can the app be packaged repeatably? | A tagged image |
| Deploy | Is that exact artifact running somewhere? | The version shown by a health check |
| Rollback | Can I return to the last good version? | A recorded recovery |
Notice that a green test does not prove the deploy worked, and a deploy does not prove the test was meaningful. Each stage has its own evidence.
Start with a small app
Use a simple application that returns a greeting and has a test for the expected response. Document its dependencies and startup command.
A container image describes the packaged environment; a container is a running instance. Configuration and secrets should be supplied through appropriate runtime mechanisms, not baked into a public image.
Build a meaningful CI check
When a change is proposed, the pipeline installs dependencies and runs the test. Change the greeting so the test fails. Confirm that the failed check prevents the next release step.
A pipeline that only prints “success” does not verify the application. The test must exercise behaviour that matters.
Separate build from release
After checks pass, produce an identifiable artifact. Deploy that artifact to a disposable environment and record its version. Avoid rebuilding an untracked variant at release time.
An approval can remain between successful CI and deployment. Automatic production publishing is not required to practise the concepts.
Observe and recover
Run a health check after deployment. Then deliberately release a broken version in your own test environment and practise restoring the previous one.
Document what rollback does and does not reverse. Persistent data and external actions may require separate recovery steps.
Practice deliverables
Include the application, test, container definition, pipeline and runbook. Show one successful run and one failed run. Keep logs free of credentials and remove unused resources.
The common mistake is treating Docker as the whole of DevOps or treating a green CI badge as proof of production reliability. The value comes from a controlled process whose checks, permissions and recovery you can explain.
What are the common mistakes?
- Baking passwords or tokens into the image, which anyone with the image can read.
- Using the tag
latestfor everything, so you cannot say which version is running. Tag with a version number or the commit identifier. - Writing a test that cannot fail, then trusting the green badge.
- Rebuilding at release time instead of releasing the artifact that passed the checks.
- Never practising a rollback until something breaks.
How do I check I got it?
Make the test fail on purpose and confirm the pipeline stops before the release step. Release version 1.0, then 1.1 with a deliberate bug, and restore 1.0. Finally, explain to someone else which part of the process Docker handles and which part CI handles. If you can point to the log line that shows each one, you understand the split.
What should I build next?
Try the three delivery exercises in DevOps project ideas for freshers, or step back to the DevOps roadmap to see what to learn after containers. The DevOps track describes the guided path.
Sources & further reading
Examples and practice recommendations are educational illustrations. Tool documentation and programme inclusions should be checked for your intended use.