DevOps & Deployment

1. What is DevOps?

DevOps is a culture, set of practices, and toolchain that unifies software development (Dev) and IT operations (Ops). It breaks down the traditional wall between the team that builds software and the team that runs it, so they collaborate throughout the entire lifecycle.

The core ideas: automation of build, test, and deployment so releases are fast, repeatable, and reliable; continuous delivery so software can be released at any moment, in small increments; collaboration and shared ownership between developers and operations; monitoring and feedback so problems are found quickly and learning flows back into development; and infrastructure treated as code.

DevOps arose because the traditional handoff was slow and adversarial — developers “threw code over the wall” and operations ran it, leading to long release cycles and blame when things failed. DevOps replaces that with a single team owning the software end to end. The measurable outcomes are faster, more frequent, lower-risk releases. The interview point: DevOps is primarily a cultural and process shift — automation is the enabler, not the definition.

2. What is CI/CD?

CI/CD is the combined practice of Continuous Integration (CI) and Continuous Delivery/Deployment (CD) — the automation pipeline that takes code from a developer’s commit all the way to production.

Continuous Integration automatically builds and tests every code change as it is committed, catching integration problems immediately. Continuous Delivery extends this by automatically preparing every change for release — building, testing, and packaging — so that releasing to production is a manual, one-click decision at any time. Continuous Deployment goes further and automatically releases every change that passes the pipeline to production, with no human gate.

The pipeline typically runs: on every commit, code is compiled, unit and integration tests run, the build is packaged, it is deployed to staging, and smoke or acceptance tests run there. CI/CD’s benefits are speed (frequent small releases), quality (every change is tested), and low risk (small changes are easier to roll back). The interview distinction to nail: CI is about integrating and testing constantly; CD about the release pipeline — delivery keeps a human in the loop, deployment removes it.

3. What is Continuous Integration?

Continuous Integration (CI) is the practice of automatically integrating and testing every code change as soon as it is committed to the shared repository — many times a day. Its purpose is to catch integration problems early, before they compound.

The mechanics: developers commit frequently to the shared branch; on every commit, a CI server automatically builds the code and runs the test suite; if the build or tests fail, the team is notified immediately and the failure is fixed before moving on. The commits are small and frequent, so integration problems are small and immediately located.

The value of CI is that integration is a continuous, low-stress activity rather than a painful end-of-project event. In traditional development, developers worked in isolation for weeks, and “integration day” was a disaster. CI inverts this: the main branch is always in a working state, because every change is validated as it lands. The key practices: a shared repository, frequent commits, an automated build and test on every commit, and a culture where a broken build is the team’s top priority.

4. What is Continuous Delivery?

Continuous Delivery (CD) is the practice of ensuring that every code change is automatically built, tested, and prepared for release, so the software can be released to production at any time — with the actual release being a deliberate, human decision.

The pipeline automatically runs the build, tests, and deployment to a staging environment that mirrors production, validating each change as far as possible. What stops at a human gate: the decision to push to production. The release is one-click and low-risk because it has been exercised continuously — the team is always ready to release, at any moment.

The value of Continuous Delivery is that releasing becomes boring and cheap. Because every change is always release-ready, the team can ship small, frequent releases whenever the business wants — instead of the traditional “release train” every few months with its painful integration and freezing. The distinction: Continuous Delivery keeps a manual approval before production (the business decides when); Continuous Deployment removes that gate entirely and releases every passing change automatically. Continuous Delivery is the safer and more common choice for teams that want control over the release moment.

5. What is Continuous Deployment?

Continuous Deployment is the practice of automatically releasing every code change that passes the automated pipeline directly to production — with no human approval step. Every commit that builds, passes its tests, and passes the deployment pipeline goes live automatically.

Continuous Deployment extends Continuous Delivery by removing the manual release gate. In Continuous Delivery, a human decides when to release; in Continuous Deployment, the pipeline itself is the release. If the change passes every check — build, unit tests, integration tests, acceptance tests, deployment tests — it is deployed.

Continuous Deployment is the strongest form of the release automation spectrum (CI → Continuous Delivery → Continuous Deployment), and it demands exceptional confidence in the pipeline: excellent test coverage, automated monitoring, and fast rollback, because a bad change reaches users without human review. Its benefit is the fastest possible feedback loop — the moment a feature is merged it is in production, and the team learns immediately. Its cost is the rigor required. It suits products with strong automated quality gates; teams that need human judgment at release still use Continuous Delivery.

6. What is the difference between Continuous Delivery and Continuous Deployment?

Both are the “CD” in CI/CD and both automate everything up to the point of release. The difference is the final step.

Continuous Delivery ensures every change is automatically built, tested, and prepared for release, so the software is always release-ready — but the actual release to production is a manual, human decision. The business chooses when to ship. Continuous Deployment removes that human gate: every change that passes the automated pipeline is automatically released to production, with no manual approval.

The practical consequences: Continuous Delivery can release frequently but on a schedule the business controls — safer for regulated environments, and it allows batching releases. Continuous Deployment releases constantly — every merged change goes live — giving the fastest feedback loop but requiring a very trustworthy pipeline, comprehensive tests, and rapid rollback.

The interview answer: both automate the release preparation; Delivery stops at a human approval for production, Deployment does not. Continuous Deployment is a superset — everything required for Continuous Delivery plus the automated final release.

7. What is deployment automation?

Deployment automation is the practice of using tools and scripts to deploy software to environments automatically, instead of performing manual steps by hand. It turns “log into the server and follow the runbook” into “run the deployment pipeline.”

Automation covers the whole deployment: building the artifact, provisioning the environment, pushing the code, running migrations, configuring the runtime, and smoke-testing the result. Tools like CI/CD servers, infrastructure-as-code tools, and container platforms drive it. The same automated pipeline deploys to development, staging, and production, reducing drift between environments.

Deployment automation matters because manual deployment is slow, error-prone, and unrepeatable — humans forget steps, type wrong commands, and get different results each time, especially on complex environments. Automation makes deployments fast, consistent, and auditable: the same process runs every time, and it runs the same way in every environment. It is also the prerequisite for frequent release — you cannot release many times a day with a two-hour manual runbook. The interview point: deployment automation is what makes fast, reliable, repeatable releases possible; it is the execution arm of CI/CD.

8. What is a deployment pipeline?

A deployment pipeline — also called a release or CI/CD pipeline — is the automated sequence of stages that a code change passes through from commit to production. Each stage validates the change and prepares it for the next.

A typical pipeline: commit — the developer pushes code; build — the code is compiled and packaged into an artifact; test — unit, integration, and acceptance tests run; staging deployment — the artifact is deployed to a staging environment and validated there (smoke tests, performance checks); approval — (in Continuous Delivery) a human approves; production deployment — the artifact is deployed to production; verification — monitoring confirms the deployment is healthy.

The pipeline is the concrete machinery of CI/CD. Its design principles: every stage is automated and fast; failures stop the pipeline and notify the team; the same artifact flows through all stages (no rebuilding between environments); and the pipeline gives visibility — everyone can see where every change is. The value of a good pipeline is that the release is no longer a risky event — it is a routine, exercised path that every change travels through safely.

9. What is Infrastructure as Code?

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure — servers, networks, databases, load balancers — through machine-readable definition files instead of manual configuration or interactive tools. The infrastructure is treated like application code: versioned, reviewed, tested, and deployed through pipelines.

Tools like Terraform, CloudFormation, Ansible, and Pulumi define the desired infrastructure declaratively — “I want three web servers behind a load balancer with this database” — and the tool makes reality match the definition. The definitions live in a repository, so infrastructure changes go through the same review and automation as code changes.

IaC delivers several benefits. Consistency: the same definition produces the same infrastructure every time — no more “works on the admin’s laptop.” Repeatability: environments (dev, staging, prod) are created identically and destroyed easily. Versioning and audit: every infrastructure change is recorded and revertible. Speed: environments are provisioned in minutes, not days. The interview point: IaC is the infrastructure equivalent of source code management — it turns a manual, error-prone process into a versioned, automated, testable one.

10. What is blue-green deployment?

Blue-green deployment is a release strategy that uses two identical environments — blue (the current production version) and green (the new version) — to release with minimal risk and near-zero downtime.

The process: while blue is serving all traffic, the new version is deployed and tested on green. When green is verified healthy, the load balancer switches traffic from blue to green — an instant switch with no downtime. If anything goes wrong, the switch is flipped back to blue, which is still running the old version, giving an instant rollback.

Blue-green deployment’s strength is fast, safe rollback: the previous version is still live and warm, so reverting is flipping a switch, not redeploying. Its cost is the doubled infrastructure — two full environments running at once. It suits applications where downtime is unacceptable and rollback must be instant. The interview point: blue-green separates deployment (get the new version running) from release (switch traffic to it), which is why rollback is so simple — the old version was never destroyed.

11. What is canary deployment?

Canary deployment is a release strategy that gradually rolls a new version out to a small subset of users first, monitors it, and only then expands it to everyone. It reduces the risk of a bad release affecting all users at once.

The process: the new version is deployed alongside the old one. A small percentage of traffic — say 5% — is routed to the new version (the “canary”). Monitoring watches its behavior — errors, latency, crashes. If the canary is healthy, the traffic percentage is gradually increased — 25%, 50%, then 100%. If the canary shows problems, traffic is redirected back to the old version and the rollout is stopped.

Canary deployment’s strength is controlled, measurable risk: problems affect only a few users and are caught by real production monitoring before broad exposure. It is more sophisticated than blue-green — instead of a binary switch, it is a gradual ramp. It suits applications where even a small outage is costly and where you want real user traffic validating the release. The name comes from the canary in a coal mine — a small early signal that warns of danger.

12. What is rollback in deployment?

Rollback is the process of returning an application to a previously known-good version after a deployment causes problems. When a release is bad — crashes, errors, performance degradation — rollback restores the service to the state before the change.

The methods depend on the deployment strategy. With blue-green, rollback is instant: switch traffic back to the blue environment, which is still running the old version. With canary, rollback means routing traffic away from the canary back to the stable version. With containers and orchestrators, rollback can mean redeploying the previous image. Some teams prefer forward-fix — shipping a new fix forward — but rollback remains the safety net for the moment the new version is broken.

The value of rollback is that a bad deployment becomes a low-risk, quickly recovered event rather than an incident. Rollback works best when it is automated and rehearsed: the team must be able to revert fast, and the previous version must actually be deployable. The interview point: rollback is the deployment team’s insurance — the ability to undo a release quickly is what makes frequent, low-risk releases possible.

13. What is containerization?

Containerization is a method of packaging software with all its dependencies — code, runtime, libraries, configuration — into a single isolated unit called a container, which runs consistently on any system that supports containers.

A container shares the host’s operating system kernel but isolates its own filesystem, processes, and network. This makes containers lightweight compared with virtual machines (which each run a full guest OS). The same container runs identically on a developer’s laptop, a staging server, or production — the “works on my machine” problem disappears because the environment is packaged with the code.

Containers bring several benefits: consistency across environments; portability between clouds and on-premises; efficient use of resources (lightweight, fast to start); and isolation between applications. They also enable the modern microservices and CI/CD workflow — each service is packaged independently and deployed in its own container. The interview distinction: containers virtualize the application (sharing the host OS), while virtual machines virtualize the hardware (each running a full OS) — which is why containers are lighter and faster.

14. What is Docker?

Docker is the most widely used platform for building, running, and managing containers. It made containerization practical and popular, and in common usage “Docker” and “container” are often used interchangeably.

Docker’s model: a Dockerfile describes how to build the container image — the base image, the dependencies, the code, and the command to run. Docker builds the image from the Dockerfile, and Docker runs containers from that image. Images are stored in a registry (like Docker Hub) and pulled to run anywhere. Docker provides the tooling for the whole lifecycle: build, ship (push/pull images), and run (create and manage containers).

Docker delivers the core container benefits — consistency, portability, lightweight isolation — with an easy workflow, and it became the standard because of that ecosystem. In modern practice, Docker is usually the container engine underneath an orchestrator like Kubernetes, which manages many containers across many machines. The interview point: Docker is the tool that builds and runs containers; containers are the technology — and at scale, Docker containers are typically managed by an orchestrator rather than run individually.

15. How does DevOps differ from traditional software development?

Traditional software development and DevOps differ in structure, rhythm, and ownership. In the traditional model, development and operations are separate teams with separate responsibilities and incentives — developers build, test, and hand the software “over the wall” to operations, which runs and maintains it. Releases are large, infrequent, and risky events, and when production breaks, the two teams blame each other.

DevOps unifies the two. One team owns the software end to end — development, deployment, and operations. Releases are small and frequent, automated through CI/CD pipelines, and risk is managed through automation, monitoring, and fast rollback. Collaboration replaces the handoff, and shared ownership replaces blame. Continuous feedback from production flows back into development.

The differences in practice: traditional releases happen quarterly with manual steps and release trains; DevOps releases happen daily or hourly through automated pipelines. Traditional testing happens late; DevOps integrates testing into every commit. Traditional environments are manually configured and drift; DevOps uses infrastructure as code for consistency. Traditional quality is checked at the end; DevOps builds quality checks into every stage. The interview point: DevOps is not a tool — it is a cultural shift from separated, batch-based development to continuous, collaborative, automated delivery.