Continuous Delivery (CD)

Importance of Continuous Delivery

Continuous Delivery (CD) is an engineering practice where code changes are automatically built,
tested, and prepared for release to production. It's a key part of DevOps philosophy.

• Core Insight: CD isn't just about speed; it's about reducing risk and building quality into the
process. By ensuring that the codebase is always in a releasable state, organizations can deploy
software changes at any time, on demand, with high confidence.

• Key Benefits:

o Faster Time-to-Market: Quickly release new features and bug fixes.

o Lower Risk Deployments: Frequent, small changes are less risky to deploy than
infrequent, large ones.

o Better Product Quality: Automated and exhaustive testing in the pipeline catches
issues early.

o Improved Feedback Loop: Developers get rapid feedback on their changes, leading to
faster iteration.

o Customer Satisfaction: Delivering value to users more frequently and reliably.

CONTINUOUS DEPLOYMENT (CD) Flow

Continuous Deployment is the next step after Continuous Delivery. It means every change that passes
the automated pipeline is automatically released to production without explicit human approval
(unless a final deployment gate is needed for business reasons).

• The Flow (CI/CD Pipeline):

1. Commit/Code: Developer commits code to the version control system (e.g., Git).

2. Continuous Integration (CI):

▪ Build: The code is compiled and packaged.

▪ Unit Tests: Automated unit tests are run.

▪ Static Analysis: Code quality and security checks are performed.

3. Continuous Delivery/Deployment (CD):

▪ Artifact Creation: A deployable artifact (like a Docker image) is created and

stored.

▪ Integration/Acceptance Tests: Automated tests (e.g., functional, UI,

performance) are run against a staging/test environment.

▪ Deployment to Staging/Pre-production: The application is deployed to an

environment that mirrors production.

▪ Manual/Exploratory Testing (Delivery): Optional human approval or final

exploratory testing (in Continuous Delivery).
 ▪ Deployment to Production (Deployment): The artifact is automatically or
manually promoted and deployed to the production environment.

▪ Monitoring & Feedback: Production is monitored for issues, and feedback

loops inform the development team.

Containerization with Docker

Introduction to Docker

Docker is a platform for developing, shipping, and running applications using containerization. A
container is a lightweight, portable, and self-sufficient executable package that includes everything
needed to run a piece of software, including the code, runtime, libraries, environment variables, and
config files.

• Core Insight: Docker solves the "it works on my machine" problem. By packaging the
application and its environment together, it guarantees consistency across development,
testing, staging, and production environments. It abstracts the operating system differences,
providing isolation.

Docker Installation and Commands

• Installation: Involves downloading and running Docker Desktop (for Windows/macOS) or

installing the Docker Engine (for Linux servers). This includes the Docker Daemon (server) and
the Docker CLI (client).

• Key Commands (Deep Dive):

o docker **pull** <image>: Fetches an image from a registry (like Docker Hub).

o docker **build** -t <tag> .: Builds a Docker image from a Dockerfile in the current
directory.

o docker **run** <image>: Creates and starts a container from an image. Often
combined with flags like -d (detached mode), -p (port mapping), and --name.

o docker **ps**: Lists running containers. docker ps -a lists all containers (running and
stopped).

o docker **exec** -it <container> <command>: Runs a command inside a running

container (e.g., docker exec -it my-app bash to open a shell).

o docker **stop/start/rm** <container>: Manages container lifecycle. docker system

prune cleans up unused resources.

Images & Containers

• Images: Read-only templates built from a Dockerfile. They are the blueprints for containers,
composed of layered filesystems that are highly efficient for sharing and storing. Images are
static.

• Containers: Runnable instances of an Image. They run the specified application and
environment in an isolated space. Containers are dynamic; they have a read/write layer on top
of the image layers, meaning changes made inside a running container are unique to that
 instance (until it's stopped/removed). The application runs inside the container's isolated
process.

Docker File

The Dockerfile is a text file containing instructions for Docker to build an Image. Each instruction
creates a new layer in the image, promoting immutability and efficiency.

• Key Instructions:

o FROM <base_image>: Specifies the starting image (e.g., node:18-alpine).

o WORKDIR <path>: Sets the working directory inside the container.

o COPY <source> <dest>: Copies files from the local machine into the image.

o RUN <command>: Executes a command during the image build process (e.g., installing
dependencies).

o EXPOSE <port>: Documents which ports the application inside the container listens on
(doesn't publish them).

o CMD <command>: Provides the default command/entrypoint for a running container

instance.

Running and Working with Containers

• Running Containers: Use docker run. Port mapping (-p 8080:80) is crucial to access the service,
as containers run in network isolation. The application runs as the main process within the
container.

• Working with Containers: This involves using docker logs to view output, docker exec to debug
or run one-off commands inside the container, and docker inspect to view detailed container
configuration (IP address, volumes, etc.).

Publish to Docker Hub

Docker Hub is the world's largest public registry for Docker images.

• Process:

1. Tagging: Tag the local image with your Docker Hub username and repository name:
docker tag <local_image> <username>/<repo>:<tag>.

2. Login: Authenticate with Docker Hub using docker login.

3. Pushing: Upload the image to the registry: docker push <username>/<repo>:<tag>.

• Core Insight: Publishing to a registry allows the image (the application artifact) to be consumed
consistently by other parts of the CI/CD pipeline, staging environments, and production
orchestration tools (like Kubernetes).
Testing Tools
Introduction to Selenium and its features

Selenium is a portable framework for automated testing of web applications. It is primarily used for
end-to-end (E2E) and User Interface (UI) testing by simulating user interactions with a browser.

• Core Insight: Selenium enables browser automation. It directly controls the web browser
(Chrome, Firefox, etc.) as a real user would, allowing testers to validate functionality,
appearance, and performance across different browsers and operating systems.

• Key Features:

o Cross-Browser and Cross-Platform Support: Runs tests seamlessly on multiple

browsers (via WebDriver) and OSs (Windows, Linux, macOS).

o Language Bindings: Supports test script development in multiple languages (Java,

Python, C#, Ruby, JavaScript, etc.).

o Selenium WebDriver: The modern core of Selenium, which communicates directly

with the browser's native automation support, offering better control and
performance than older versions.

o Selenium Grid: Allows for the parallel execution of tests across multiple machines and
browser versions, significantly reducing test run time, a critical feature for fast CI/CD
pipelines (often deployed using Docker).

o Open Source: Free to use and backed by a large community.

JavaScript Testing

JavaScript testing generally falls into three categories: Unit, Integration, and End-to-End (E2E) testing.
The ecosystem is rich with specific tools tailored for each level.

• Unit Testing (Focus on small, isolated functions):

o Tools: Jest (popular for React, generally a fast all-in-one runner), Mocha (flexible,
extensible framework), Jasmine (behavior-driven development framework).

o Insight: Unit tests provide the fastest feedback loop and ensure individual
components work correctly in isolation.

• Integration Testing (Focus on how components work together):

o Tools: Often uses the same frameworks as unit testing (Jest/Mocha) but with more
complex setup, simulating service interactions (e.g., API calls).

o Insight: Confirms that interfaces between parts of the system are correct, catching
issues that individual unit tests might miss.

• E2E Testing (Focus on full user flow in a real browser):

o Tools: Selenium, Cypress (developer-friendly, faster setup), Playwright (from

Microsoft, strong multi-browser support).
 o Insight: These tests are the most realistic but also the slowest and most fragile. They
are crucial to ensure the final product meets user requirements.

The integration of Docker with Selenium (running tests in consistent, isolated, and parallelized
containers) is a powerful pattern for reliable Continuous Deployment.

Deep Insight: Importance of Continuous Delivery (CD)

1. Risk Mitigation via Small Batches

The primary goal of CD is to ensure the software is always in a releasable state. It achieves this by
forcing teams to work in small batches.

• Traditional Approach: Teams integrate code infrequently, leading to massive "big bang"
releases with hundreds of changes. When a bug occurs in production, it's nearly impossible to
isolate which of those hundreds of changes caused it, leading to prolonged downtime and
frantic debugging.

• CD Approach: Code is integrated and run through the pipeline multiple times a day. Each
deployment artifact contains only a few changes. If a production incident occurs, the cause is
immediately narrowed down to the handful of changes in that single, recent deployment. This
drastically reduces the "blast radius" of any failure.

2. Accelerated Feedback Loop and Business Agility

CD is the engine that drives an agile business. It ensures the time from a business idea to a customer
seeing that feature is measured in hours or days, not months.

• Insight: Getting new features to customers quickly means learning quickly. If a feature is
unpopular or has a usability flaw, the business learns this in days, not after spending months
developing an unwanted product. This enables teams to "fail fast" and iterate rapidly based
on real user feedback.

• Business Impact: This ability to pivot or double-down on features provides a significant

competitive advantage.

3. Culture of Quality and Trust

By automating the build, testing (unit, integration, and UI), and deployment steps, CD creates an
objective, repeatable process that removes human error from the pipeline.

• Insight: Developers get immediate, comprehensive feedback on their changes. If a change

breaks a test, the pipeline stops instantly. This accountability fosters a "build quality in"
mentality, where everyone trusts the automated system and is motivated to maintain the
quality of the test suite.
Example: A Traditional E-Commerce Company vs. A CD-Enabled Startup

Traditional Company (Monthly

Feature CD-Enabled Startup (Daily Releases)
Release)

Release Once per month (200+ code

Multiple times per day (2-5 code changes)
Frequency changes)

Deployment 6 hours (manual checklist,

15 minutes (fully automated pipeline)
Time overnight release)

High. If the release fails, the site is Low. If a deployment fails, only a tiny change is
down for hours, requiring a costly, the culprit, which can be fixed and deployed in
Risk of Failure
manual rollback of the entire minutes (roll-forward) or automatically reverted
complex batch of changes. (roll-back) with a single command.

Time to A feature completed on day 1 is A feature completed this morning is available to

Market available to users on day 30. users this afternoon.

A bug found in production requires A fix is committed, passes the automated

Fixing a
weeks of planning to fit into the pipeline, and is deployed to production in under
Critical Bug
next monthly release cycle. an hour.

Export to Sheets

Conclusion

For the CD-Enabled Startup, releases are no longer a stressful, all-hands-on-deck event. They are a
trivial consequence of development. This allows the team to focus 99% of their energy on innovation
and delivering value, rather than on the mechanics and trauma of deployment. This is the ultimate
importance of Continuous Delivery.

The Continuous Deployment (CD) Flow Pipeline

Continuous Deployment is a pipeline that is Continuous Delivery with one crucial step removed: the
final manual gate. The success of this fully automated flow relies on an obsessively rigorous
automated testing and monitoring strategy.

The typical CD flow follows these automated stages:

1. Source/Commit (CI Start):

o A developer commits code to the Version Control System (VCS), like Git, triggering the
pipeline.

2. Build (CI):

o The code is compiled into a single, immutable artifact (e.g., a Docker image, JAR file,
or executable).

3. Test (CI):
 o Unit Tests, Integration Tests, and Static Analysis run rapidly. Any failure immediately
stops the pipeline and notifies the developer.

4. Staging Deploy & Test (CD Stage 1):

o The validated artifact is automatically deployed to a Staging Environment (a replica

of production).

o More comprehensive tests run: End-to-End (E2E) Tests, Performance/Load Tests, and
Security Scans (DAST).

5. Release (CD Stage 2 - The Key Difference):

o In Continuous Deployment, the Staging Test success automatically triggers the

deployment to the Production Environment. There is no manual approval step here.

o The deployment often uses low-risk techniques like Blue/Green deployment or

Canary Releases to minimize impact.

6. Verify & Monitor (Post-Deployment):

o The system performs smoke tests on the live production environment.

o Real-time monitoring and alerting tools (Observability) track key metrics (error rates,
latency) and will automatically trigger an automated rollback if a predefined alert
threshold is breached.

Example: Deploying a "Dark Mode" Feature

Imagine an e-commerce company that uses a Continuous Deployment pipeline.

Pipeline
Action Triggered by Pipeline Insight on Automation
Stage

A developer pushes a small code change to Starts the flow. The system knows a
Commit
Git for a new "Dark Mode" CSS file. change exists.

The system builds the new container image Builds Trust. The change is proven
Build/Test and runs 10,000 automated Unit/Integration compatible with the existing 100% of the
tests. codebase in minutes.

Proves Deployability. We confirm the

Staging The new container image is automatically
infrastructure-as-code and deployment
Deploy deployed to the Staging Environment.
script work reliably.

Simulates User Experience. We ensure

Automated E2E tests check the "Dark Mode"
E2E/Load the end-to-end user journey and
toggle on all browsers. Load tests ensure the
Test performance are flawless before the
new CSS doesn't slow down the site.
customer sees it.
Pipeline
Action Triggered by Pipeline Insight on Automation
Stage

AUTOMATIC DEPLOYMENT to production The Zero-Friction Point. No human clicks

Production (using a Canary Release). The new Dark "deploy." The successful test is the
Deploy Mode is enabled for only 1% of users via a permission. The Canary limits the
feature flag. impact.

The Automated Safety Net. If the 1% fail,

Observability tools watch the 1% of Canary
the system automatically rolls back to
Monitoring users for a spike in HTTP 500 errors or a drop
the previous stable version within
in conversion rates.
minutes.

The Core CD Insight

The most significant aspect of Continuous Deployment is the fundamental culture shift it represents:

It replaces the philosophy of "Release slowly to avoid failure" with "Test thoroughly and fail fast to
recover instantly."

This is why major tech companies often deploy hundreds of times a day. Their confidence is placed
entirely in the automated test and monitoring suite, allowing them to prioritize speed and
instantaneous customer feedback above the historical need for manual sign-offs.

Containerization with Docker

The profound insight into Containerization with Docker is that it solves the problem of "It works on
my machine!" by fundamentally shifting the unit of software delivery from an artifact (like a JAR or
WAR file) to an entire, self-contained environment (the Docker Image).

Docker doesn't just package your code; it packages the entire operating system and environment
necessary to run your code, ensuring consistency and portability across development, testing, and
production.

Introduction to Docker: Deep Insight

1. The Core Problem Solved: Environmental Drift

Before Docker, deploying an application involved installing the application's code, plus its specific
dependencies (e.g., Python 3.8, a certain version of PostgreSQL client library, specific operating system
patches, etc.) onto a server. This led to environmental drift, where minor differences between the
developer's machine, the staging server, and the production server would cause bugs.

• The Docker Solution: Docker uses a concept called Containerization. A Docker container is a
lightweight, executable package that includes everything needed to run a piece of software:
the code, runtime, system tools, system libraries, and settings. This package is called a Docker
Image.

• The Insight: Since the environment inside the image is identical everywhere, the deployment
becomes predictable. If it works in the container on the developer's laptop, it will work exactly
the same way in the container on the production server.
2. Efficiency and Resource Management

Docker containers share the host operating system's kernel, making them much lighter and faster than
traditional Virtual Machines (VMs).

• VM: Each VM requires its own full copy of an operating system (OS), including the kernel,
making it heavy, slow to boot, and resource-intensive.

• Container: Containers abstract at the OS level (user space). They share the host OS kernel,
making them incredibly lightweight. A container can start in milliseconds and uses far less
memory. This allows a single server to run significantly more isolated applications.

3. Portability and Speed

The Docker Image becomes the single source of truth for the application and its environment.

• This single artifact can be moved seamlessly from a local development machine to a cloud
VM, a Kubernetes cluster, or an on-premise data center without changes. This dramatically
simplifies the Continuous Delivery (CD) pipeline.

Illustrative Example: A Python Web Application

Component Traditional Deployment (VM) Containerization (Docker)

A zipped Python project file and a document A single Docker Image (e.g., my-
Artifact
with manual installation steps. app:v1.0).

An engineer must spend 2 hours installing

Python, specific libraries (e.g., pandas, flask), The engineer runs docker run my-
Setup Time
configuring OS firewall rules, and setting app:v1.0. Setup is seconds.
environment variables.

Low. The production VM might have a different High. The container bundles all
Consistency version of a system library than the developer's dependencies, ensuring the exact same
machine, causing a subtle bug. environment runs everywhere.

Scaling means provisioning a new, full VM Scaling means telling a container

Scalability (several minutes) and manually running the orchestrator (like Kubernetes) to start
setup script again. 10 more identical containers (seconds).

In essence: Docker turns infrastructure dependency headaches into a single, executable file, allowing
developers to focus on writing code, not configuring environments.

Docker Installation & Core Insight

The installation process sets up the Docker Engine, which is comprised of the Docker Daemon (the
persistent background service) and the Docker Client (the CLI you interact with).
The core insight is that every Docker command you run is the Docker Client sending an instruction
via an API to the Docker Daemon. You are not directly managing low-level OS resources; you are telling
the smart, powerful Daemon what you want it to build, run, or clean up.

Key Installation Component: The Docker Daemon

• Role: The Daemon is the "brain" of Docker. It is responsible for building images, running
containers, managing storage volumes, and controlling the network.

• Insight: When you install Docker, you are essentially installing a standardized control plane on
your machine. This abstraction is what allows your Docker commands to work identically
whether you are on Windows, macOS, or a Linux server.

Essential Docker Commands: Deep Dive and Example

The fundamental workflow with Docker revolves around three major command categories: Images,
Containers, and Cleanup.

1. Images: The Blueprint Commands

Images are the immutable, read-only blueprints that package your application and its entire
environment.

Command Action Insight

docker **pull** Downloads an image from a The first step to reproducibility—you pull
[image_name] registry (like Docker Hub). a defined, tagged version.

Creates an image from a

docker **build** -t The key to consistency—you codify your
Dockerfile (your explicit
myapp:latest . entire environment setup into a file.
instruction set).

Helps manage the "inventory" of all your

docker **images** Lists all local images.
application environments.

Export to Sheets

Example: Building an Image

You have a simple web app and a file named Dockerfile in your current directory:

# This command reads the Dockerfile in the current directory (represented by .)

# and names the resulting image 'web-app' with the tag 'v1'.

docker build -t web-app:v1 .

2. Containers: The Runtime Commands

Containers are the live, running instances of an image. They are the isolated, ephemeral environments
where your application executes.
Command Action Insight

Creates and starts a container from The moment the blueprint comes to
docker **run** -d -p
an image, detaching (-d) it and life. Port mapping is critical for
8080:80 [image_name]
mapping ports (-p). accessing the isolated app.

Lists all currently running Shows the live state of your isolated
docker **ps**
containers. application environments.

docker **exec** -it The method for debugging and

Runs a command inside a running
[container_id] inspection without affecting the host
container (like opening a shell).
/bin/bash machine.

Retrieves the standard Provides immediate feedback and

docker **logs**
output/error of the running observability of the application's
[container_id]
container. internal activity.

Example: Running and Inspecting a Container

1. Run the container: Start your image, map the container's internal port 80 to your host's port
8080, and run it in the background (-d).

Bash

docker run -d --name my-web-app -p 8080:80 web-app:v1

2. Verify it's running: See the live container.

Bash

docker ps

# Output shows my-web-app is running and its ID.

3. Inspect the environment: Access the running container's shell to check files or configurations.

docker exec -it my-web-app sh

# You are now inside the isolated container.

3. Cleanup: The Housekeeping Commands

Proper containerization involves a lot of temporary assets, so cleaning up is essential to prevent clutter
and save disk space.

Command Action Insight

docker **stop** Allows the application inside to shut

Gracefully stops a running container.
[container_id] down cleanly.

docker **rm** Removes the live, isolated

Removes a stopped container.
[container_id] environment.
Command Action Insight

docker **rmi**
Removes a local image. Removes the local blueprint.
[image_name]

Removes all stopped containers, The ultimate efficiency tool,

docker **system
unused networks, and dangling reclaiming vast amounts of disk
prune**
images. space.

Export to Sheets

Example: Cleanup

To stop and remove the container from the previous example:

docker stop my-web-app

docker rm my-web-app

Images and Containers

The deepest insight into Images and Containers is that they represent the fundamental separation of
the application blueprint (the Image) from its running state (the Container). This dichotomy is what
enables Docker's core promise: consistency, immutability, and efficient resource isolation.

Think of it like this:

• The Image is the class in object-oriented programming (OOP)—a static, read-only definition.

• The Container is the object (or instance)—a dynamic, running realization of that definition.

1. Docker Images: The Immutable Blueprint

A Docker Image is a lightweight, standalone, executable package of software that includes everything
needed to run an application: code, runtime, libraries, environment variables, and config files.

Deep Insights:

• Layered File System (The Key to Efficiency): Images are built using a Union File System (UFS),
meaning they are composed of a stack of read-only layers. Each command in a Dockerfile (e.g.,
RUN, COPY) creates a new layer.

o Insight: If you have 10 applications based on the same Ubuntu base image, that base
layer is stored only once on your system. This drastically reduces storage space and
speeds up image distribution, as only the new, unique layers need to be downloaded
or copied.

• Immutability and Trust: Once an image is built, it never changes. If you need to fix a bug, you
don't modify the existing image; you build a new image with a new tag (e.g., app:v1.1).

o Insight: This guarantees that the image tested in QA is the exact same binary artifact
deployed to production, eliminating configuration errors and environmental drift.
 • Portability: An image is designed to run the same way on any operating system that has the
Docker Engine installed.

o Insight: This makes the image the universal unit of software delivery in the cloud-
native world.

2. Docker Containers: The Running Instance

A Docker Container is a runtime instance of a Docker Image. It is a live process running in an isolated
environment on a host machine.

Deep Insights:

• The Read/Write Layer (The Key to Isolation): When a container starts from an immutable
image, Docker adds a single, thin read/write layer on top of the image's read-only layers.

o Insight: Any changes made while the container is running (e.g., creating a file, writing
a log) happen only in this top read/write layer. The original image remains untouched.
When the container is deleted, this ephemeral layer is destroyed, ensuring a clean
slate for the next container started from the same image. This is why containers are
considered ephemeral.

• Resource Isolation (via Linux Kernel Features): Containers achieve isolation using two
fundamental Linux kernel features:

o Namespaces: Provide the container with its own isolated view of the system (its own
process ID space, network interface, hostname, etc.).

o cgroups (Control Groups): Limit the amount of resources (CPU, memory, disk I/O) the
container can consume.

o Insight: This is the core difference from Virtual Machines (VMs). Containers are simply
isolated processes running on the host OS kernel, making them much lighter and
faster than full VMs.

• Process-Centric: A container is typically designed to run a single main process (e.g., a web
server). When that main process exits, the container stops.

o Insight: This promotes the microservices architecture philosophy of single

responsibility and encourages treating infrastructure as cattle, not pets—easily
started, stopped, and replaced.

Example: Deploying a Web Server

Concept Image (httpd:2.4) Container (Instance of httpd:2.4)

State Static (Blueprint) Dynamic (Running)

Action Built or Pulled from Docker Hub Started (docker run) and Stopped (docker stop)
Concept Image (httpd:2.4) Container (Instance of httpd:2.4)

File System Read-Only Layer Stack Read-Write Layer on Top

Ephemeral (Data is lost when deleted, unless

Persistence Permanent (Until manually removed)
using a Volume)

The Apache HTTP Server code and A live, isolated Apache server responding to
Example
configuration files. requests on port 80.

In summary: The Docker Image provides the assurance that your application's environment is defined
and immutable. The Docker Container provides the isolation and ephemeral execution of that assured
environment. This duality of static blueprint (Image) and dynamic instance (Container) is the
foundation of modern, scalable application deployment.

The deeper insight into Dockerfile, running containers, working with containers, and publishing to
Docker Hub is that they collectively form the complete DevOps lifecycle for a single microservice. This
workflow establishes a repeatable, automated path that transforms simple application code into a
highly portable, shareable, and runnable artifact.

This process is about codifying everything an application needs, from its build instructions to its
distribution method.

1. Dockerfile: The Infrastructure as Code Blueprint

The Dockerfile is the core of Docker's philosophy, representing Infrastructure as Code (IaC) at the
application level. It is a plain text file that contains a sequence of instructions used to automatically
build a Docker Image.

Deep Insight: Layer Caching and Efficiency

The most critical insight is how the Docker build process uses layer caching based on the immutable,
ordered instructions in the Dockerfile.

• Instruction: Each command in a Dockerfile (like FROM, RUN, COPY) creates a new, read-only
layer.

• Caching: Docker checks if the instruction and its context have changed since the last build. If
they haven't, it uses the cached layer, dramatically speeding up subsequent builds.

• Optimization Strategy: To maximize this caching, slow-changing instructions (like the base OS
and system dependencies) should be placed before frequently changing instructions (like the
application code).
Dockerfile Instruction Purpose Insight on Efficiency

Sets the base operating

FROM ubuntu:22.04 Slowest changing layer; always first.
system.

RUN apt-get update && Placed high to benefit from cache reuse across
Installs base dependencies.
apt-get install python3 code changes.

Placed after dependency installs, ensuring a

Copies your application
COPY . /app code change only invalidates this final layer,
code into the image.
not the installation layers above it.

Defines the command to

CMD ["python3",
run when the container Defines the container's single main process.
"/app/[Link]"]
starts.

2. Running & Working with Containers: Isolation and Debugging

Running a container (docker run) transforms the static Image into a live, isolated environment. Working
with containers involves managing their interaction with the host system and the outside world.

Deep Insight: Network and Storage Separation

The primary power of the running container is its isolation from the host system.

• Networking Isolation: By default, containers are isolated. You must explicitly map a port using
the -p flag (e.g., -p 8080:80) to expose the container's internal services to the outside world.

o Insight: This means a container running a web server on port 80 won't conflict with
another application on the host using the same port 80, unless you map them
incorrectly.

• Storage Isolation (The Read/Write Layer): As noted, all runtime changes are ephemeral. To
make data persistent (e.g., database files, log files), you must use a Docker Volume with the -
v flag.

o Insight: Using a volume (-v /host/data:/container/data) breaks the container's

isolation for that specific directory, linking it to the host file system. This is the
exception to ephemerality, used for essential state management.

Command Deep Insight on Isolation

docker run -p 8080:80

Explicitly punches a hole in the network isolation barrier for a service.
[image]

docker exec -it Allows you to temporarily break into the isolated process's environment for
[container_id] sh real-time debugging and inspection.
Command Deep Insight on Isolation

Accesses the container's standard output stream, respecting the principle that
docker logs
containers should write logs to stdout/stderr for the Docker Daemon to
[container_id]
collect.

3. Publishing to Docker Hub: Standardization and Distribution

Docker Hub (or any container registry) serves as the centralized repository for storing and distributing
your Docker Images.

Deep Insight: Tagging as Version Control

Publishing an image requires tagging, which is more than just a name—it's the version control
mechanism for your entire codified environment.

• The Tagging Rule: Before pushing, you must tag the image with the registry path: docker tag
local-image:latest dockerhub-username/repo-name:tag.

• The Workflow: A typical process involves building an image, tagging it with a specific version
(e.g., v2.5.1), and also tagging it as latest.

Tag Type Purpose Insight

Specific Tag Marks a production-ready, known- Ensures pinning—users can always pull the
(v2.5.1) good build. exact version that was tested.

Moving Tag Always points to the most recently Provides a convenient default for users who
(latest) published stable build. don't care about specific versioning.

The full publication workflow:

1. Tag: docker tag my-app:latest myusername/my-app:v1.0

2. Login: docker login (authenticates access to the registry)

3. Push: docker push myusername/my-app:v1.0

This final step completes the microservice DevOps loop: Code Dockerfile Image (Build) Container
(Test) Registry (Distribute).
Testing Tools:Selenium and JavaScript testing
The profound insight into Selenium and JavaScript testing is that they represent two distinct, yet
complementary, approaches to ensuring web application quality: External End-to-End (E2E) UI Testing
(Selenium) and Internal Component/Unit Testing (JavaScript Frameworks).

Selenium validates the entire user experience from the outside, acting as a human would, while
JavaScript testing frameworks validate the smallest building blocks of the application from the inside,
ensuring reliability at the source code level. Together, they create a robust quality assurance strategy.

1. Introduction to Selenium and its Features

Selenium is an open-source suite of tools designed to automate web browsers for testing purposes. It
provides a way to write scripts that mimic user interactions (clicks, form inputs, navigation) and verify
the application's behavior and user interface (UI) in real browsers.

Deep Insight: The "Black Box" E2E View

Selenium operates as a "Black Box" testing tool. It doesn't care how the code is structured internally;
it only cares that the final, rendered webpage works correctly for the end-user. It tests the application
as a complete system, catching errors related to integration, deployment, and overall user flow.

Feature Description Insight

The core component; it directly Ensures authentic user simulation—scripts run

WebDriver controls native browser APIs exactly as a user would interact with the browser,
(Chrome, Firefox, etc.). not just manipulating HTTP requests.

Scripts can be written in multiple

Language Offers flexibility for development teams to use
languages (Java, Python, C#,
Support familiar languages for testing.
etc.).

Cross- Easily runs the same tests across

Essential for ensuring compatibility in the diverse
Browser different browsers and
modern web environment.
Testing operating systems.

Allows parallel execution of tests

Selenium Provides speed and scale crucial for Continuous
across many machines and
Grid Integration/Continuous Deployment (CI/CD).
environments.

Export to Sheets

Example: Selenium (Python) - Login Test

This script logs into a dummy website and verifies the successful login.

Example Program (Python with Selenium WebDriver)

Python

from selenium import webdriver

from [Link] import By

from [Link] import Service

# 1. Setup (Requires [Link] in your PATH or specified path)

service = Service('/path/to/chromedriver') # Replace with your actual path

driver = [Link](service=service)

# 2. Step-by-Step Execution Procedure

try:

# Navigate to the login page

[Link]("[Link] # Assume a dummy login page

print("Navigated to login page.")

# Locate and enter username

username_field = driver.find_element([Link], "username")

username_field.send_keys("testuser")

print("Entered username.")

# Locate and enter password

password_field = driver.find_element([Link], "password")

password_field.send_keys("password123")

print("Entered password.")

# Locate and click the login button

login_button = driver.find_element(By.TAG_NAME, "button")

login_button.click()

print("Clicked login button.")

# Verification: Check if the success message or dashboard element is visible

# We wait for a specific element (e.g., the dashboard title) to appear

success_element = driver.find_element(By.CLASS_NAME, "dashboard-title")

 assert "Welcome, testuser" in success_element.text

print("\n Test Passed: Successfully logged in and verified dashboard title.")

except Exception as e:

print(f"\n Test Failed: {e}")

finally:

# 3. Cleanup

[Link]()

2. JavaScript Testing (Unit and Component)

JavaScript testing refers to the use of dedicated frameworks (like Jest, Mocha, and Cypress) to test the
application's code modules, components, and logic before they are integrated or deployed.

Deep Insight: The "White Box" Internal View

This is "White Box" testing, where the internal structure and logic of the code are known and explicitly
tested. It validates the code at the developer level, catching bugs early and providing fast feedback.

• Unit Testing (Jest, Mocha): Tests the smallest isolated parts of the application (e.g., a single
function).

o Insight: Extremely fast and pinpoint failure location precisely. This is the first line of
defense against bugs.

• Component Testing (React Testing Library, Vue Test Utils): Tests UI components in isolation
(e.g., a "Login Form" component).

o Insight: Ensures individual UI elements render correctly and handle state/props as

expected, without relying on the full backend or browser setup.

Example: JavaScript (Jest) - Unit Test

This example tests a simple function that adds two numbers.

Example Program (JavaScript/Jest) - [Link]

JavaScript

// [Link]

function sum(a, b) {

if (typeof a !== 'number' || typeof b !== 'number') {

throw new Error('Both arguments must be numbers');

}
 return a + b;

[Link] = sum;

Example Program (JavaScript/Jest) - [Link]

JavaScript

// [Link]

const sum = require('./sum');

// The test suite

describe('The sum function', () => {

// Test case 1: Happy Path

test('adds 1 + 2 to equal 3', () => {

// The 'expect' assertion is the core of the test

expect(sum(1, 2)).toBe(3);

});

// Test case 2: Edge Case (Negative numbers)

test('adds -1 + 1 to equal 0', () => {

expect(sum(-1, 1)).toBe(0);

});

// Test case 3: Error Handling (Non-number input)

test('throws an error if inputs are not numbers', () => {

// Jest's 'toThrow' assertion is used for exception handling

expect(() => sum('a', 2)).toThrow('Both arguments must be numbers');

});

});

Step-by-Step Execution Procedure (Jest)

1. Setup: Ensure [Link] and npm are installed.

o Initialize a project: npm init -y

o Install Jest: npm install --save-dev jest

 2. Define Script: Add a test script to your [Link]: "test": "jest"

3. Execute: Run the test from the terminal:

o npm test

4. Result: Jest quickly executes the file, reporting the outcome.

o Output: A console message showing that 3 tests passed with 100% code coverage for
the [Link] file.

Synthesis of Approaches

Metric Selenium (E2E) Jest/Mocha (Unit)

User experience, integration, and final Code logic correctness and individual
Goal
product validation. component reliability.

Feedback Slow (Requires building, deploying, and Fast (Runs in milliseconds in the [Link]
Speed full browser setup). environment).

Broad (Can't easily pinpoint the Pinpoint (Identifies the exact function and
Failure Scope
function that failed). line of code that failed).

Relies on a running server, database, Independent of the server, database, and

Dependency
and browser. browser.

Question bank
1. A key challenge in Continuous Delivery (CD) is maintaining environment parity. How
does Docker address this issue, and why is this critical for achieving true CD reliability?
(Bloom's Level 3 - Application)
2. Which sequence of Docker commands correctly prepares and publishes the image?
(Bloom's Level 3 - Application)
3. Differentiate the roles of the CMD and ENTRYPOINT instructions within a Dockerfile
and explain how they interact to define the executable when a container is run.
(Bloom's Level 2 - Comprehension).
4. Demonstrate the combination of two Docker commands you would use to confirm
the container is running and then access its real-time internal process output to find
potential errors? (Bloom's Level 3 - Application)
5. Explain the rationale for splitting the COPY instructions, in Dockersfile. (Bloom's Level
3 - Application)
6. Bring out the primary difference in persistence and modification between a Docker
Image and a Docker Container? (Bloom's Level 2 - Comprehension)
7. A Continuous Integration (CI) build pipeline for a microservice fails during the npm test
step. The tests are written using a JavaScript framework like Jest and specifically check
if a single class method, [Link](id), correctly returns a validated user
 object. Based on the scope of the code being tested, what type of testing is most likely
failing? (Bloom's Level 3 - Application)

Bit Bank:

Corre
ct
# Question Options Bloom's Level
Answ
er

A. It requires the use of Docker and

What is the core insight Kubernetes. B. It's about reducing risk and
regarding the importance building quality into the process. C. Its Level 2
1 B
of Continuous Delivery primary goal is to eliminate all manual (Comprehension)
(CD)? testing. D. It ensures the deployment time
is exactly 15 minutes.

Which phase of the CI/CD A. Continuous Integration (CI) - Build B.

flow is responsible for Continuous Integration (CI) - Static Analysis
Level 2
2 creating a deployable C. Continuous Delivery/Deployment (CD) - C
(Comprehension)
artifact, such as a Docker Artifact Creation D. Monitoring &
Image, and storing it? Feedback

Which fundamental
Docker component is
defined as a read-only
A. Docker Daemon B. Docker Container C. Level 2
3 template composed of C
Docker Image D. Docker CLI (Comprehension)
layered filesystems and
serves as the blueprint for
containers?

A. It sets the internal container port to

The docker run command
8080. B. It runs the container process in
is often used with the -p
parallel on two ports. C. It maps the host Level 3
4 8080:80 flag. What specific C
machine's port 8080 to the container's (Application)
functionality does this flag
internal port 80. D. It specifies the image
enable?
build path.

Which instruction in a
Dockerfile is used to
execute a command during
Level 2
5 the image build process A. CMD B. EXPOSE C. RUN D. ENTRYPOINT C
(Comprehension)
(e.g., installing
dependencies) and creates
a new layer?
 Corre
ct
# Question Options Bloom's Level
Answ
er

Which Docker command is

used specifically to execute
a new, isolated command
A. docker run B. docker attach C. docker Level 3
6 (like opening a shell or D
start D. docker exec (Application)
running a diagnostics
script) inside an already
running container?

A. It mandates the use of Selenium for

testing. B. Every change that passes
Continuous Deployment is
automated tests is automatically released
distinguished from Level 2
7 to production. C. It uses Virtual Machines B
Continuous Delivery by (Comprehension)
instead of containers. D. It requires a
which characteristic?
manual checklist before deployment to
staging.

A. To manage image storage on Docker

What is the primary Hub. B. To perform high-speed JavaScript
purpose of Selenium in the Unit Testing. C. To automate End-to-End Level 2
8 C
context of a CI/CD (E2E) and User Interface (UI) testing by (Comprehension)
pipeline? simulating user interaction. D. To compile
the application code on the build server.

Fill in the blanks

# Question Answer

Continuous Delivery (CD) is a key part of the ________ philosophy, ensuring

1 DevOps
code changes are automatically built, tested, and prepared for release.

Docker solves the problem of "it works on my machine" by guaranteeing

2 consistency
________ across development, testing, staging, and production environments.

To list all currently running containers on your system, you would use the
3 docker ps
________ command.

When a Container is started, Docker adds a single, thin ________ layer on top read/write (or
4
of the image's read-only layers for runtime state changes. writable)
# Question Answer

The Dockerfile instruction ________ specifies the starting base image, such as
5 FROM
node:18-alpine.

To make a local image available to a remote CI/CD pipeline, the final step after
6 docker push
tagging the image is to use the ________ command to upload it to the registry.

The ________ framework allows for the parallel execution of Selenium tests
7 Selenium Grid
across multiple machines and browser versions, speeding up the test run time.

The fastest feedback loop in JavaScript testing is provided by ________ testing,

8 Unit
which focuses on small, isolated functions, often using tools like Jest.