Deploying from CI/CD pipeline in Docker - Time & Space Complexity

Time Complexity: Deploying from CI/CD pipeline

O(n)

Understanding Time Complexity

When deploying applications using Docker in a CI/CD pipeline, it is important to understand how the deployment time changes as the project grows.

We want to know how the steps in the pipeline scale when more services or containers are added.

Scenario Under Consideration

Analyze the time complexity of the following Docker deployment snippet in a CI/CD pipeline.

# Build and push multiple Docker images
for service in service1 service2 service3; do
  docker build -t myrepo/$service:latest ./services/$service
  docker push myrepo/$service:latest
  docker service update --image myrepo/$service:latest $service
  sleep 5
 done

This script builds, pushes, and updates Docker services for each microservice in the list.

Identify Repeating Operations

Look for repeated steps that affect total time.

• Primary operation: Loop over each service to build, push, and update.
• How many times: Once per service (3 times in this example, but can grow with more services).

How Execution Grows With Input

As the number of services increases, the total deployment time grows roughly in direct proportion.

Input Size (n)	Approx. Operations
3	3 builds + 3 pushes + 3 updates
10	10 builds + 10 pushes + 10 updates
100	100 builds + 100 pushes + 100 updates

Pattern observation: Doubling the number of services roughly doubles the total deployment time.

Final Time Complexity

Time Complexity: O(n)

This means the deployment time grows linearly with the number of services being deployed.

Common Mistake

[X] Wrong: "Adding more services won't affect deployment time much because each step is fast."

[OK] Correct: Each service requires separate build, push, and update steps, so total time adds up with more services.

Interview Connect

Understanding how deployment time scales helps you design efficient pipelines and shows you can think about real-world system growth.

Self-Check

What if we ran the builds and pushes in parallel instead of sequentially? How would the time complexity change?

Practice

1. What is the main purpose of using a CI/CD pipeline when deploying Docker applications?

easy

A. To manually update Docker images on each server

B. To write Dockerfiles faster

C. To automate building, testing, and deploying Docker containers

D. To monitor server hardware performance

Solution

1. Step 1: Understand CI/CD pipeline role

   A CI/CD pipeline automates repetitive tasks like building and deploying software.

2. Step 2: Apply to Docker deployment

   For Docker apps, it automates building images, pushing them, and deploying containers.

3. Final Answer:

   To automate building, testing, and deploying Docker containers -> Option C

4. Quick Check:

   Automation = CI/CD pipeline purpose [OK]

Hint: CI/CD pipelines automate repetitive Docker deployment tasks [OK]

Common Mistakes:

• Thinking CI/CD is for manual updates
• Confusing CI/CD with monitoring tools
• Believing CI/CD only speeds up coding

2. Which of the following is the correct Docker command to push an image to a registry in a CI/CD pipeline?

easy

A. docker run myimage:latest

B. docker pull myimage:latest

C. docker build myimage:latest

D. docker push myimage:latest

Solution

1. Step 1: Identify the command to upload images

   The docker push command uploads images to a registry.

2. Step 2: Confirm correct syntax

   docker push myimage:latest correctly pushes the image tagged 'latest'.

3. Final Answer:

   docker push myimage:latest -> Option D

4. Quick Check:

   Push = upload image [OK]

Hint: Push uploads images; pull downloads images [OK]

Common Mistakes:

• Using pull instead of push to upload
• Using build or run commands to push
• Missing image tag in push command

3. Given this snippet in a CI/CD pipeline YAML file:

steps:
  - name: Build image
    run: docker build -t myapp:1.0 .
  - name: Push image
    run: docker push myapp:1.0
  - name: Deploy
    run: kubectl set image deployment/myapp myapp=myapp:1.0

What will happen after this pipeline runs successfully?

medium

A. The Kubernetes deployment will update to use the new Docker image tagged 1.0

B. The Docker image will be deleted from the registry

C. The deployment will roll back to the previous image

D. The Docker image will only be built locally without pushing

Solution

1. Step 1: Analyze build and push steps

   The pipeline builds the image tagged 'myapp:1.0' and pushes it to the registry.

2. Step 2: Analyze deployment step

   The command updates the Kubernetes deployment to use the new image 'myapp:1.0'.

3. Final Answer:

   The Kubernetes deployment will update to use the new Docker image tagged 1.0 -> Option A

4. Quick Check:

   Build + push + deploy = update deployment [OK]

Hint: Build, push, then deploy updates the app [OK]

Common Mistakes:

• Assuming image is only local, not pushed
• Thinking deployment rolls back automatically
• Confusing deployment update with image deletion

4. A CI/CD pipeline fails at the deployment step with the error: kubectl: error: no deployment found. What is the most likely cause?

medium

A. The Docker image failed to build

B. The Kubernetes deployment name is incorrect or missing

C. The Docker push command was missing

D. The pipeline YAML syntax is invalid

Solution

1. Step 1: Understand the error message

   The error says no deployment found, meaning Kubernetes cannot find the named deployment.

2. Step 2: Identify cause in deployment step

   This usually happens if the deployment name in the kubectl set image command is wrong or missing.

3. Final Answer:

   The Kubernetes deployment name is incorrect or missing -> Option B

4. Quick Check:

   No deployment found = wrong deployment name [OK]

Hint: Check deployment name spelling in kubectl command [OK]

Common Mistakes:

• Blaming build or push steps for deployment error
• Ignoring error details about deployment not found
• Assuming YAML syntax error without checking logs

5. You want to deploy a new version of your Docker app automatically only if tests pass in your CI/CD pipeline. Which sequence of steps is best to ensure this?

hard

A. Run tests -> Build Docker image -> Push image -> Deploy to production

B. Build Docker image -> Push image -> Run tests -> Deploy to production

C. Push image -> Run tests -> Build Docker image -> Deploy to production

D. Deploy to production -> Run tests -> Build Docker image -> Push image

Solution

1. Step 1: Understand the logical order for safe deployment

   Tests must run first to verify code correctness before building and deploying.

2. Step 2: Confirm correct step sequence

   After tests pass, build the Docker image, push it to the registry, then deploy to production.

3. Final Answer:

   Run tests -> Build Docker image -> Push image -> Deploy to production -> Option A

4. Quick Check:

   Tests first, then build, push, deploy [OK]

Hint: Always test before building and deploying [OK]

Common Mistakes:

• Building or pushing before tests pass
• Deploying before tests run
• Running tests after deployment