Continuous Integration Best Practices and CI/CD Pipelines

11.1 Recap: The CI Best Practices Covered So Far

11.1.1 Where We Left Off

The previous session covered the prerequisites for continuous integration and then started the list of best practices. Two of those practices are already on the table, and they set the tone for everything that follows:

• Keep the build and test process short. A short build-and-test loop gives fast feedback. When a check-in breaks something, you find out quickly, while the change is still small and easy to trace. The longer the loop, the more code piles up between a mistake and its discovery. This is not a vague preference: the standard guidance is that the pre-check-in build and the commit-stage build should each run in at most ten minutes, with about five minutes as a comfortable target and ninety seconds as the ideal. Once the loop grows beyond that, real behavioral damage shows up: developers stop running the full build before checking in, they check in less often (because nobody wants to sit around waiting for a long build), and several commits pile up between two builds, so nobody can tell which check-in broke the build. A short loop also makes reverting cheap, because the last known-good revision is only minutes old.
• Manage your development workspace like a production environment. Treat your local workspace as the equivalent of a production environment. The point is that what works locally should be what works when the code ships, so your local setup has to mirror production closely. The practical version of this rule is to use the same automated processes on a developer machine that the continuous integration server and production use: the same build script, the same test commands, the same deployment steps. When teams skip this, they get the classic "it works on my machine" syndrome — the code passes locally and fails everywhere else, because the local database, middleware, or configuration silently differs from every other environment. Careful configuration management is the supporting discipline: source code, test data, database scripts, build scripts, and deployment scripts all live in version control, and the starting point for any new work is the latest known-good revision — the one that passed all automated tests on the CI server.

Real-world connection: The payoff of these two practices at scale is not hypothetical. HP's LaserJet firmware division ran with roughly four hundred developers across the US, Brazil, and India, and before continuous integration was adopted, only about 5% of their time went into new features — the rest was absorbed by branch management, manual testing, and planning. After they committed to trunk-based development, heavy automated testing, and a shared build, the team went from about twenty commits per day performed by a single "build boss" to over one hundred commits per day by individual developers, and time spent on innovation rose from 5% to 40% of developer time. The first step on that road was exactly what these two practices describe: a fast, automated build-test loop running against a common, production-like setup.

11.2 Don't Check In on a Broken Build

11.2.1 The Rule and Why It Exists

The next practice is don't check in on a broken build. The very first intention of introducing continuous integration was to keep the application always in a stable, workable state. If a committed change fails the build, the product is no longer in that state. Checking in more code on top of that broken build directly violates the first rule of keeping the application always in a working condition.

This rule is called the cardinal sin of continuous integration in the literature: when a build breaks, the developer responsible is expected to be right there, fixing it. Anyone else checking in during that window triggers new builds on top of a known-failing state, muddies the water, and makes the fix harder — the exact opposite of what the team needs. The rule protects not just the code base but also the person trying to repair it: they need a clear run at the problem, not a stream of new commits compounding the failure.

11.2.2 What Goes Wrong When You Do

The professor walks through three concrete consequences of committing on a broken build:

1. You are growing the code base on an unstable product. The application is not in a working state, and you are adding new code on top of it. Each check-in makes the broken foundation larger. In the building-site analogy, you are not just piling floors on a cracked foundation — you are also making it harder to find which slab is cracked, because the rubble is now bigger.
2. The fix takes much longer. If a new check-in or build trigger happens during the broken state, your code base has already increased. Finding out where the problem was triggered, isolating that issue, and fixing it across a larger code base will definitely take more time. The failure was cheap to fix at the moment it happened — a two-line mistake in the change that broke the build — but it becomes expensive once ten more commits sit on top of it, because the failing change is buried under unrelated work.
3. The team stops caring. Frequent broken builds encourage the team not to care much about the working condition of the application. The discipline that CI is supposed to create quietly erodes, and the stable-state rule becomes a memory. This is the most dangerous consequence of the three: once a red build is normal, developers stop reacting to it, the build stays red for days, and CI degenerates into a notification service for a product that never works.

There is a second, practical benefit hidden in this practice: traceability. Because every change flows through the pipeline, you can easily audit which commit failed a particular build and who made that commit. Everyone can be traceable. This audit trail is a core reason the pipeline exists at all — if you see a problem in any later stage, you can immediately find which check-in caused it, because every build is tied to the revision that produced it.

Real-world connection: The strictest teams in the industry treat a broken pipeline like a stopped production line. In the HP LaserJet example, the group created a culture that halted all work the moment a developer broke the deployment pipeline, so the system was brought back to green fast. The T2 and R2 reference texts put the same idea in the form of a universal team rule: if any part of the pipeline fails — even a deployment to an environment — the whole team owns that failure, and they stop and fix it before doing anything else. That is consequence three turned upside down: instead of the team learning to tolerate red, the team learns that red halts everyone, so fixing it becomes the highest priority on the project.

11.3 Commit Locally, Then Let the Pipeline Carry It to Production

11.3.1 The Pipeline Path

The practice is commit locally, then direct to production — which is really a rule about never adding code directly to production. Code should always travel via the proper pipeline:

1. Commit locally on your machine.
2. Push to the GitHub repositories (the source control system).
3. Continuous integration triggers automatically and runs the subsequent process: build process, testing, continuous code inspection, and continuous testing on different environments.
4. The pipeline then pushes the result to production.

Every small commit and every small change should follow this same process. There is no shortcut route from an editor straight into production. Notice what the practice does not say: it does not say "commit directly to production," and it does not say "push to production yourself." Your machine is the starting line of the journey, not the destination — you commit locally, and from that moment the pipeline owns the trip.

Think of the route as a one-way street with a single gate. Every change, whether it is a one-line typo fix or a new feature, queues at the same gate, passes through the same checks, and arrives in production only when the checks say it is fit. There is no staff entrance, no window to climb through, and no exception for urgency — the gate does not know or care how urgent the change is.

11.3.2 Why Every Commit Takes the Same Route

The reason for this uniformity is that the pipeline is the only place where the build, the tests, and the inspections happen in a controlled, repeatable way. If one commit were allowed to bypass the pipeline, the stable-state guarantee would be gone, and nobody would know what actually made it into production and under what conditions it was tested.

The uniformity also preserves the audit trail from the previous section: because every change is carried by the pipeline, every change is traceable. If a production incident is later traced to a specific build, you can walk backwards — which pipeline run produced that build, which commit started it, and who pushed it — instead of guessing which of several ad-hoc routes the change may have taken.

Real-world connection: Delivery teams model this journey with a value stream map — a chart of everything that happens to a change between "concept" and "cash," showing both the working time and the waiting time at each step. The pipeline portion of that map, from check-in to release, is deliberately automated so that builds pass through it many times, gaining confidence at each gate. In the reference literature, the pipeline is described as "an automated manifestation of your process for getting software from version control into the hands of your users" — and the whole point is that every change, urgent or not, takes exactly that path, which is what makes the process repeatable enough to trust.

11.4 Wait for the Commit Test to Pass Before Moving On

11.4.1 The Check-In Owner Watches the Build

The next practice is wait for the commit test to pass before moving on. At the time of check-in, the particular team member who checked in the code is responsible for monitoring the build progress. The rule is blunt: never go home with a broken build. Monitor the progress, and if the build is broken, take the subsequent actions — which we get to in the next section.

The level of attention this practice expects is specific. While the commit-stage build for your check-in is running, you are not free to begin a new feature, walk out for lunch, or sit in a meeting — you stay close enough to know the outcome within seconds of the build finishing. The commit stage is designed to run in minutes precisely so this is practical: the wait is a short one, and the feedback is worth it. If the commit succeeds, and only then, you are free to move on to the next task. If it fails, you are on the spot, with the fresh context still in your head, ready to determine what went wrong.

11.4.2 Why Ownership Matters

This practice assigns accountability to the person who caused the change. The author has the freshest context about what they changed, so they are the best person to react the moment a build fails, instead of leaving the discovery to someone else the next morning.

Real-world connection: This ownership rule scales directly to very large organizations. At Google, any developer's commit runs against suites of hundreds of thousands of automated tests; if the change passes, it merges into trunk automatically, and if the pipeline breaks, engineers are expected to fix it right away because nobody else can commit while it is red. Google's engineers describe the informal pact behind it: everyone knows that one day they will break someone else's project by accident, and the next day they may be the one broken — so the person who caused the failure is the person who stays with it until it is green.

11.5 Always Be Prepared to Revert

11.5.1 When to Revert

The last of the four new practices is always be prepared to revert to the previous revision. If, due to some constraints or issues, the build got broken and the team does not know the exact solution at that moment, it is always good to come back to the previous version and keep the application in a working state rather than leaving a broken build sitting there.

Notice the two conditions in the rule. First, the build is broken. Second, the team does not know the exact solution at that moment — not "the fix is impossible," just "the fix is not in reach right now." Under those conditions, the decision is already made: return to the previous revision, which you know is good precisely because the team's discipline (section 11.2) means nobody checked in on top of a broken build, so the previous revision is the last verified-green state. Reverting is what version control exists for; a revision control system that gives you the history of every change is also the tool that lets you step back to any point in that history.

The preparation part of the practice matters as much as the action: be prepared. You should know, before the failure happens, which revision the team will revert to, and whether your uncommitted local work can be preserved through the rollback. A team that decides on the revert strategy while the build is already broken is a team that will hesitate, and hesitation keeps the application in a broken state longer.

11.5.2 Reverting Is Not Giving Up

Reverting is a temporary fallback, not a defeat. The broken changes do not vanish — they stay in the developer's local system — and the team keeps a shippable state while the problem is investigated calmly. The next section shows exactly when reverting is the right call, and the section after that shows how a team avoids living in revert mode forever.

Real-world connection: Automated pipelines make reverting almost free in practice. When deployment and release are automated, stepping back to an earlier version is exactly as easy as stepping forward — the worst case is that you find a critical bug in the new release, at which point you revert to the earlier version that does not contain it while you fix the new release offline. Google's release engineers make rolling back easy on purpose, because when the pipeline is broken, developers can no longer commit; the fastest way to unblock the team is a clean rollback, not a heroic overnight fix.

11.6 The Friday 5:30 p.m. Broken-Build Scenario

11.6.1 Three Options on a Friday Evening

Now we apply the practices to a realistic scenario. It is Friday, 5:30 p.m. — the end of the work week, and the weekend is about to start. You are on the verge of going home, and the commit you just made got broke: the build failed. You have three options:

1. Stay late and try to fix it — fix first, go home after some extra timeline.
2. Revert the changes — roll back to the previous working revision.
3. Leave the broken build — go home and deal with it on Monday.

When asked which option to pick, the class converged quickly: revert. One student noted that fixing takes time, so revert; another said revert immediately — that is what is followed; another said it depends on the use case, but revert seems fine. The professor agreed with all of them: in this scenario, revert the changes and go home.

11.6.2 What Happens If You Leave It Until Monday

Why is leaving the broken build so bad? Walk through the weekend:

• Say Saturday and Sunday you had some function at home, or a plan to go out somewhere. By Monday your memory is no longer fresh on what exactly you worked on Friday.
• It will then take significantly more time to understand the problem and fix it.
• Everyone will yell at you at the workplace. And if, by any chance, you get late on Monday, you should be ready to answer any number of calls from other team members, because they all know the build is broken.
• Thanks to the pipeline, the audit is easy: you can find out because of which commit this particular build failed and who did that commit. Everyone is traceable.
• And not the least: your name will be in mud. People will yell at you and conclude that you just work incorrectly and do not follow the best practices.

11.6.3 Staying Late vs. Check-In Early

What about option one — staying late to fix the build after working hours? The professor does not recommend it: extending work hours is a bad habit, and once you get that habit you ultimately lose your personal time, including family time. His own preference is clear — it is not his cup of tea; whatever the justification, he would rather not be in a position of staying late to fix issues.

The preventive rule that makes staying late unnecessary: check in early so you can have helping hands around. If a problem shows up while teammates are still present, you can dig into the issue together. Concretely, make a rule of checking in no later than one hour before you end your work. For example, if 6 p.m. is your end timeline, your check-in should be completed before 5 p.m.; after 5 p.m. you should not check in.

And even with a broken build at the end of the day, the best solution in this scenario is to revert in your source control: go to the previous version, keep the previous version active, and all the changes you made stay in your local system, ready to be fixed with fresh context tomorrow.

11.6.4 A Note on Flexible Work Hours

The professor also shared a personal stance on work-hour tracking, because it connects to how teams think about check-in discipline. Some people hate swipe in and swipe out, arguing that what matters is the work you deliver, not the hours you pass in the building. One experienced engineer described a workplace where there was no swipe system for him at all — he had a great bond with his manager, checked in late whenever comfortable, completed his job, and approved around 20 to 25 days of time cards each month. He later moved to a company that also had no swiping; the month they introduced swipe in and swipe out, he switched jobs the next month. His takeaway: how you like to work, and how your workplace treats that choice, varies a lot — but the pipeline rules themselves stay the same regardless of your hours.

11.7 The Time-Boxing Rule: Revert Smartly, Keep Progress

11.7.1 The Question That Drove the Rule

There is an obvious objection to "always revert": if everyone just follows revert blindly — revert, revert, revert, every time — how can the team ever make progress? One student jokingly suggested the answer is to find a new manager; the professor laughed and admitted his own history puts him in exactly that category of frequent reverters. But the serious answer is the time-boxing rule.

11.7.2 The 10-15 Minute Time Box

Whenever a build fails, the team should first try their level best to fix the issue within a fixed timeline of about 10 to 15 minutes. If, within that time period, there is no scope and no chance of getting it fixed, then — and only then — go ahead and revert to the previous version. This should be a universal rule in the team: first the time box, then the revert.

The rule has two halves, and both halves are mandatory. The first half forces an attempt: before any revert, you genuinely try to fix the failure, and you give that attempt a bounded window of roughly ten to fifteen minutes. The second half caps the attempt: when the window closes without a fix, you revert — you do not extend the window "just five more minutes" indefinitely. Ten minutes is a deliberate size: it is enough time to land the small fixes that are actually easy (a one-line correction, a missed import, a wrong flag), and short enough that a genuinely difficult problem cannot consume the afternoon.

11.7.3 Why the Rule Works

The time box gives every failure a small, honest attempt at a real fix, so the team does not lose the habit of solving problems — and the revert caps the damage when the problem is beyond the current context. Progress happens in two ways: fixes that are achievable in minutes land, and everything else rolls back cleanly so the next attempt starts from a working state. This is the practice that keeps "be prepared to revert" from turning into "never fix anything."

Real-world connection: The reference literature states the same rule almost word for word as a recommended team rule: when the build breaks on check-in, try to fix it for ten minutes; if you are not finished after that, revert to the previous version from your version control system, with a little leeway only if you are mid-way through a local build that may already contain the fix. Large organizations institutionalize the "first the time box, then the revert" pattern through gated commits — the pipeline refuses to accept a change that does not build and pass tests — so the discipline is enforced by the machine instead of by willpower.

11.8 The CI/CD Pipeline: A Generic Four-Phase Flow

11.8.1 The Big Picture

With the best practices done, we move to the generic CI/CD pipeline concept — the mental model behind all of it. The one-line picture: you need a source code, a continuous integration system, and a path to production. The continuous integration software pushes the code to subsequent staging, acceptance testing, or functional testing environments; if every test conducted there gives a result of green — a pass — your code moves to the production environment. That final move is what we call continuous deployment.

The whole journey, in one pass:

IDE (write code)
         │ commit
         ▼
      pre-commit unit test ──fail──► go back, refactor
         │ pass
         ▼
      source code management (GitHub)
         │ push triggers CI automatically
         ▼
      compile ──► code inspection ──► quality gate ──► subsequent testing
                                                        │
                                                        ▼
                                              artifact repository (store the package)
                                                        │
                                                        ▼
                           same artifact through functional / UAT / end-to-end testing
                                                        │ all green
                                                        ▼
                                              production deployment

This single picture contains four concepts, each of which is one phase of the flow: continuous integration (phase 2 — everything between the commit and the stored artifact), continuous delivery (phase 3 — testing that same artifact through the next environments), and continuous deployment (phase 4 — the automatic push to production), with phase 1 being the developer's own local write-commit-unit-test loop. In the reference model of the deployment pipeline, these same stages appear as the commit stage (compile, unit tests, code analysis, build installers), the automated acceptance test stages, and the release stage — the pipeline is "an automated manifestation of your process for getting software from version control into the hands of your users."

11.8.2 Phase 1 — Write, Commit, Unit Test

The first phase starts with the developer writing code in any IDE — Visual Studio or any other you like. Then the developer commits that code. Once they commit, the pre-commit test happens, which is your unit test in this case:

• If the unit test fails, the developer has to go back and refactor the code to clear that unit test.
• If the unit test passes, the developer pushes the code to source code management (the source control repository).

This phase is deliberately the developer's own loop: the unit tests are fast enough to run locally, so the cheapest place to catch a problem is here, on the developer's machine, before anyone else sees the change. A unit test (a test that checks one small piece of the application in isolation — a single function or a small group of them, without the database, filesystem, or network) is the right tool at this stage because it runs in seconds. The commit-stage test suite in the reference model has the same shape: fast, primarily unit-level tests that the developer also runs before checking in.

11.8.3 Phase 2 — Continuous Integration: Compile, Inspect, Gate, Test

Once the code commit has happened, the continuous integration pipeline triggers automatically. Its steps, in order:

1. Compile the code.
2. Code inspection — check whether any code-level defects are present.
3. Quality gate — if all threshold values are intact with this new code commit, the quality gate gives a green pass. The quality gate is the guard that decides whether this change is healthy enough to move forward.
4. Subsequent testing — functional testing, capacity testing, or whatever testing is part of your project.
5. Store the artifact — the package that got built is stored in an artifact repository.

This is the core continuous integration phase: the machine compiles the committed code, inspects it for code-level defects (duplicated code, security warnings, complexity, test coverage), checks the quality thresholds, runs the project's tests, and — only if everything is green — saves the produced package, the artifact, into an artifact repository such as JFrog. Note the word "automatic": no human triggers these steps; the commit itself triggers them. The quality gate deserves special attention because it is the guard: it holds the threshold values (for example, "test coverage must not drop below 80%" or "no new critical defects"), and a commit that breaks a threshold fails the gate even if every test passes.

11.8.4 Phase 3 — Continuous Delivery: Test the Same Artifact

The third concept is continuous delivery: the same artifact that was stored in the artifact repository should go further and follow the testing on the next environments — functional testing, user acceptance testing, and end-to-end testing. The word "same" matters: you do not rebuild between environments; the identical package travels through each test stage.

11.8.5 Phase 4 — Continuous Deployment to Production

The fourth and last concept: if all testing is clear, that particular increment is pushed to the deployment production environment. That is continuous deployment — the automatic release of a fully tested increment.

The distinction between phases 3 and 4 is where many students lose marks. Continuous delivery means the tested artifact is ready to go to production — the team can release at any moment, and often a human presses the final button. Continuous deployment means the release itself is automatic: when the tests pass, the increment goes to production with no manual step in between. In this lecture's generic flow, phase 3 ends with the same artifact proven green across functional, UAT, and end-to-end testing, and phase 4 is the automatic push that follows.

11.8.6 The Whole Flow in One Pass

So the generic flow is: IDE → commit → pre-commit unit test → source code management → automatic compile → code inspection → quality gate → subsequent testing → artifact repository → same artifact through functional, UAT, and end-to-end testing → production deployment. This is the generic workflow people generally opt for, and it is the mental picture to carry into the exam.

Real-world connection: This generic flow is the pattern that real delivery teams reproduce with different tooling: a commit stage that compiles, unit-tests, analyzes, and assembles binaries; automated acceptance stages that exercise the same binaries in production-like environments; and a release stage that deploys them. Modern CI servers visualize exactly this — every check-in down one side, every pipeline stage it passed or failed, so a problem in acceptance testing can be traced to the precise commit that caused it. Whether the deployment target is a hosting server, Kubernetes, Docker, or a cloud platform, the four-phase shape is the same; only the tools inside the stages change.

11.9 Pipeline Variations by Application Type and the Tool Landscape

11.9.1 Web Applications

If you are building a web application, you typically need a CI server such as Jenkins, and your acceptance tests should follow on browsers, because a web application depends on different browsers. The testing tools differ from other application types, but the CI backbone is the same.

A web app is judged by how it behaves in the user's browser — Chrome, Firefox, Safari, Edge — and each browser can render and execute the same page differently. So the acceptance tests for a web application are browser-driven: the tests drive the application through real browser sessions, catching layout and behavior differences that a headless check would miss. The CI server that runs those tests is the same Jenkins (or any CI tool) used everywhere; what changes is the test tooling attached to it.

11.9.2 Mobile Applications

For mobile applications, you want to run this testing on physical mobile devices rather than browsers. The testing approach will be different and the coding approach will be different, but continuous integration stays the same: the same CI server (Jenkins, for example), with different tools and technologies used to perform those subsequent tests.

A mobile app depends on the physical device — its operating system version, screen size, memory, and sensor behavior — so the honest test environment is a device, not a desktop browser emulation. The CI backbone does not care: the same server triggers the same build on every commit, and the same stages (compile, inspect, gate, test, store artifact) run with mobile test tools swapped in for browser tools.

11.9.3 Microservices and Containers

For a microservice-based solution, you definitely introduce the Docker container — containerized solutions — and deployment happens on either Docker or Kubernetes, because your solution is a microservice and you want to deploy it into a containerized environment. Again, continuous integration can be the same and the source code repository can be the same; only the deployment and testing technologies differ. This is the generic pipeline for microservices on Kubernetes. If you are working with Azure — cloud solutions with a microservice architecture on Kubernetes — this is the generic scenario to picture.

A microservice (a small, independently deployable service that handles one piece of business functionality and talks to other services over a network) is packaged with its own runtime into a Docker container — a lightweight, self-contained package holding the service and everything it needs to run. Kubernetes (the container orchestration platform that schedules, scales, and manages those containers) is the deployment target for containerized microservices. The pipeline itself is unchanged: same CI server, same repository, same commit-stage stages. What differs is the last mile — instead of deploying a binary to a hosting server, the pipeline builds a container image, stores it, tests the same image, and deploys it into a Kubernetes cluster.

11.9.4 Tools at Each Stage

The tool landscape for the whole pipeline, as covered:

• Continuous integration / build: Jenkins, Bamboo, CircleCI, TeamCity — pick whichever you are comfortable with; one or two names are enough in an answer.
• Artifact repository: JFrog — one student confirmed it is the artifact repository in their setup, and that is correct.
• Code inspection: SonarQube — used to inspect code-level defects.
• Continuous feedback: Slack, Outlook, and similar tools.
• Deployment targets: a hosting server, Kubernetes, Azure, AWS with S3 buckets and EC2 instances, Docker, or any other cloud platform.

Real-world: this slide-level landscape is exactly how real teams split the pipeline — the CI server, the artifact store, the inspection tool, and the deployment target are independent choices per project. AWS S3 (Amazon's object storage service) often holds build artifacts or static assets, while EC2 (Amazon's virtual servers) hosts application instances; these are interchangeable pieces in the deployment-target slot, not fixed requirements.

Real-world connection: Containerized microservices on Kubernetes is the default architecture for modern cloud teams — the reference text's description of a deployment pipeline that runs whole applications in production-like environments maps directly onto this scenario, with Docker images playing the role of the "binaries" that are built once and promoted unchanged through every environment. The independence of the tool slots is what makes the ecosystem flexible: an organization can keep Jenkins and JFrog while moving its deployment target from a hosting server to AWS, without redesigning the pipeline.

11.10 Last Year's Paper: Keeping the Application in a Releasable State

11.10.1 The Question

We now walk through last year's question paper, question by question. The very first question: "The team is interested in keeping the application in a releasable state. The team has created branches to develop different features. What are the techniques one can use in such a situation to keep the application in a releasable state?"

This question carries a specific structure that the examiner chose deliberately: the situation is given (branches exist, one per feature), the goal is given (a releasable state), and the ask is for techniques — named practices, not vague good intentions.

11.10.2 The Clarification: Releasable, Not Just Working

The professor paused the class here for a terminology correction: he was not asking about a working state. He wanted a releasable state. The distinction is meaningful — an application can work and still not be fit to release; the question asks for the practices that keep the product always ready to ship.

11.10.3 Student Attempts and the Missing Term

The class offered plenty of correct concepts: pull requests and merging into the code base, regression testing before releasing from master, quality gates, frequent commits, automating the build process, keeping master stable, updating the master branch with every production release, and testing each feature fully. All of these ideas are right — and that is exactly the trap of this subject: whatever you write, it feels connected to the answer, but the examiner wants a best practice, a proper word. The word nobody said: branch by abstraction.

11.10.4 The Three Techniques

The course covers three related techniques for keeping the product releasable:

1. Branch by abstraction — develop each feature on its own branch; keep master stable and merge only fully tested code. This is the fit for the question, because the team already created branches.
2. Feature toggle — functional-level hiding: ship the code with the feature hidden behind a switch until it is ready to be exposed.
3. Small releasable pieces — break a requirement into such small components that every piece is independently releasable.

11.10.5 How to Write the Answer

Real-world connection: The reference treatment of branch by abstraction describes it as the alternative to version-control branching for large-scale change: instead of merging a giant branch back at the end, you create an abstraction layer over the part to be changed, build the new implementation beside the old one, switch the abstraction to the new implementation when ready, and remove the old code. Teams like the ones that wrote the T2 and R2 texts use this pattern precisely to keep the application releasable while replacing large chunks of it — the same goal the exam question tests, and the reason the practice name, not just the idea, is what earns the marks.

11.11 Last Year's Paper: Compiling at Every Environment

11.11.1 The Question

Question two: "You joined a team where the source code is getting compiled at the development environment for unit test, the UAT environment for user acceptance testing, and then at the staging environment for the final system test. What is the problem with the current process? How can you improve it?"

Note what the setup describes: three environments — development, UAT (user acceptance testing, where users verify the software meets their needs), and staging (the environment that mirrors production) — and at each one, the source code is compiled again. The question asks you to name the problem this creates and to propose the improvement.

11.11.2 Why the Current Process Is Slow and Risky

Students spotted the issues quickly: it is platform dependent and it is time taking. The professor sharpened both points:

• Time to market suffers. Every time, for all subsequent testing on subsequent environments, you are rebuilding the code. Building takes time, and each rebuild delays your time to market.
• Every build creates a different artifact. Whenever you compile code on a different environment, factors intervene: the compiler versions in use, any changes in libraries, and changes in binaries. Compatibility issues will occur between environments.
• Confidence drops. How can you bring confidence to your team members that the code will definitely work on the production environment if it was never tested as the exact thing that will ship? If you do the testing on the same artifact that will be deployed, that pushes confidence that this particular code will work even on the production environment.

11.11.3 The Fix: Build Once, Promote the Artifact

The proven way: pack the code as an artifact once, and let the same artifact face each subsequent environment — UAT and staging included. You compile once, store the artifact, and test that same artifact in every environment, then promote it toward production. This is the concrete expression of the continuous delivery phase of the pipeline.

"Promote" is the operational word: the artifact does not get rebuilt or repackaged between environments; it is promoted — marked as passing each stage and moved to the next. This is exactly the "same artifact" rule from section 11.8: the package that passes user acceptance testing is byte-for-byte the package that later reaches production, so the testing evidence applies to the shipped product. If a difference ever sneaks in between environments (a recompiled jar, a different dependency resolution), the promotion chain is broken and the confidence argument collapses.

11.11.4 Five Supporting Points for the Answer

When answering "how can you improve it," any five of the following points will do, with two to three lines per point:

1. Build once and promote the same artifact through the environments (the core answer).
2. Increase collaboration and remove waste — that in itself accelerates the timeline.
3. Code inspection — code-level defects get easily addressed early.
4. Automated testing — reduces the time to market.
5. Continuous integration and continuous delivery as the overall process.

Real-world connection: "Only build your binaries once" is a named practice in the deployment-pipeline literature, and real pipelines enforce it mechanically: binaries are created in the commit stage, stored with their metadata, and reused without re-creation at every point of use, with hash checks verifying that the promoted artifact is identical at every stage. The practice exists precisely because the textbook authors have seen bugs reach production from every one of the differences the professor listed — a different compiler version in a later stage, an unintended third-party library version, even a compiler configuration change.

11.12 Last Year's Paper: Technical Debt and the Quality Gate

11.12.1 The Question

Question three: "An organization has not yet implemented all DevOps practices. The team identifies the problem of increasing technical debt. Which DevOps practice will result in reducing the technical debt, and how?"

Technical debt is the build-up of shortcuts and deferred quality in the code base. The term comes from Ward Cunningham, one of the creators of the wiki, who described it this way: when a team does not aggressively refactor its code base, the code becomes more difficult to change and to maintain over time, slowing down the rate at which the team can add new features. Like financial debt, it feels free at the moment you take it — the shortcut lets the feature ship today — but it accrues interest: each subsequent change now has to work around the shortcut, understand its mess, and spend extra effort that a clean code base would not demand.

11.12.2 The Answer: Code Inspection with Thresholds

The answer is code inspection — and under code inspection you mention your quality gate check. The practice that keeps debt in check is measuring it and refusing to let it grow.

Here is the mechanism, precisely: provide a threshold value for the quality gate — for example, technical debt should not be increased by so-and-so percentage. If a new code commit increases the debt beyond that threshold value, the quality gate fails it. The gate stops the change, and your team has to fix the debt first before the commit can move forward. This turns "we should reduce debt someday" into an automatic, per-commit guardrail.

Real-world connection: The quality gate is a daily, working mechanism in real pipelines. Code inspection tools (SonarQube being the best-known example) continuously report metrics such as test coverage, duplicated code, and maintainability, and CI servers treat violations of preset thresholds exactly the way they treat a failing test — the commit stage fails. The HP LaserJet story shows why this matters at scale: teams stuck in technical debt spend 20% of their time on detailed planning and 25% on porting code between branches, leaving only 5% for new features; a gate that refuses to let the debt grow is the precondition for ever escaping that ratio.

11.13 Last Year's Paper: Will AI and ML Aid DevOps?

11.13.1 The Question

Question four: "DevOps progress will be aided by AI and ML — do you agree with the statement? Write down two technical points that show why you agree or disagree." The professor clarified that this is not about MLOps as a discipline — it is asking whether AI/ML solutions change the way DevOps helps.

Read the question carefully: it is not "is MLOps a thing?" and not "compare AI and DevOps." It is a yes/no opinion question with a specific format — take a position and back it with exactly two technical points. The professor's clarification matters for the answer: you are arguing that AI and ML solutions change how DevOps helps — the automation and infrastructure that DevOps provides become the enabler for ML workloads.

11.13.2 Two Technical Points for Agreeing

The class agreed, and the professor assembled the technical arguments:

• AI/ML needs huge computational power. ML workloads demand more servers and more computational speed. Cloud as a catalyst — a topic already covered — matters here: with cloud you do not have to depend on ordering a server and waiting for it. ML is absolutely a research topic; there is a high chance that whatever work has been done has to be discarded. Waiting a long time for infrastructure that might be thrown away is not a solution.

• ML needs lots of automation. The action still has to come from the human end; for prediction we can use ML. But building, training, and evaluating models is automation-hungry, and that is exactly what DevOps practices deliver.

11.13.3 MLOps: A Different, Multi-Level Pipeline

The professor closes the loop: this is why people have opted for DevOps practices for ML solutions — that is what we call MLOps. In MLOps, ML does follow a CI/CD pipeline, but the terminologies and technologies are different, and the pipeline is multi-level: it is not a single, straightforward pipeline. The extra levels reflect the extra stages an ML solution has — data, training, evaluation, and model deployment, on top of ordinary code.

Real-world connection: MLOps is now a standard practice in industry: machine-learning teams version their data alongside their code, run training and evaluation as pipeline stages, and deploy models through the same gate structure as any service — but with extra stages for dataset validation, retraining triggers, and model-performance checks. The multi-level shape the professor describes is exactly what real ML platforms look like: a model pipeline (data → training → evaluation → deployment) that sits on top of the ordinary software pipeline, each level with its own tooling and its own gates.

11.14 Last Year's Paper: The Top Ten DevOps Tools

11.14.1 The Question

Question five is direct: "List the top ten DevOps tools and highlight and explain the tools." The professor's guidance: pick any three tools for continuous integration and explain how CI helps, then cover continuous monitoring, then continuous feedback.

The question is open by design — "top ten" is not a fixed list, and no specific tool is mandatory. The professor's structure makes the answer easy to organize: three CI tools with a line of explanation each, one monitoring tool, one feedback tool, and the supporting explanation of how each helps. Ten names is the count; the categories are the marks.

11.14.2 Continuous Integration Tools

Any three CI tools work — Jenkins, CircleCI, TeamCity, Bamboo are all acceptable names. For each, explain how continuous integration helps: the automatic build and test of every commit keeps the application in a working state and gives fast feedback.

11.14.3 Monitoring and Feedback Tools

For continuous monitoring, name your monitoring solution of choice. For continuous feedback, you can mention Slack or Teams. Even your GitHub integration counts: automating GitHub to integrate with your Slack or with your email will quickly give you the notification when your review comments are in — for example, whether your merge request was approved or not, and what comments you have received. You can immediately get that feedback instead of polling for it.

The mechanism worth explaining: continuous feedback is the automatic delivery of results to the people who need them. Without it, a developer must go check the CI page, poll the repository, or ask a teammate whether the review is done. With it, the notification arrives — a Slack message when the build turns red, an email when the merge request is approved, a Teams message with the review comments. The tool category exists precisely to close the loop that CI opens: CI produces the result, and feedback tools deliver the result to the human who must act on it.

Real-world connection: The feedback loop this question describes is how modern teams actually work: GitHub webhooks push merge-request events into Slack or email, so a developer gets notified the moment a review comment lands instead of checking the page repeatedly. Large organizations treat these integrations as part of the pipeline itself — the reference texts describe build status sent to lava lamps, wall monitors, and messaging channels, all serving the same goal: everyone can see the state of the build at a glance, and the people who must react are told the moment action is needed.

11.15 Last Year's Paper: Forty Engineers, Syncing Binaries and Libraries

11.15.1 The Scenario

Question six: "A 40-engineer team at a company is frequently facing sync issues of their product development binaries and libraries, as most of them are working on their local environment. You are a DevOps consultant. Address the above statement." Early student guesses were off-target: big team merge conflicts, "continuous integration is needed," "use Maven to align." The professor redirected: this is not related to continuous integration and not related to code review. It is strictly related to the binaries and libraries on which your application depends.

The redirect is the heart of this question: the phrase "most of them are working on their local environment" is the clue, not the merge conflicts, not CI, not code review. A binary is the compiled, executable form of a program or library (a jar, a DLL, an executable); a library is a package of reusable code that the application depends on. The question is about how those artifacts are managed across machines.

11.15.2 The Real Problem: Manual Dependency Management

The problem is that the team is managing binaries and libraries manually, locally, per engineer. Each engineer's local environment drifts, and sharing the right versions of every dependency — including transitive dependencies (the dependencies of your dependencies) — breaks down. That manual management is exactly why they keep facing sync issues.

A dependency is anything your software needs in order to build or run — the application depends on its libraries, and each library may depend on further libraries of its own. Those second-level libraries are transitive dependencies: the dependencies of your dependencies. When forty engineers each download and store their libraries manually on their own machines, three things happen at once: machines drift (one has version 1.2, another 1.4), nobody has a single source of truth for "what versions does this product actually use," and the transitive graph — which library version goes with which — is reproduced from memory on every machine. The sync issues are not a bug; they are the predictable output of manual dependency management.

11.15.3 The Solution: Artifact Repository and Automated Builds

As a DevOps consultant you prescribe:

1. Automate the build process — your build tool (for example Maven) automates the build and manages your application dependencies, including transitive dependencies, in a repeatable way.
2. Use an artifact repository — maintain one repository where all binaries and libraries are part of the same repo, versioned and centralized, instead of living scattered across local machines.
3. Make it automated — the retrieval and resolution of dependencies happens through the build tool against the artifact repository, so every engineer builds against the same known set of binaries.

The benefits to mention: consistent builds across 40 local environments, no manual syncing, and full traceability of which version of which library went into each build.

Real-world connection: Dependency mismanagement is so notorious it has a name — dependency hell (or DLL hell). Early Windows stored all shared libraries in one system directory without versioning, so new versions overwrote old ones and applications silently got whichever version loaded first; Java teams hit the diamond problem, where two libraries depend on different versions of the same third library and the application compiles but fails at run time. Artifact repositories and dependency-managing build tools are the industry's standard answer, and the reference texts recommend exactly what the professor prescribes: declare versions in the project's configuration, resolve them transitively, and control which versions are available through your organization's own artifact repository.

11.16 Last Year's Paper: Are DevOps and Agile the Same?

11.16.1 The Question

Question seven: "A company wants to transform their culture to DevOps, but in one department people think DevOps and Agile are all the same. What is your comment on it? Do you feel DevOps and Agile are the same?"

Notice the question's own wording does half the work: the company wants to transform their culture to DevOps. The word "culture" is the hint, and the department's error is to collapse DevOps into Agile, which lives at a different level.

11.16.2 The Answer: Process vs. Culture

The professor endorsed the class's answer: DevOps and Agile are not the same. Agile is a process — a way of working in iterations — while DevOps is a culture of collaboration between development and operations. A common way to put it: the DevOps process might look Agile, with some add-ons and amendments to it, but the two live at different levels. DevOps names the culture and collaboration model; Agile names the process rhythm inside it.

The two are complementary, not competing: an organization can practice Agile perfectly — two-week sprints, planning poker, retrospectives — while development and operations still throw work over a wall at each other, which is the opposite of DevOps. And a team with a genuine DevOps culture will still run an Agile process. The confusion in the department comes from seeing the same meetings and the same rhythm and concluding that the names mean the same thing; what they are observing is one culture's process, not the culture itself.

Real-world connection: The process-versus-culture distinction shows up in how teams actually change. Organizations that only change their process adopt Scrum without touching the wall between development and operations — and keep suffering slow, high-risk releases. Organizations that transform their culture, as the reference texts describe, integrate operations into the daily work of development: operations engineers work inside delivery teams, deployments become shared responsibility, and the pipeline itself becomes the team's common product. The question's scenario — "transform their culture to DevOps" — is testing exactly this understanding: the goal is the culture, and Agile alone does not deliver it.

11.17 Last Year's Paper: Automation Tools vs. Bottlenecks

11.17.1 The Question

Question eight: "An organization has acquired the latest automation tools, hoping it will increase productivity by eliminating all bottlenecks. Being a DevOps specialist, comment on your view. Do you feel that bringing in the automation will help them increase productivity and eliminate all the bottlenecks?"

This question reuses a misconception the course covered earlier in the semester, and the examiner expects you to recognize it: tools are not the transformation. The wording is deliberately inviting — "latest automation tools," "eliminating all bottlenecks," "increase productivity" — and the correct professional answer pushes back on the assumption.

11.17.2 The Misconception

The class leaned mostly toward yes — tools will help, processes get faster, test cases run automatically. But the professor flagged this as a misconception we have already covered: just by doing automation, do you feel your bottlenecks will be removed? No. Automation alone will not help much; DevOps is a culture that must be adopted, and the tools must be used with the best practices.

The trap is real because automation does help — test cases do run automatically, builds do get faster — and every one of those statements is true and still not the answer. The question asks whether automation eliminates all bottlenecks, and the correct answer is no, because the bottlenecks live in the process, and automation does not see processes; it executes them.

11.17.3 The Correction: Lean First, Then Automate

The key correction: if your process contains waste, and you apply automation tools to that process, you are automating the waste too — it stays inside the process. So the sequence matters: first perform value stream mapping and remove as much waste from your process as you can (become more lean), and only then start automating. Tools reduce bottlenecks only with the correct implementation — and correct implementation starts with a lean process.

Value stream mapping (drawing the complete journey of a piece of work through the organization — every step, every wait, every handoff — and marking how much time is value-added versus waiting or waste) is the diagnostic that makes the waste visible. The value stream map from the reference material tells the story in numbers: a product journey taking about three and a half months can contain waits of five days or more between stages, time that automation of individual steps would never recover, because the waits are structural. Automation applied before this mapping locks the waste in: the conveyor belt carries the garbage at high speed, and now it is harder to see that it was ever garbage.

Real-world connection: The lean-first principle is exactly how the deployment-pipeline literature justifies its own existence: much of the waste in releasing software is not slow builds but structural waits — testers waiting for good builds, developers receiving bug reports weeks late, builds waiting five days to reach a production-like environment. Automating individual steps without mapping the stream leaves those waits untouched, which is why value stream mapping is a standard starting exercise in DevOps transformations, and why "bring the pain forward" — testing early and often, not at the end — is one of the core delivery principles taught alongside it.

11.18 Last Year's Paper: Component-Based Architecture

11.18.1 The Question

Question nine is a direct question the professor did not need to touch in depth: for some application, the statements are given — there is one component for the login and sign-up page; once a person signs up, they can reserve a room according to their selection; and the app provides add-on services, like whether you want car hiring or not. Based on this component set, you are asked to draw the component-based architecture, draw the dependency graph and the pipeline, list the benefits of your component-based design, and show the upstream dependency.

A component is a reasonably large piece of the application with a well-defined interface that can potentially be swapped for another implementation. The scenario names three components by their behavior: the login and sign-up page, the room reservation flow, and the add-on services (such as car hiring). The examiner wants to see that you can translate those statements into a component diagram with the dependency relationships drawn correctly.

11.18.2 What the Answer Must Show

For this kind of question, draw the components (login/sign-up, room reservation, add-on services) as boxes, connect them according to who depends on whom, and show the pipeline through which the components flow. For artifact versioning, use any version number format you are comfortable with — for example v1.2.3. The Set B version of the paper had the same question with a different application scenario, so practice the pattern rather than memorizing this one application.

The pattern to practice, on this scenario:

        ┌─────────────────────┐
              │  login/sign-up      │   component v1.2.3
              └──────────┬──────────┘
                         │  depends on (needs an authenticated user)
              ┌──────────▼──────────┐
              │  room reservation   │   component v1.2.3
              └──────────┬──────────┘
                         │  depends on
              ┌──────────▼──────────┐
              │  add-on services    │   component v1.2.3
              │  (e.g., car hiring) │
              └─────────────────────┘

The drawing has three parts: the boxes (the components), the arrows (the dependency graph — who needs whom), and the version labels (each component is independently versioned, for example v1.2.3). The pipeline part shows how the components flow: each component is built, tested, and stored as a versioned artifact in the artifact repository, and the application is assembled from the approved component versions.

11.18.3 Upstream and Downstream Dependencies

The essential understanding behind the question: what is an upstream dependency and what is a downstream dependency. In a dependency graph, the component that something else depends on is upstream; the component that relies on it is downstream. If you change an upstream component, every downstream component is affected — which is precisely why component-based design, with clear dependency graphs and versioned artifacts, keeps large applications manageable.

Real-world connection: Component-based design is how the reference literature recommends keeping large applications manageable: components are independently deployable pieces with clear interfaces, teams develop them at different rates, and the deployment pipeline assembles the application from the approved versions of each component. The dependency direction is the critical fact — if an upstream component changes, every downstream component is affected, so versioned artifacts and clear dependency graphs are what let a large team change parts of the system without breaking the whole.

11.19 Last Year's Paper: Five Activities Version Control Can Manage

11.19.1 The Question

Question ten: "Mention any five project or product development activities which can be managed by version control system." The professor flagged a trap in the wording: the question says version control system, not source code version control system. Source code is not the only answer — any file can be version controlled.

Version control (keeping a complete, recoverable history of every change to a set of files, so any earlier state can be inspected or restored) is not a source-code-only tool. The question's wording is the clue: it says version control system, and a version control system tracks files. Anything that changes, needs to be audited, or must be reproducibly rebuilt belongs in version control — the reference texts put it directly: everything needed to create, install, run, and test the application should be checked in, from code and tests to database scripts, build scripts, and deployment scripts.

11.19.2 The Five Activities — and More

The answers, which students called out one by one:

1. Configuration as code — configurations can be version controlled.
2. Test cases — your test cases live in version control.
3. Documentation — documentation can be version controlled.
4. Code — the source code itself, of course.
5. Jenkins pipeline / deployment scripts — the pipeline definition and your deployment scripts can be version controlled.

The professor's verdict: that is the correct answer, and the general principle is simply — any file.

Real-world connection: This is exactly how modern teams operate: pipeline as code, configuration as code, and infrastructure as code all lean on the version control system, not just the application source. The reference texts make the same point about the commit stage of the deployment pipeline — the build and deployment scripts are treated like the codebase itself: stored in version control, tested, and refactored, because a pipeline whose definition is not version controlled is a pipeline nobody can reproduce or audit.

11.20 Last Year's Paper: Many Developers, One Repository

11.20.1 The Question

The last question: "What challenges can arise as a result of multiple developers contributing to the same repository, and what tactics can be used to address them?" The answer: concurrent working, which produces conflicts.

The challenge is the direct product of concurrency: when several developers work on the same repository at the same time, their changes to shared files overlap, and the version control system cannot combine them without help. That overlap is a merge conflict — a situation where two changes touch the same lines (or the same logical region) of a file, and the tool needs a human to decide which version, or what combination, is correct.

11.20.2 Conflicts Need Manual Intervention

The first line of the answer should be clear: conflicts cannot be solved automatically. The tool will show you what the conflicts are, but resolving them needs a manual intervention. The tactics are the two places where you can perform that intervention.

The version control tool is a detective, not a judge: it compares the two change sets, identifies the exact lines where both authors edited the same region, and marks the conflict for the reader. What it cannot do is decide the intended meaning — the two edits may be semantically contradictory (both change the same function's behavior in different ways), and only a person who understands the intent can pick the right resolution. The professor's warning stands unqualified: conflicts cannot be solved automatically; manual intervention is always needed.

11.20.3 Where to Resolve Conflicts

1. On your local system — resolve the conflicts with manual intervention on your local copy (as covered in the tutorial session).
2. On the GitHub repository (the remote server) — you can also resolve those conflicts directly on GitHub.

Either way, manual intervention is required, plus a review of the conflict resolution. Frequent, small commits and quick merges reduce how often conflicts happen, but the resolution itself is always a human decision.

Real-world connection: The reference literature confirms both halves of the answer. Merge conflicts grow as branches and changes accumulate — integrating long-lived, rarely merged work becomes exponentially harder, which is why trunk-based development and daily check-ins exist: small, frequent merges keep conflicts small. And the resolution is documented as a human task: the revision control system merges what it can, and when it detects a change it cannot merge automatically, the developer is asked to resolve the conflict — the same manual intervention the professor's answer names, in the same two locations.

11.21 Exam Logistics, Marking, and Practical Details

11.21.1 The Paper: 30 Marks, One Set

The mid-semester paper is worth 30 marks in total. Last time, because of the huge crowd, two different sets of the exam were set up — Set A and Set B — and students got questions from either one. This time, the professor indicated, there are no multiple sets: everyone gets the same paper. The scope is the syllabus covered so far — the best practices. There are no questions on Jenkins jobs or pipelines; that belongs to the next session. The professor's promise: after this discussion, the upcoming exam will feel easier, because you will be in a position to think in the way the answers are expected.

The exam's boundaries, in one line: 30 marks, one set for everyone, open book, covering the best practices and the CI/CD pipeline concept — and explicitly not covering Jenkins jobs or pipelines, which arrive in the next session.

11.21.2 Open-Book Rules and Web References

This is an open-book exam — and as the professor put it, first exams are always difficult, or rather confusing sometimes; that is what open-book exams are meant for. The reference material includes some website links. Those references are purely for your in-depth understanding; you most likely will not need them during the examination, but you are allowed to refer to those web pages, and you can toggle between the browsers while doing so.

One joke deserves recording: asked whether the faculty should be available during the examination as a proctor, chatting in the exam chat box to say "read the question again," the professor laughed — the faculty who taught the syllabus is exactly who should be monitored, he said. And on hints for the upcoming exam: whatever was already shared is already too much extra help; if the same question were put in the exam, everyone would score full marks, the institute would surely notice, and he would be looking for another job.

11.21.3 Regular vs. Makeup Exams

Asked whether the difficulty level will be higher in the makeup exam: yes, as per the rules, makeups are a little bit tougher than the regulars — but it is not a huge difference. The makeup is a facility given to candidates who were not prepared and wanted extra time to prepare, so a slightly higher difficulty is expected. One firm rule: makeup question papers are never shared on any platform, ever; regular papers are always shared.

11.21.4 Answer Scripts and Evaluation

Will students get the solutions after the exam so they can see where they went wrong? As per the rules, the answer scripts cannot be shared. But after the examination, during one of the sessions, the class can walk through the mid-semester paper and the points that were needed to cover. The hard copy will not be shared. The question papers and the evaluation happen through the teaching assistant — but the instructors will let the evaluators know how to evaluate and what to evaluate, and the evaluators are industry experts, so the marking follows the same expectations as the walkthrough.

11.21.5 Grading and Passing

On passing marks: the grading follows the overall marks formula you went through during the orientation program. It is relative — the grades are decided by the performance of the class: whoever scores the highest marks, based on that, the grading starts; it is cumulative. So everyone should pass without panic — and no, there should be no strike to redefine the criteria, and no plan where nobody writes more than 20 marks of questions so that everyone scores at least 10 or 15. That kind of scenario is a joke, not a strategy.

Exam Guidance Summary

• The paper: 30 marks total, one set this time (previously Sets A and B due to the crowd), open book, mid-semester scope covering the best practices and the CI/CD pipeline concept. No questions on Jenkins jobs or pipelines — that is the next session's material.
• Expected question types: problem-statement questions (for example, a team always checking code into an unstable application — suggest following continuous integration and name one or two CI tools such as Jenkins, CircleCI, or TeamCity), plus the walkthrough topics from last year's paper: releasable state via branch by abstraction, build once and promote the artifact, technical debt via code inspection and quality gates, AI/ML aiding DevOps, top ten DevOps tools, binaries and libraries sync via artifact repositories, DevOps vs. Agile, automation without lean, component-based architecture with dependency graphs, five version-control activities, and merge conflicts.
• Answer writing: a 4-mark question takes about four lines; two to three lines per point is enough. State the practice name and its concept; stick to the points; irrelevant theory or blubbering around a topic causes deductions. The concept alone earns marks, but the exact practice name is what MCQ-style exams require.
• Open book and references: web links in the reference material are allowed during the exam; you can toggle between browsers; the links are for in-depth understanding and most likely will not be needed during the exam.
• After the exam: answer scripts are not shared per the rules, but a walkthrough of the paper and the required points happens during a session; the evaluation is done through the teaching assistant, guided by the instructors, by industry-expert evaluators.
• Regular vs. makeup: makeup exams are a little tougher; makeup question papers are never shared; regular papers are always shared.
• Grading: relative and cumulative — based on the class performance, with the grading scale starting from the highest score; everyone can pass.
• Study aid: the CI/CD pipeline overview material — the generic pipeline idea and the different tools — is the recommended revision resource, and it also helps if you have not yet implemented CI/CD in your own project.

Key Industry Applications

• GitHub as the pipeline gate and audit trail: every commit is traceable — which commit failed a build and who made it (see 11.2).
• CI servers: Jenkins, Bamboo, CircleCI, TeamCity — the continuous integration backbone for web, mobile, and microservice pipelines (11.9).
• Artifact repositories: JFrog — central storage of build artifacts (11.8, 11.9).
• Code inspection: SonarQube with quality gates and threshold values that block debt-increasing commits (11.9, 11.12).
• Continuous feedback: Slack, Teams, Outlook/email, and GitHub integrated with Slack or email for instant review-comment and merge-request notifications (11.14).
• Deployment targets: hosting servers, Kubernetes, Docker, Azure, AWS with S3 buckets and EC2 instances, and other cloud platforms (11.9).
• Containerized microservices: Docker containers deployed on Docker or Kubernetes, with the same CI and source repository and only deployment/testing technologies differing (11.9).
• Dependency management: build tools such as Maven, with an artifact repository, handling application and transitive dependencies across large teams (11.15).
• MLOps: ML solutions follow multi-level CI/CD pipelines with their own terminology and technologies (11.13).
• Version control beyond source code: configuration as code, test cases, documentation, and pipeline/deployment scripts all version controlled (11.19).