4.2CI/CD and containers

What DevNet asks is not the definition of "what CI/CD is" but whether you can read what the pipeline or Dockerfile in front of you guarantees and where it is flawed. A pipeline that deploys without passing tests mass-produces incidents, a Dockerfile that ignores caching needlessly slows builds, and an image missing CMD will not start. This section covers CI/CD stages, Python unit tests, and each Dockerfile instruction from the viewpoint of reading and diagnosing a presented artifact.

4.2.1The CI/CD pipeline

• CI (continuous integration) integrates developers' changes into a shared branch frequently, running an automated build and test each time to catch breakage early. CD (continuous delivery/deployment) advances an artifact that passed tests all the way to automatic release/production. In short, it makes build -> test -> deploy repeatable without human hands.
• The heart of a pipeline is a gate: do not advance if tests fail. It is correct design that if the test stage is red, deploy does not run; a pipeline that skips tests and pushes to production is an automated incident. The earlier and smaller the failure is caught, the cheaper the fix.

4.2.2Python unit tests

• Unit tests automatically verify the behavior of the smallest units—functions and methods—by their expected output for an input. In Python you use the standard unittest (assertions like assertEqual) or pytest (assert statements and concise syntax). CI mostly runs these unit tests to guard that a change has not broken existing behavior.
• A good test checks one behavior in one case and, on failure, makes it clear what broke and why. If assertEqual(add(2, 3), 5) fails, a regression in add is obvious at a glance. Passing tests is CI's pass condition, and the practical crux is that code without tests gets no protection from CI.

4.2.3Dockerfile, image, and container

• A Dockerfile is text describing how to build an image. Key instructions: FROM (base image), RUN (run a command at build time, e.g., install dependencies), COPY (bring files into the image), EXPOSE (declare the listening port), CMD (the default command run when the container starts). docker build -t myapp . builds an image (an immutable template), and docker run myapp starts a container (a running instance) from that image.
• A build caches layers per instruction. Putting the COPY of frequently-changing app code later and the rarely-changing dependency install (COPY requirements.txt -> RUN pip install) earlier avoids reinstalling dependencies on every code change and speeds builds. Reversing the order invalidates the cache every time and slows it. Also mind the timing difference between RUN (build time) and CMD (start time).

Review the following Dockerfile: after FROM python:3.12-slim it has COPY . /app (copy the whole project), then RUN pip install -r /app/requirements.txt, and finally CMD ["python", "/app/main.py"]. It works, but a complaint arrives that every build is slow. The problem is placing COPY . /app before the dependency install. Editing even one line of source changes the COPY . layer, invalidating the cache, so the subsequent pip install starts over every time. The fix is to first COPY requirements.txt /app/ alone, run RUN pip install -r /app/requirements.txt, and only then COPY . /app for the app body—this way the pip install layer stays cached unless dependencies change, and builds after code edits become dramatically faster. Next, another team reports "it shipped to production even though tests were failing." Looking at the pipeline, the deploy job was configured to run in parallel, independent of the test job's outcome. Since the essence of CI/CD is that tests are the gate, fix it so deploy depends on test success and halts on red (do not let it be overridden by hand). The lesson: for both CI/CD and Dockerfiles, the question is not merely "does it run" but reading from the artifact what it guarantees and where it hurts speed or safety. It is not a vocabulary question about what FROM or CI means; the real skill is diagnosing and fixing this artifact's defects.

4.2.4Section summary

• CI/CD automates build -> test -> deploy and makes tests the gate (do not deploy when test is red)
• Python unit tests (unittest/pytest) guard the smallest units by expected output and are CI's pass condition
• Dockerfile (FROM/RUN/COPY/EXPOSE/CMD) -> build makes an image -> run makes a container; put rarely-changing deps earlier and the code COPY later to use the cache