Deployment Pipelines and Continuous Delivery

This session moves past continuous integration into the deployment side of the pipeline. We look at what deployment is, the considerations a team should settle before deploying, the challenges that make release processes slow and risky, what a deployment pipeline is and how its structure looks, the value stream map with its cycle, waste, and lead times, intelligent pipeline scheduling, the release plan, smoke testing, and a quick CI/CD knowledge check.

13.1 Continuous Delivery and Continuous Deployment

What is the smallest possible difference between two of the most used terms in the DevOps vocabulary? One button — the button that pushes code into production.

13.1.1 How the Delivery Flow Runs

The whole flow starts with the developers and the DevOps team changing code. The moment the code is committed to the source code management (SCM) repository — the single versioned home of the codebase — the build process triggers automatically. Nobody logs into a server and runs the build by hand; the commit itself is the trigger. Once the build finishes, the testing cycles start automatically as well: capacity testing (can the system handle the expected load?), functional testing (does each feature behave as specified?), and so on. Every step in this chain happens with tools and technology, not by hand.

This is an ongoing process. The team keeps adding a new feature, enhancing existing functionality, or fixing bugs, and the loop keeps running until the product cycle for that particular product is complete. Nothing about this loop is a one-time event: each check-in restarts the entire cycle, which is why the word "continuous" matters. In this course the flow is called continuous integration while it covers commit through build and test; the term continuous delivery (and its relative continuous deployment) starts where the artifacts begin moving toward the environments where users will meet them.

13.1.2 Continuous Delivery

The distinction is sharp: if you deliver the code to the staging, pre-production, or UAT environment with automation, you call it continuous delivery — as long as the final step, pushing to production, is still a human action. Each intermediate environment has a purpose: staging is a rehearsal environment built to look like production; pre-production runs the last checks before going live; UAT is where end users (or their representatives) confirm that the software actually meets their needs. All three are delivery targets. Production is not one of them in continuous delivery — a human decides when the verified artifact is allowed in.

13.1.3 Continuous Deployment

So the difference between the two terms is one step: in continuous delivery the production push is manual; in continuous deployment it is automated too. Continuous delivery is the prerequisite for continuous deployment — just as continuous integration is the prerequisite for continuous delivery. You cannot meaningfully automate the production push of an artifact that has not been built and tested automatically first; each stage builds on the guarantees of the previous one.

13.1.4 The Contrast in One View

A useful way to remember the pair: continuous delivery gets you ready to deploy at any moment, with a human pressing the final button; continuous deployment does not wait for a human — every check-in that passes the pipeline ends up in production on its own. Both terms describe an automatic flow from commit through build and test; they split only at the production boundary.

The guiding question for a team: what happens between the last green test run and production? If the answer names a person pressing a button, the team is practicing continuous delivery. If the answer is "nothing — the pipeline does it", the team has moved to continuous deployment.

Real-world: at Amazon and Google, most teams practice continuous delivery, and some practice continuous deployment — there is real variation between teams in how often they deploy and how the deployment happens. Teams choose based on the risk they are managing: an online service with strong automated tests and quick rollback can auto-ship every passing change, while a team shipping software to devices in the field usually keeps a human in the loop at the release boundary.

13.2 Deployment Considerations

Before any team performs a deployment, it should be clear about several considerations. The class brainstormed this exact question, and the list the discussion produced became the backbone of the rest of the session: four answers from the class itself, three formal additions from the discussion, and a fourth practical one — tools.

13.2.1 The Class Brainstorms Considerations

So the class itself named four things: a rollback plan, unit testing, a security check, and zero downtime. The discussion then added three more formal considerations: compatibility, thorough testing (canary style), and rollback versus roll forward, plus a fourth practical one — tools. None of these are nice-to-haves; each one answers a question that will come up the moment a release goes wrong, so the checklist doubles as a risk register for the release.

13.2.2 Compatibility: Backward and Forward

The first formal consideration is compatibility, and it comes in two directions: backward compatibility and forward compatibility.

Backward compatibility means the new version of your application should support the older version's services as well — the new version keeps the old version's behavior alive. The case study used was an e-grocery application.

The design rule behind the example: the safe way to evolve a schema is to add new fields or tables, not to repurpose or drop existing ones. The old behavior keeps working, and the new fields can be filled in gradually.

13.2.3 Forward Compatibility

Forward compatibility is the opposite direction: the application should be compatible with the upcoming versions, and users should always know which version they need to access a given feature. The same e-grocery story continues.

The takeaway constraint: an application should always be backward and forward compatible at the same time. Both directions protect the same thing — the moment in between deployments when two versions of the system coexist in the world.

13.2.4 Canary Testing

A deployment should also be well tested. The class mentioned this in the brainstorm, and the fuller name for it is canary testing — some people call it alpha or beta testing. The idea: end users perform the testing and access the features, then report whether the product or application is fit to use or not. The canary question came up again later in the session.

So canary testing is on the agenda under deployment strategies, which is a separate topic that comes after this one. What matters here is the role it plays in the consideration list: automated tests in the pipeline prove the software is technically sound, and canary testing is the layer where real users (the "end-user testers") judge whether the product is fit to use.

13.2.5 Rollback and Roll Forward

Rollback was the first thing the class named, and it gets a careful treatment.

The key property to notice: rollback is a downtime-avoiding move. The old version takes over instantly, users keep getting service, and the debugging happens in the background, without the pressure of a dead application.

The deciding factor between the two is knowledge: unknown root cause means roll back; known root cause and known fix means roll forward.

In practice the decision is rarely made by a machine: a human looks at how serious the error is and then chooses between rolling back and rolling forward. Rolling back is the more cautious path (it reverts to a known-good state), and rolling forward is simply a normal upgrade performed quickly — which is exactly why a team can only roll forward when it genuinely understands the bug.

These are the three basic, mandatory deployment considerations every team should be aware of: compatibility, testing, and rollback/roll-forward — and the fourth is tools.

13.2.6 Tools and Platform Choice

The fourth consideration is tools. When it comes to deployment, the big question is: on what platform are you deploying? Are you deploying on a local server inside the organization? Is the team deploying to a cloud platform, or onto a virtual machine? Based on the platform you choose, you need to know what kind of tools and technology your team will use to complete the deployment, and those tools must be clear to every team member, because they are the ones operating them during deployment.

The platform decides the toolchain: a local server inside the organization may be deployed to with simple scripts over SSH; a cloud platform brings managed deployment services; a virtual machine (VM) setup may need image baking and hypervisor tooling. Whatever the choice, the tools must be known to every team member — the deployment button is useless if the person who must press it does not know which tool produces which artifact.

Real-world: e-commerce and banking apps deal with the compatibility question on every release — the app on a user's phone (an old version) must keep talking to the backend (a new version) while a deployment is in progress. That is why API versioning and tolerant null handling are standard practice, and why the rollback plan is rehearsed in production-like environments before it is ever needed in anger.

13.3 Challenges in Deployment

What is the biggest challenge in deployment? It is not automation — it is the waste hiding inside the process that automation is supposed to speed up.

13.3.1 Waste in the Deployment Process

The very first challenge — and the biggest one — is waste in the deployment process. Up to this point the discussion has only covered how to automate each process with particular tools and technology, plus the best practices of each stage: code practices in source code management, test-case writing in testing, best practices in continuous integration. Nobody touched the aspect that the process itself might contain waste.

Waste, in this context, is anything that adds no value to the product or the development cycle. The examples of waste seen in the software industry:

• Build and operations teams waiting for documentation or fixes. The build engineers and the operation team sit idle, doing no fruitful work, because they are blocked on something outside their control. Their time is spent waiting, not producing.
• Testers waiting for good builds of the software. They cannot perform testing until a decent artifact arrives, so their time is wasted. The tester is fully available, but the thing they test has not been delivered yet.
• Development teams receiving bug reports a week after the team has already moved to the new functionality. The feedback is delayed, reports do not arrive on time, and that delay is pure waste — the bug is now anchored to code the team has already left behind, so fixing it costs rework.
• Discovering towards the end of the deployment process that the application architecture will not support the system's non-functional requirements. The discovery comes far too late to matter cheaply. A non-functional requirement (NFR) is a property of the whole system — performance, security, scalability, availability — and if the architecture cannot deliver it, the discovery at the end of the process means the fix is expensive or impossible.

The common thread: every example is time spent not adding value — waiting, delayed feedback, or discovering problems too late to fix cheaply.

13.3.2 What Waste Produces

This kind of waste leads to software that is undeployable — because it has taken so long to reach a production-like environment — and buggy, because the feedback cycle between the development, testing, and operation teams is so long.

The key warning: even if you have a proper automation toolchain in place and everything is deployed, if you do not have a proper, value-added process, your organization will not see the actual results of DevOps. A team can call itself DevOps while the operation team still gets feedback way too late, while people do not follow the CI/CD pipeline, while the team is not aware of the tools and technology. Anything that adds waste, anything that adds no value to the product or the development cycle, is waste.

13.3.3 The New Approach to Deployment

The new approach should be an end-to-end way of delivering software:

• Deployment of the application should be easy and one-click-go. It should not be a manual task that creates a dependency on the team — the deployment must not require a specific person's memory or presence.
• A powerful feedback loop should exist — rapid feedback on both the code and the deployment process, given to the team.
• Lower the risk of release, and transfer knowledge of the deployment process to the development team. If the process is scripted and simple, the knowledge lives in the script, not in one person's head.
• Testing teams should deploy the builds into the testing environment by themselves, using the push button. This removes the waste of the tester waiting for a proper build or artifact — a pull system, where the person who needs the build pulls it on demand, replaces the push chain of handoffs.
• Operations should be able to deploy builds into staging and production environments at the push of a button.
• Developers should be able to see which builds have passed through which stage of the release process, and what problems were found at each stage.

These six points are really one idea: make every environment self-service. Each role pulls the build it needs when it needs it, and every role can see the state of every build.

13.3.4 The Water-Pipe Bottleneck Analogy

The intuition for why visibility matters comes from a simple image: a water pipe and a water tank.

The analogy carries over to software delivery exactly: the value stream is the pipe, the value-added work is the water, and the release process is full of narrow joints (waiting for builds, delayed feedback, late discoveries). Improving an arbitrary stage without knowing the bottleneck is wasted effort — which is itself waste, the very thing this section is about.

With a transparent release system, everybody in the delivery process gets two things: access to what they need when they need it, and visibility into the release process. The team sees where the problem is, gets feedback early, visualizes the bottleneck in the value stream, optimizes it, and removes it. The result is a delivery process that is not only faster but also safer, because you are rehearsing it — you use the same release process every time you change code, so by the time a real release happens, the process has already been exercised hundreds of times.

Real-world: the idea that waste kills flow comes from lean manufacturing — Toyota's production system — and entered software through the lean and DevOps movements. In industry, the concrete versions of these wastes are the queue of un-reviewed pull requests, test environments that take weeks to provision, and release tickets that sit in approval queues; every one of them is a pipe joint waiting to be measured and widened.

13.4 The Deployment Pipeline and the Value Stream Map

13.4.1 What a Deployment Pipeline Is

This design increases collaboration between many individuals and gives the transparency to visualize what is going on — which particular version is in which state of the pipeline at any moment. The pipeline is the map of the delivery process turned into machinery: wherever the map shows a step, the pipeline shows an automated stage, and wherever the map shows a wait, the pipeline shows a bottleneck waiting to be removed.

13.4.2 Value Stream Map of Product Creation

A value stream map exercise maps every stage a product passes through — a flowchart of the product's journey from opportunity to release. The example below is taken from the textbook itself — a high-level value stream map for creating one particular product, with the value-added time at each stage (the time spent actually working) and the handoff time between stages (the elapsed waiting time):

First comes product opportunity assessment: assess what the product opportunities are. Then the idea becomes a product and you start discovering it — collecting requirements, deciding how the product will be, making sure it differs from competitive products. Different teams do these stages: the business team (PRM) hands the opportunity assessment to a requirement-gathering team for product discovery. After the requirements are identified, product planning and estimation decides which features go into the product, how much time and effort it needs, and what cost is involved. Then the actual development happens, followed by final testing, approval, and release.

Note on the development handoff: the map shows 5 days of waiting between development and testing, which is the value in the textbook figure this example comes from — that source explicitly calls out "a five-day wait between the development team completing work on the first release and the start of the testing process". The five days is also the value used in the waste-time arithmetic below, so the map and the sums stay consistent.

13.4.3 Cycle Time, Waste Time, and Lead Time

Three terms organize this map. Cycle time is the value-added time — the sum of all the productive stage durations, where the index $i$ runs over all the stages of the map:

$$\text{cycle time}=\sum _i(\text{value-added time at stage }i)$$

For the example product, the lecture states the cycle time as 11 weeks, 3 days, and 2 hours. Waste time is the elapsed time spent between stages — the handoffs where nothing productive happens, where the index $j$ runs over all the handoffs between consecutive stages:

$$\text{waste time}=\sum _j(\text{elapsed waiting time between stages})$$

The waste components are 1 week plus 10 days plus 3 days plus 5 days plus 2 days, and the lecture states this to give five weeks of waste time. Finally, lead time is the overall cycle time plus waste time:

$$\text{lead time}=\text{cycle time}+\text{waste time}$$

Lead time means the whole span from when the project started until the product is released to the market.

The lecture stated the totals as 11 weeks 3 days 2 hours (cycle time) and five weeks (waste time). Those stated figures are kept here as the exam-relevant versions; the arithmetic above is the reference form. Where does the four-day gap between the stated 11 weeks 3 days 2 hours and the computed 10 weeks 6 days 2 hours come from? The likely source is a unit slip in one stage: if the 10-day planning and estimation stage is counted as two weeks (14 days) instead of 10 days, the total becomes $3+7+14+49+7=80$ days, which is exactly 11 weeks 3 days — the stated cycle time. Similarly, the stated "five weeks" of waste does not match the 27 days the handoffs actually sum to. When you work such an example, always re-add the table yourself rather than trusting a spoken total.

13.4.4 The Value Stream Mapping Exercise

In a value stream mapping exercise, the team or organization tries to minimize the waste time as much as possible while increasing the value-added time. The challenges can be anything — teams sitting in different locations, email notification delays — and those challenges are addressed in the brainstorming session of the exercise. The organization then works to shrink the waste time and grow the cycle time.

The map is a measurement instrument, not a decoration: once the waiting times are written down, the team can see which handoff is the longest joint in the pipe (from section 13.3) and attack exactly that one. Every brainstorming session in the exercise is aimed at a specific handoff or delay — remote teams cause waiting, so fix the handoff protocol; email notifications delay decisions, so automate the notification.

Real-world: value stream mapping is borrowed from lean manufacturing, where factories map the path of a physical product through machines and waiting areas. In software, the same exercise maps the path of a feature from opportunity assessment to release — the map in this section is the canonical textbook example, and running the exercise is how organizations decide where their DevOps effort should land first.

13.5 Structure of the Deployment Pipeline

13.5.1 Expected Steps

Every deployment pipeline follows the same expected steps.

As the build passes each test of its fitness, confidence in it increases: this application will be fully quality even in a production environment. Confidence is not a feeling here — it is the accumulated evidence of each stage that the artifact survived. The more stages the build clears, the more resources the team is willing to spend on it: environments become progressively more production-like, exactly matching the growing confidence.

The objective of the design is to eliminate unfit release candidates as early as possible in the process. That gives the team feedback on the root cause of failure as rapidly as possible, so they can perform root cause analysis and fix the unfit release. Any build that fails a stage is generally not promoted to the next one: if the build fails, it does not move to testing — it goes back, the team gets the feedback that the build failed, they fix the code, revisit and refactor it, commit it to the version control system again, and the same pipeline triggers once more after the code change has been committed.

The loop is important: the pipeline is not a one-way road with a dead end at failure. A failed stage feeds back into the codebase — fix, commit, retrigger — so the pipeline is a closed loop around the delivery team. Failing early is a feature, not a bug: a failure at the first stage costs minutes; the same failure found in production costs an incident.

13.5.2 Three Scenarios in a Typical Pipeline

The same idea, shown as three concrete check-in scenarios:

13.5.3 The Broad Overview: Stages

Looking at the broad overview, every stage gets tested and the stages fall into a familiar shape.

Because each environment is exercised by the pipeline, you get faster feedback and the environments become more production-like, which raises the assurance that the build is ready for production. There is a trade-off built into this structure: the deeper the build travels, the more resources the stages consume (acceptance testing is far costlier than compiling), but the more production-like the environment it is tested in, the stronger the guarantee it will work in production. The pipeline is designed so that cheap stages run early and every build, while expensive stages run late and only for the survivors.

Visualize the pipeline as a funnel with three compartments: on the left, the commit stage (compile, unit tests, code analysis, build) — fast and cheap, filtering every check-in; in the middle, the acceptance test stage (user acceptance testing, capacity testing) — slower, filtering the survivors; on the right, deployment to production. Each compartment is labelled with two growing quantities — confidence in the build's production readiness (rising) and the production-likeness of the environments (rising) — and one shrinking quantity: the time between a mistake and its feedback.

Real-world: this is the shape used by every mainstream CI/CD tool — Jenkins pipelines, GitLab CI, GitHub Actions, Go — where a job graph of build → test → deploy stages mirrors the commit stage, acceptance stage, and production deployment. Teams read the pipeline board the way air traffic controllers read a runway: which change is where, and which stage is currently the bottleneck.

13.6 A Basic Deployment Pipeline with Tools

13.6.1 From Source Repository to Artifact

With respect to tools and technology, the in-depth components of a deployment pipeline start with the source code repository — GitHub in this case.

Whenever a code change is committed, GitHub triggers the commit stage, which is your integration pipeline. Here you compile, run the commit tests, assemble the code, perform code analysis, and store the resulting binary artifact in the artifact repository. That artifact repository is a real, named component of the pipeline — the place where the binaries wait for the later stages.

The commit stage plays the role of the first gate: it rejects code that does not compile, code that fails its tests, and code that violates the analysis rules — before any environment is touched. Only the survivors are assembled into binaries and handed to the artifact repository.

13.6.2 Acceptance Staging and Configuration as Code

For acceptance staging — performing acceptance testing on the artifact — you access the environment and its configuration through the version control system itself. This is the practice of managing configuration as code and infrastructure as code: everything lives in version control, and you write scripts for it.

The steps in the acceptance stage, in order:

1. Configure the environment — pull the environment and app configuration from version control and apply it.
2. Deploy the binaries — take the artifact from the artifact repository into the environment.
3. Smoke test — verify the application actually started and answers.
4. Acceptance tests — run the full automated acceptance suite against the deployed application.

The key idea: none of this is done by hand on a server. The environment's identity is a set of versioned scripts and config files, so the same procedure that builds the acceptance environment can build the capacity environment, the UAT environment, and production. A deployment becomes "run the script for this environment against this artifact".

13.6.3 The Component View

Real-world: the overall picture of the pipeline has four kinds of repositories working together — the artifact repository, the source control repository, and the configuration and environment infrastructure (infrastructure as code), all of which live in version control systems themselves. None of the environments are hand-configured; every stage pulls its configuration from a versioned script.

The four work together: code flows from source control into the commit stage; binaries flow into the artifact repository; configuration flows from the config repositories into every environment; and each environment is scripted, never hand-made. This is what makes the pipeline repeatable — a new environment can be created from nothing but the versioned scripts, and a deployment cannot drift from how it was tested, because the scripts are the same everywhere.

Real-world: in industry the artifact repository is a concrete product — Nexus and Artifactory are the classic binary stores, and modern CI servers (Jenkins, GitLab CI) build artifact storage in natively. The configuration-as-code practice is what tools like Ansible, Puppet, and Terraform automate: the "environment" is a text file plus a script, exactly as the component view describes.

13.7 Outcomes of the Deployment Pipeline

13.7.1 Fast Feedback

The ultimate purpose of everything in this pipeline is one thing: get feedback to your team as fast as possible. Every stage gives feedback back to the previous stages early. That is the first outcome — a fast feedback cycle.

Feedback is the product of the pipeline, not the deployments. A build that fails in the commit stage tells the developer, within minutes of the commit, exactly what broke. The same failure discovered in production would travel backward through support tickets and reproduce-the-bug sessions for days. The pipeline compresses that distance: every stage is a checkpoint that reports to the team immediately, and the earlier the checkpoint, the cheaper the lesson.

13.7.2 Transparency and a Smaller Debugging Scope

The second outcome is transparency. You can see which build is deployed into which environment, and which stage in the pipeline each build has passed — all of it visible from the pipeline itself.

Visualize the transparency as a table: each row is a check-in (with its check-in comments), each column is a stage of the pipeline (commit, acceptance, capacity, UAT, production), and each cell shows whether that build passed or failed that stage, and which environment the build currently sits in. One glance answers "where is version 4 right now?" for anyone on the team.

The quick-notice property follows: if you see a problem in acceptance testing, you can immediately find out which change caused it — which particular version of the source code triggered the acceptance test failure — and perform root cause analysis on that code base. Because every build process actually results in stable working software, the scope of the search becomes small. Instead of hunting a bug across the whole system, you look at the one change that entered the pipeline most recently.

Real-world: this traceability is exactly what release tools like Go, Jenkins, and GitLab's pipeline views are built around — and it is the same property that audit and compliance teams rely on: which change, built from which commit, was deployed to which environment, and when. When an incident strikes, the pipeline's trace is the first document pulled.

13.8 Binary Anti-Patterns: Build Once, Deploy the Same Artifact

13.8.1 The Anti-Pattern: Recompiling in Every Context

A commonly seen anti-pattern is dealing with binaries by recompiling the source code repeatedly in different contexts — during the commit process, at acceptance test time, during capacity testing, and often once for each separate deployment target. Organizations tend to build the artifact multiple times for multiple environments.

This is not best practice, because every time you compile the code you run the risk of introducing a difference in your artifact. Why would differences appear?

• The compiler differs. The version of the compiler installed in the later stage may differ from the version used at commit test time.
• The compiler configuration differs. Configuration changes in the compiler may change the behavior of the application.
• The dependencies differ. You may pick up a different version of some third-party library than the one you intended.

Any of these silently changes the artifact. The key word is silently: nothing announces the difference, no test comparison is run — the new binary simply behaves differently from the one that was validated.

And if the artifact differs, how can you say that the artifact which worked on the pre-production environment will definitely work in production? You are not testing the same artifact. That reasoning collapses — the guarantee you want is exactly what this practice destroys.

13.8.2 The Two Principles It Violates

Recompiling at every stage violates two principles.

First, the efficiency of the deployment pipeline: the whole point is fast deployment feedback, and recompiling takes time — on large systems the build process is slow, so feedback arrives late. Each stage that recompiles adds a full build duration to the critical path of every change.

Second, the principle of always building upon the foundation: the binaries that get deployed to production should be exactly the same as those that went through the acceptance testing and all the other test stages. Recreating binaries breaks the link between what you tested and what you ship. The strongest implementations check this link mechanically: the hash of each binary is recorded when the binary is created, and later stages verify that the binary is identical at every step of the process.

13.8.3 The Remedies

The remedies form a short checklist of pipeline hygiene:

• Build your binaries only once, then deploy that same artifact to every environment. The build happens exactly one time, in the commit stage, and everything after that moves the artifact, not the source.
• Use the same release process everywhere: deploying with the same script to production that you use for development environments is a fantastic way to prevent the "it works on my machine" syndrome — where something works in one environment and nobody understands why it fails in another.
• Perform a smoke test of your deployments. When the artifact lands in an environment, immediately verify that it is actually up and running.
• Deploy always into a copy of production — a pre-production or staging environment that is an exact mirror of production.
• Each change should propagate through the pipeline instantly. No scheduled nightly builds; every commit triggers the first stage, and each stage triggers the next as soon as it finishes.
• Have intelligent pipeline scheduling (the topic of the next section).
• If any part of the pipeline fails, stop the line there itself. The whole team owns the failure and fixes it before anything else moves.

Real-world: binary artifact stores like Nexus and Artifactory exist largely to make this practice easy — the artifact is fetched, not rebuilt, at every stage, and its checksum travels with it. In audited industries, the recorded hash of the deployed binary is part of the evidence that what went to production is exactly what passed acceptance testing.

13.9 Intelligent Pipeline Scheduling

13.9.1 The Five-Developer Scenario

Intelligent pipeline scheduling decides when a pipeline stage runs. The scenario that explains it uses one delivery team and five developers.

Developer 1 checks in. The build and unit test stage runs and passes, and the automated acceptance test starts — it is in progress. Meanwhile developers 2, 3, 4, and 5 make more check-ins:

• Developer 2's check-in triggers the build and unit test pipeline, which passes — but it does not trigger the automated acceptance test.
• Developer 3 is the same. Why not? Because the acceptance test is already in progress for the first check-in.
• Developer 4's check-in fails at the build and unit test stage, so it stops there.
• Developer 5's check-in passes its build and unit test.

13.9.2 What If Every Commit Triggers Acceptance Testing?

That student's point deserves its own note: the team always has a backup for every member — if there are issues, they can perform a forced release. But the main answer stands: letting every check-in fire the acceptance test stage burns resources and delays feedback, which is exactly what the pipeline was built to avoid. Each acceptance test run takes minutes to hours of computing time; queueing five of them for five tiny changes delays the last result by four runs, which is the opposite of fast feedback.

13.9.3 The Outcome

Now finish the scenario. By the time developer 5's build passes, the first acceptance test has completed. The acceptance test triggered by the fifth check-in now covers all the changes from check-ins 2, 3, 4, and 5 together — one test run, four changes verified. This is the optimized use of resources and time: you are not executing every stage of the pipeline for every tiny change, and the feedback stays fast. That is the intelligent way of scheduling.

Real-world: in the early days of DevOps, when teams started using Jenkins, Jenkins did not have this intelligent scheduling built into the system — organizations had to configure their pipelines so scheduling worked this way. Today every tool, including Jenkins, ships with intelligent scheduling by default, so the system handles it on its own.

13.9.4 Parallel Pipelines

The clarification matters: parallel pipelines for separate branches are wanted — microservices demand them. Each service (and each branch) can have its own pipeline running its own acceptance tests, and those runs do not compete: they are different tests of different code. What is not wanted is repeatedly triggering the same test stage on the same feature from every small check-in, where the new runs queue behind the old one and the last developer waits for everyone else's runs to finish.

13.10 The Release Plan

13.10.1 When the Release Plan Is Made

A release plan should be ready before you start implementing the application. This was put to the class: are you aware that the release plan exists well before you enter the implementation phase?

So in an agile setup the release plan is born in sprint planning; in a traditional setup it appears during planning and estimation, right after product discovery. Either way, the plan exists before the first line of production code — because the plan determines what gets built (which tests the release must pass, which environments it must travel), and a plan invented after development is a plan that cannot shape the development.

13.10.2 Who Creates the Release Plan

The release plan is created and maintained by everyone involved in the delivery of the software — developers, testers, operations, infrastructure, and support personnel. Operations in particular should give their input on infrastructure: what kind of tools and technology they will need, which version, which operating system to look for. The release notes are part of this planning conversation too.

So the automatic release-note pipeline has three sources: commit messages and task logs, Jira task status, and GitHub's own per-version summary of merged pull requests. The planning conversation decides that release notes are generated from these three, so the notes never depend on someone writing them up by hand at the end.

13.10.3 What the Release Plan Must Cover

The plan must cover several things.

• Automate the process. Minimize the effect of people making mistakes by automating as much of the release plan process as possible — the planning includes what your project must pass: unit testing, capacity testing, integration testing, and so on, and each of those processes should be automated wherever you can.
• Practice the procedure. Practice it often, in a production-like environment, so you can debug the process and the technology supporting it. The rehearsed release is the safe release: the first real release should be the hundredth time the procedure has run.
• Back out safely. Have the ability to back out a release if things do not work out — the rollback must always be in the plan, with three decisions attached: when to roll back, how much time the rollback should take, and what deciding factor triggers it.
• Migrate configuration and data. Have a strategy for migrating configuration and production data as part of both the upgrade and the rollback process. Upgrading the code is only half of a release; the configuration and the data must move with it, and they must move back if the release rolls back.

13.10.4 The Goal: A Completely Automated Release

The goal is a completely automated release process. Releasing should be as simple as choosing a version of the application to release and pressing a button. And backing out — if something is not working properly, returning to the previous version — should be as simple as pushing the new one.

Real-world: this is the structure behind release strategies in industry: the release plan lives inside the release strategy document, covering first deployment steps, smoke-test steps, back-out steps, backup and restore, data migrations, log locations, and monitoring. Teams that rehearse this procedure — often with automated release drills — are the teams that can genuinely ship at the push of a button.

13.11 Smoke Testing and Performance Testing

13.11.1 What Smoke Testing Is

Smoke testing asks how strong the system is. The basic logic comes from the image behind the name: you want to check how strong your system is, so you put a fire rather than just smoke, and you watch how much impact that fire has on your application. One kind of smoke testing uses the monkey tool, which acts as the fire.

The core distinction: in smoke testing you are not validating how well your application works — you are validating how bad it will be if something goes wrong. It is a survivability test, not a functionality test.

13.11.2 How to Perform Smoke Testing

The procedure is direct.

That is the smoke test — a controlled breakage, followed by observation, followed by a check that the automation heals the system.

A note on terminology: the professor's smoke test is a failure-injection test — break a service and watch the system survive. Many textbooks use the same name for a different, complementary practice: a fast post-deployment check that the application is up and running (launch the app, confirm the main screen loads, confirm its dependent services are reachable), which is why the deployment pipeline performs a smoke test after every deployment. Both practices share the same spirit — a quick, rough check of the system's health under stress or after a change — but on the exam, keep the professor's version: smoke testing is the fire test that checks how bad things get when something goes wrong.

13.11.3 Smoke Testing vs Performance Testing

The two get confused, so the boundary is worth stating:

Performance testing measures response — how quickly the system answers, like the time from clicking login to the next page loading. Smoke testing measures survivability — what breaks and how badly when something goes wrong. They are separate practices.

Real-world: this kind of failure-injection testing is how resilience is engineered at scale — the principle that teams deliberately break components in controlled environments (a practice popularized as chaos engineering at companies like Netflix) to find out in advance which failures the system can absorb and which ones it cannot. The monkey tool named in the lecture is one implementation of that idea: a tool that acts as the fire.

13.12 Knowledge Check: CI/CD Fundamentals

A quick knowledge check tested whether the class was in line on the fundamentals of version control, build, and release. These four exchanges are the check and its answers.

13.12.1 Signaling That Code Needs Review

The pull request is the formal handshake of a code change: the developer pushes a branch, opens a pull request describing the change, reviewers see exactly which lines changed and discuss them, and the merge happens only after the review approves it. The word "reviewed" is the point — the technique exists so that no change reaches the repository silently.

13.12.2 Testing and Deploying the Same Asset

The rejected alternatives matter as much as the answer: a pull request reviews the source, not the artifact, so it cannot certify that the deployed binary is the tested one; and "keeping our fingers crossed" is the absence of a mechanism, not one.

13.12.3 Overlapping Changes From Two Developers

The root cause of a merge conflict is not the overlap itself — it is the time the two changes spent diverging. Merging to the trunk often keeps every change small and recent, so an overlap is found while it is still small and both developers still remember their own changes well enough to resolve the conflict by hand. Postponing merges compounds the conflict: the longer the branches diverge, the larger the overlapping surface and the harder the resolution.

13.12.4 Indicators of a Good CI/CD System

The three indicators map directly onto the pipeline outcomes from section 13.7: fast builds feed the fast feedback loop; showing why and where tests fail turns a red status into an actionable message; and supporting the team's own containers and environments means the tool adapts to the team's reality instead of forcing the team to adapt to the tool.

Exam Guidance Summary

• Relative grading: the topper's score sets the top grade — a topper at 80 gets the A grade, and a topper at 95 or above gets A plus; there is no fixed band for A. Below that, the grades are divided across the class by marks — average scorers get B, C, or C minus. Everything is relative to overall class performance. Do not rely on the results portal's percentile: the Webbox results portal is a third-party tool with its own algorithm, and it is not in line with the institute's way of working.
• Comprehensive exam scope: the comprehensive exam covers the full syllabus — the entire course handout is its syllabus. Duration is 2 hours 30 minutes, against the mid-semester's 2 hours, and the question count is higher.
• Copy-paste is a risk: do not copy-paste content in the comprehensive exam. Write your own answers, even if they are wrong or not in perfect language — write your understanding. A lot of copied answers were found in the mid-semester, and that is a risk, not a strategy.
• Mid-semester is mandatory: missing both the regular and the makeup mid-semester is a regret case: the mid-semester is a mandatory component, and if both attempts are missed you will not be allowed to sit the comprehensive exam — and even if you sit it, you must give all the exams again.
• Mid-semester results: a few evaluations were still pending for some candidates; makeup exams take longer to evaluate, and a few students had attachment issues that were under discussion with the operations team. Reevaluation notifications come by mail.
• Expected-answer review (a real mid-semester question): a company is trying to build an MVP and time is essential — which development method is useful, and why is feature-driven development (FDD) not the answer? The expected answer was test-driven development (TDD), because the scenario needs both speed and quality; the one-liner expected was that the team is mature enough to use TDD. A first-time TDD team sees delayed productivity while learning to write test cases first. FDD is picked when you have multiple teams and many members — 50 or more people across different teams — and still want to follow agile. Marks were given to all answers, but that was the expectation. Also note: feature prioritization happens in every agile method — the product owner's roadmap puts higher-priority tasks on top, and some projects pick riskier tasks first — so prioritization alone never justifies choosing FDD.
• Case-study review (a real mid-semester question): a Scrum master is restricting the development team from communicating with the product owner. This is poor agile — the Scrum master should motivate the team to adhere to the proper agile process, not block communication. Resolution paths: reach out to an agile coach, who can revert the issue to the Scrum master; or, as one answer suggested, change the team if political challenges prevent that route. The product owner may be a client business person while the team is technical — even then the team must have the opportunity to talk directly to the product owner whenever needed.
• Sprint length: one-week sprints are not suggested anywhere in Scrum. A one-week sprint gives no chance to look back and understand mistakes — everything is done in a hurry. The ideal range is two to four weeks, not less and not more.
• Quiz and tutorial: a quiz follows the tutorial session; the tutorial covers Maven along with Jenkins. Do the quiz the same day.
• Assessment and assignment guidance: submit the assignment as a document or a recorded video — evaluation works with proper screenshots, and a recorded video shows each and every step; a written document is fine for those who prefer writing. Marks take about two to three weeks after upload, and you will see them before the comprehensive exam. Create your repository with your BITS ID for a more authenticated submission; if you use a personal account, make sure your name (not a fancy alias) identifies you. You may take an alternative approach to any task, but document in your submission why you used a given command and why the alternative is more efficient. Show a master branch plus two feature branches, raise a pull request into the master branch, and show both approved and rejected scenarios. Production deployment is not possible in this setting, so deploy to UAT instead — with two virtual machines you can treat the first as the UAT environment and the other as production. You need only Git Bash to run it locally, or you can use the CSIS virtual lab: log in to the ELN portal with your BITS SSO, book a slot for the DevOps course, confirm it, and connect with the provided RDP client, where the tools are already installed.

Key Industry Applications

• Real-world: GitHub as the source code management repository — the commit-stage trigger for the whole pipeline, and the home of pull requests; GitHub also auto-generates per-version summaries of merged pull requests.
• Real-world: Jenkins as the CI/CD automation server — the classic example used for integration pipelines, and the tool whose history illustrates intelligent pipeline scheduling (absent in early versions, built in today).
• Real-world: Maven alongside Jenkins in tutorial practice — build and package Java projects as part of the pipeline flow.
• Real-world: artifact repositories as the storehouse of the single artifact that every stage tests and deploys — the mechanism that guarantees you test exactly what you ship.
• Real-world: deployment targets in practice — local servers in the organization, cloud platforms, and virtual machines; the toolchain a team chooses depends on the platform, which is the fourth deployment consideration.
• Real-world: configuration as code and infrastructure as code — environments and their configuration kept in version control, scripted and reproducible, instead of hand-configured machines.
• Real-world: smoke testing with the monkey tool, and monitoring plus configuration management systems that automatically heal broken services after a controlled failure.
• Real-world: e-grocery applications as a running case study — signup schema evolution across versions, monthly purchase-report features, and login response-time measurements in performance testing.
• Real-world: virtual labs for hands-on practice — the CSIS virtual lab reached through the ELN portal, booked by slot, accessed with the BITS SSO login and an RDP connection, with the toolchain preinstalled.
• Real-world: Jira task status feeding release notes, plus commit-message and task-log aggregation, as the practical way release notes get generated during the deployment process.