D784 Continuous Integration and Continuous Delivery is banner number ITSW 6101 and three competency units in the School of Technology, in the graduate DevOps sequence. The catalog describes it as advanced DevOps practices for continuous integration and continuous delivery in modern software development environments. The competency is pipeline design as an engineering problem: what runs, in what order, how fast it has to be to stay useful, and what each stage is permitted to stop.
Three terms that are not synonyms
Getting the vocabulary exact is worth doing before anything else, because graduate aspects use these terms precisely and students use them loosely. Continuous integration means every developer merges into the shared line frequently, and every merge is verified automatically. Continuous delivery means every verified change is kept in a state where it could be released at any moment, with the release itself remaining a business decision. Continuous deployment means the release happens automatically when the checks pass. A paper that uses delivery and deployment interchangeably has undermined its own analysis.
The economics of the pipeline drive most design decisions. A feedback loop is only useful if it closes while the developer still has the change in mind, which puts a practical ceiling on how long the fast stages can take. That ceiling is what forces the layering: quick checks on every commit, slower and broader verification on a schedule or before promotion, and the slowest checks reserved for a release candidate. A single pipeline that runs everything on every commit is thorough and, past a certain size, ignored.
Branching strategy is inseparable from integration. Long-lived feature branches postpone integration, which is the exact thing continuous integration exists to prevent, and they produce merge conflicts proportional to how long they lived. Trunk-based development with short-lived branches and feature flags keeps the line integrated at the cost of needing flags managed and retired. Aspects that ask about your integration approach expect this trade-off stated.
Artifact discipline is the quiet requirement. One build, produced once, versioned, and promoted unchanged through environments. Rebuilding for each environment means the thing you tested is not the thing you shipped, which silently invalidates every stage before the last.
Turning scored aspects into pipeline stages and a budget
Each rubric aspect at WGU is scored on its own and needs a 2. In a pipeline course the mapping runs from aspect to stage, to a policy, or to a measurement, and each should be identifiable in your pipeline design before you draft prose.
Budget it. Suppose ten scored aspects and a document of about 2,000 words with a pipeline diagram. Ten into 2,000 gives 200 words apiece. Sort them. Three are design aspects answered mostly by the diagram and a stage table, needing 120 each of reading text, which is 360 and releases about 240. Two ask you to justify the stage design and the branching strategy, at 330 each, or 660. One asks about artifact and environment promotion, 280. Two ask about metrics and feedback, at 250 each, or 500. Two are shorter framing sections at 90 each, or 180. That totals 360 plus 660 plus 280 plus 500 plus 180, which is 1,980, on target, with justification and measurement holding almost sixty percent.
Alongside it, write a time budget for the pipeline: target duration for each stage and what you would remove if the fast path exceeded its ceiling. That budget converts a diagram into an engineering design and answers aspects about practicality directly.
Designing the D784 pipeline?
Send the aspects plus the delivery context. You get a stage design with time budgets, a branching argument and a metric set.
Stage design, with what each stage is allowed to stop
| Stage | Runs on | Target duration | Authority |
|---|---|---|---|
| Compile and static checks | Every push | Under two minutes | Blocks the merge |
| Unit tests | Every push | Fast enough to keep the loop closed | Blocks the merge |
| Build and publish artifact | Every merge to the main line | Short, and reproducible from the commit | Blocks promotion |
| Integration and contract tests | Every merge | Minutes, not hours | Blocks promotion |
| Deploy to a test environment | Every promoted artifact | Automated, no manual steps | Blocks the next stage on failure |
| End-to-end journeys | Promoted artifacts, in parallel where possible | Bounded, with flaky tests quarantined | Blocks release candidacy |
| Release | A decision, or automatically under continuous deployment | Progressive, with monitored signals | Triggers rollback on a defined signal |
The authority column is what makes this a pipeline rather than a sequence of reports. A stage that cannot stop anything is telling you something nobody has to act on.
Measuring delivery, and citing the evidence
Graduate work on delivery is expected to measure, and there is a well established set of measures to reason with: how often you deploy, how long a change takes from commit to production, how often a change causes a failure, and how long restoration takes. Each says something different, and a paper that reports deployment frequency alone can describe an organization shipping breakage quickly.
Attach a decision to each measure, as with any metric. A rising change failure rate should trigger a specific action, such as strengthening a stage or shrinking batch size, and saying which action makes the metric part of a control loop rather than a dashboard.
Cite properly. Established texts on continuous delivery and published research on software delivery performance support the practice claims, in APA where your program requires it. Tool documentation is the authority for what a tool does and is not evidence that a practice improves outcomes. Where your scenario constrains you, a regulated release approval or a fixed maintenance window, quote the constraint when justifying a stage so the design is visibly derived from the case rather than from a reference architecture.
What clears, and what returns
WGU records Competent or Not Competent with no letter grades and no ordinary grade point average, and revision after a return carries no penalty. Inside a six month flat rate term what a return costs is days, which is why a first submission built on precise terminology and stated constraints is the efficient path.
Designs that clear use the three terms correctly, set a time budget the organization could actually sustain, pick a branching model and state its cost, promote one artifact, and define what happens when a stage fails rather than only what it checks. They connect the pipeline to the delivery constraints in the scenario.
Returns come from four patterns. A diagram of stages with no failure behavior. Delivery and deployment used interchangeably. A branching strategy adopted without acknowledging that long-lived branches defer the integration the course is named for. And metrics presented without a single decision attached to a reading.
Eight mistakes that cost D784 students time
- Blurring delivery and deployment. One keeps the change releasable, the other releases it. Graduate aspects treat the distinction as load bearing.
- Running everything on every commit. A thorough pipeline that takes an hour gets bypassed, and a bypassed pipeline enforces nothing.
- Tolerating flaky tests. Intermittent failures teach the team to rerun, and rerunning disables every gate downstream.
- Rebuilding per environment. If the artifact is rebuilt, the thing tested is not the thing released, and the earlier stages have proven nothing about it.
- Long-lived feature branches. They postpone the integration this course exists to make continuous, and the merge cost grows with the delay.
- No rollback trigger. Progressive release without a defined signal and owner is a slower way to ship the same failure.
- Manual steps hidden inside an automated pipeline. One place where somebody copies a file by hand makes the whole process unrepeatable, and it is usually the step that fails at the worst hour.
- Large batches. A release that carries three weeks of change is harder to verify, harder to diagnose when it breaks and harder to roll back, and batch size is the variable most under your control.
How we work on this course
Support for D784 is pipeline design and vocabulary discipline. Send the scored aspects and the delivery context and you get a stage design with durations and stop authority, a branching argument built from your team's shape, an artifact promotion policy, a metric set with decisions attached, and a model document in the register WGU graduate evaluators expect. Where an objective assessment is part of your course, our help is preparation only. Every objective assessment at WGU is proctored, so coaching stops at the door of the exam, and your portal sign-in is never something we request or handle.
Graduate terms run six months at a flat rate, so closing more courses inside one lowers what each effectively costs. Pipeline papers shorten considerably once the stage table exists.
Three questions D784 students ask
Is D784 the same course as ITSW 6101?
What is the difference between continuous delivery and continuous deployment?
Do I need to build a real pipeline?
Where D784 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.