The three prescriptions — Git/PR workflows (rank 1, 92% of postings), REST as a named architectural style (rank 2, 75%), and CI/CD as an assembled process discipline (rank 3, 58%) — together close every gap surfaced by Market-fit. Each one extends a slide that already exists (Ch7 Slide 46, Ch6 Slides 33/51, Ch3 Slides 9/53) and adds only conceptual/process-level content, respecting the course's methodology depth bound.
These three prescriptions cover 3 of 3 gaps (100%) surfaced by Market-fit. They do NOT close the larger market-fit deficit on framework/language demands (Node.js, TypeScript, Postgres, React, CSS/Tailwind, Docker, Jest, Next.js, GraphQL, Kubernetes, AWS) — those are correctly omitted per Rule 2 because they exceed this course's process/methodology depth bound and would belong in a hands-on web-development or DevOps course instead. Honest framing: this course can be made market-aware in its process vocabulary, but cannot by itself prepare a fullstack hire — the curriculum needs a complementary implementation course.
Distributed version control workflows with Git — branching strategies (trunk-based vs. GitFlow) and pull-request code review as a process artifact
Extend the configuration-management slide from generic 'version management' to the Git branching + pull-request review workflow that 11 of 12 fullstack postings assume students already understand.
gitdistributed version controlbranchingpull requestcode reviewtrunk-based developmentgitflow
Where it fits
Ch7 Implementation.pptx — Slide 46 (Configuration management activities)
· Ch7 already teaches configuration management generically ('Version management... include facilities to coordinate development by several programmers. System integration... Problem tracking...'). The natural extension is to name distributed VCS (Git) as the dominant model and to introduce the pull-request review loop as a process artifact that connects version management, problem tracking, and quality control. This stays at the methodology/process level the course operates at — no `git` syntax, no GitHub-specific UI walkthrough.
Prerequisites
-
Version management / configuration management concepts
· already covered in Ch7 Implementation.pptx (Slide 46)
-
Incremental development lifecycle
· already covered in L2-Ch2 SW Processes.pptx (Slide 7)
-
Software inspection / review as a quality activity
· already covered in Ch8.Testing.pptx
REST as an architectural style for HTTP APIs — resources, statelessness, uniform interface via HTTP verbs (conceptual extension of client-server)
Promote REST from an unnamed background assumption to a first-class architectural pattern in Ch6 — 9 of 12 fullstack postings demand it, and the course already teaches every prerequisite (client-server, multi-tier, service APIs).
resthttpresourcesstatelessnessuniform interfaceapi designclient-server
Where it fits
Ch6 Architectural design.pptx — Slide 33 (Client-server architecture) and Slide 51 (Multi-tier web/application architecture)
· Ch6 already teaches client-server architecture abstractly and introduces multi-tier web systems (web server / app server / database server). Ch5 Slide 55 mentions APIs at the conceptual level ('Integrated services... offer an API... can be accessed by other services'). The natural extension is to name REST as the dominant architectural style of modern client-server APIs and treat it as an architectural-pattern entry alongside MVC, Layered, and Pipe-and-Filter. This stays conceptual (resource modelling, statelessness, HTTP verbs as a uniform interface) without descending into Express/Spring endpoint coding, which would breach the depth bound.
Prerequisites
-
Client-server architectural pattern
· already covered in Ch6 Architectural design.pptx (Slide 33)
-
Multi-tier web/application architecture
· already covered in Ch6 Architectural design.pptx (Slide 51)
-
Service-oriented systems and APIs (conceptual)
· already covered in Ch5 System modeling.pptx (Slide 55)
Continuous integration and continuous delivery as a process discipline — assembling frequent builds, automated regression tests, staging vs. production environments, and the release-vs-deploy distinction
Rewrite Ch3's 'CI is practically impossible' note into the modern CI/CD pipeline concept — the course already teaches every ingredient (frequent builds, automated regression, incremental releases); 7 of 12 fullstack postings now name the assembled pipeline by name.
continuous integrationcontinuous deliveryci/cdautomated builddeployment pipelinestaging environmentrelease management
Where it fits
Ch3. Agile SW Dev-V2.pptx — Slide 53 (Scaling up) and Slide 9 (XP build cadence), reinforced in Ch8.Testing.pptx Slide 48 (Regression testing)
· The course teaches the constituent pieces piecemeal — XP's 'New versions may be built several times per day... All tests must be run for every build' (Ch3 Slide 9), automated regression testing (Ch8 Slide 48), and incremental delivery (L2-Ch2). It also explicitly says 'Continuous integration is practically impossible' at scale (Ch3 Slide 53), framing CI as a problem rather than today's standard practice. The natural extension is to update Slide 53 and assemble the existing pieces into the modern CI/CD pipeline as a process model: build + test + deploy on every commit, environment promotion, and decoupling release from deploy. Implementation tooling (GitHub Actions YAML, Jenkinsfile internals) is correctly out of scope for this methodology course.
Prerequisites
-
Automated regression testing
· already covered in Ch8.Testing.pptx (Slide 48)
-
XP frequent-build cadence / TDD
· already covered in Ch3. Agile SW Dev-V2.pptx (Slides 9, 22)
-
Incremental development and release planning
· already covered in L2-Ch2 SW Processes.pptx (Slide 7); L4-Ch23 Project planning-v2.pptx
-
Tool-agnostic configuration management / system integration
· already covered in Ch7 Implementation.pptx (Slide 46)