Deploying from CI/CD pipeline in Docker - Step-by-Step Execution

Process Flow - Deploying from CI/CD pipeline

Code Commit

↓

CI Pipeline Trigger

↓

Build Docker Image

↓

Run Tests

↓

Stop

↓

Deploy to Server

↓

Run Container

↓

Deployment Done

This flow shows how code changes trigger a CI/CD pipeline that builds, tests, pushes a Docker image, and deploys it by running a container.

Execution Sample

Docker

git push origin main
# CI triggers
docker build -t myapp:latest .
docker push myapp:latest
ssh deploy@server 'docker pull myapp:latest && docker run -d myapp:latest'

This code pushes changes, triggers CI to build and push a Docker image, then deploys it by pulling and running on the server.

Process Table

Step	Action	Command/Process	Result/Output
1	Code pushed to repo	git push origin main	Triggers CI pipeline start
2	Build Docker image	docker build -t myapp:latest .	Image built successfully
3	Run tests	CI test scripts	Tests pass
4	Push image to registry	docker push myapp:latest	Image uploaded to registry
5	Connect to server	ssh deploy@server	Connected to deployment server
6	Pull image on server	docker pull myapp:latest	Latest image downloaded
7	Run container	docker run -d myapp:latest	Container started in detached mode
8	Deployment complete	N/A	App running on server with new version

💡 Deployment stops after container runs successfully and app is live

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 7	Final
Docker Image	None	myapp:latest (built)	myapp:latest (pushed)	myapp:latest (pulled on server)	myapp:latest (running container)
Tests Status	Not run	Running	Passed	Passed	Passed
Deployment Status	Not started	Building	Pushing	Running container	Complete

Key Moments - 3 Insights

Why does the deployment stop if tests fail?

Because the pipeline checks test results at step 3; if tests fail, it does not push the image or deploy, preventing broken code from reaching production.

Why do we pull the image on the server after pushing it to the registry?

The server needs the latest image locally to run the updated container; pulling downloads the new image from the registry as shown in step 6.

What does running the container in detached mode mean?

Detached mode (step 7) means the container runs in the background, so the deployment process can continue without waiting for the container to stop.

Visual Quiz - 3 Questions

Look at the execution table, what is the status of tests at step 3?

A Tests pass

B Tests fail

C Tests not started

D Tests skipped

💡 Hint

Check the 'Result/Output' column for step 3 in the execution table.

At which step does the Docker image get uploaded to the registry?

A Step 2

B Step 4

C Step 6

D Step 7

💡 Hint

Look for the action 'Push image to registry' in the execution table.

If tests fail at step 3, what happens next in the pipeline?

A Image is pushed and deployed anyway

B Container runs with old image

C Pipeline stops and deployment does not continue

D Server pulls old image

💡 Hint

Refer to the key moment about test failure stopping deployment and the flow diagram.

Concept Snapshot

Deploying from CI/CD pipeline:
1. Push code triggers CI pipeline
2. Build Docker image
3. Run tests; stop if fail
4. Push image to registry
5. Deploy by pulling image on server
6. Run container in detached mode
7. Deployment complete and app live

Full Transcript

Deploying from a CI/CD pipeline means automating the process of taking code changes, building a Docker image, testing it, pushing it to a registry, and then deploying it by running a container on a server. The flow starts when code is pushed to the repository, triggering the CI pipeline. The pipeline builds the Docker image and runs tests. If tests pass, the image is pushed to a registry. Then the deployment server pulls the latest image and runs it as a container in detached mode. This process ensures that only tested and verified code is deployed, making deployment reliable and repeatable.