Developer Workflow Path
Learn the real software delivery lifecycle: local development, local Git, GitHub collaboration, branch policy, testing strategy, CI, CD, release hygiene, and safe team delivery.
Lesson Flow
Flow Timeline
0/9 lessons done
Next up
The Software Delivery Lifecycle
Local Development and Version Control
The Software Delivery Lifecycle
Pending
Step 1
What Local Git Actually Does
Pending
Step 2
What GitHub Adds on Top of Git
Pending
Step 3
Branching Strategy: Local Branches, Main, Develop, and Trunk-Based Flow
Pending
Step 4
Repository Policies, Pull Requests, and Code Review Rules
Pending
Step 5
Testing Across the Lifecycle: Unit, Integration, E2E, and Release Gates
Pending
Step 6
Continuous Integration: Lint, Test, Build, and Status Checks
Pending
Step 7
Continuous Delivery, Deploys, Releases, and Rollbacks
Pending
Step 8
Capstone: Ship a Change End to End
Pending
Step 9
Local Development and Version Control
Start with the developer loop on your machine, then learn what Git records locally and what GitHub adds on top for collaboration.
Team Policies and Change Safety
Move from solo work into team rules: branching, pull requests, review policy, protected branches, and testing expectations.
Automation, Release, and Ownership
Finish by automating validation in CI, shipping through CD, and learning how a release stays safe after merge.
The Software Delivery Lifecycle
Professional software work is a lifecycle, not only a coding moment. You start locally, make changes in a branch, validate them, collaborate through review, automate checks in CI, release safely, and then monitor what happened in production.
If learners do not see this full path, they may think engineering ends when code runs on their laptop. In reality, the team trusts work only after it survives version control, tests, automation, review, and release discipline.
This track exists to make the invisible workflow visible so students understand what real engineering teams actually do from first edit to stable release.
1const deliveryLifecycle = [
2 "local development",
3 "local git history",
4 "remote collaboration on GitHub",
5 "branch and review policy",
6 "tests and CI checks",
7 "deployment and release",
8 "monitoring and rollback",
9];A new developer can code features alone but is confused when the team starts talking about branches, pull requests, CI checks, deploys, and release gates.
- Software delivery is a staged workflow, not a single coding action.
- Trust in code grows as it passes review, tests, and release gates.
- A strong engineer understands the full path from edit to production.
Draw the path one code change takes from a local file edit to a released feature that users can access safely.
- What happens after code works locally but before users can rely on it?
- Why is merge not the same thing as release?
- Which steps exist to reduce risk for the team and users?
- Learner can explain the full software delivery lifecycle in the right sequence.
- The difference between coding, merging, deploying, and releasing is clear.
- Each stage is tied to a concrete risk-reduction purpose.
What Local Git Actually Does
Git is the local version-control engine on your machine. It tracks snapshots, history, diffs, branches, and merge relationships even before anything is pushed to GitHub.
Students often confuse Git and GitHub, but they solve different problems. Git manages local history and change tracking; GitHub adds hosting, collaboration, review, automation, and repository management.
Once learners understand local Git well, commands like status, add, commit, diff, log, checkout, and branch start to feel like inspection tools instead of random magic.
1git status
2git diff
3git add .
4git commit -m "Add onboarding validation states"
5git log --oneline --decorateA learner loses track of which files changed, which edits are ready, and what the last stable version looked like because they are coding without version-control discipline.
- Git is local first and tracks project history on your machine.
- Commits are snapshots with meaning, not just save buttons.
- Status, diff, and log help you inspect work before sharing it.
Take a small code change and describe what `status`, `diff`, `add`, `commit`, and `log` each tell you during the local workflow.
- Why is Git useful even without a remote repository?
- What is the difference between modified, staged, and committed work?
- Why does a good commit message matter later?
- Learner can explain the role of local Git before any push happens.
- The staged versus committed distinction is clear.
- Git commands are understood as inspection and history tools, not memorized noise.
What GitHub Adds on Top of Git
GitHub is not Git itself. It hosts repositories and adds collaboration features such as pull requests, code review, issues, discussions, permissions, Actions, and branch protection.
The important mental model is this: Git manages history, while GitHub helps teams coordinate around that history. A branch on your machine becomes team-visible once pushed to a shared remote repository.
Teaching GitHub well means showing why remote collaboration needs more than push and pull. It needs ownership, review, traceability, and automation hooks.
1git remote add origin https://github.com/org/repo.git
2git push -u origin feature/onboarding-validation
3git pull --rebase origin mainA new engineer can commit locally, but they do not understand why the team cares about pull requests, reviewers, and repository permissions once work leaves their laptop.
- GitHub adds remote hosting and team collaboration around Git history.
- Pull requests turn code changes into reviewable units of discussion.
- Remote repos create shared truth for teams, not just backup copies.
Explain the path from a local branch to a pushed branch to a pull request another engineer can review.
- What does GitHub do that local Git does not?
- Why is a pull request more than just a diff page?
- What does a remote tracking branch help the team coordinate?
- Learner can clearly distinguish Git from GitHub.
- The role of remotes, pushes, pulls, and pull requests is explained in one coherent flow.
- GitHub is framed as a collaboration layer, not just a website with code.
Branching Strategy: Local Branches, Main, Develop, and Trunk-Based Flow
Branching strategy is a team policy, not a universal law. Some teams use long-lived `main` and `develop` branches, some use GitFlow-style release branches, and many modern teams prefer short-lived branches with trunk-based development.
What matters most is choosing a strategy that matches release frequency, team size, coordination cost, and operational risk. A startup shipping daily may want fewer long-lived branches than a regulated product with scheduled release trains.
Learners should understand the purpose of branches: isolate change, reduce conflict, protect stable branches, and make collaboration reviewable.
1main -> always releasable
2develop -> integration branch (some teams)
3feature/* -> short-lived task branches
4release/* -> optional stabilization branch
5hotfix/* -> urgent production fixesA team keeps merging huge branches late, causing conflicts and unstable releases, and nobody agrees whether they need `develop`, trunk-based development, or release branches.
- Branching policy should fit the team's delivery model.
- Short-lived branches usually reduce drift and merge pain.
- A branch exists to isolate and coordinate work safely.
Choose a branching model for one team scenario and justify whether it should use `main` only, `main` plus `develop`, or a stricter release branch model.
- When is a long-lived `develop` branch helpful versus harmful?
- Why do short-lived feature branches usually age better?
- What does 'main is always releasable' require from the team?
- Learner can compare common branching models without dogma.
- The chosen strategy is tied to release cadence and team size.
- Branch purpose is explained in terms of risk and collaboration, not habit.
Repository Policies, Pull Requests, and Code Review Rules
Engineering velocity comes from clear policies, not from letting every merge happen however someone feels like that day. Branch protection, required reviews, status checks, commit hygiene, and ownership rules reduce ambiguity and keep `main` trustworthy.
A pull request is not paperwork. It is a bounded review unit where the team checks correctness, design fit, risk, tests, and release readiness before code joins the shared branch.
Strong teams write down their merge policies so new engineers can succeed without guessing what 'done' means in this repository.
1const repoPolicy = {
2 protectedBranches: ["main"],
3 requiredReviews: 1,
4 requiredChecks: ["lint", "tests", "build"],
5 squashMerge: true,
6 forcePushToMain: false,
7};A repository keeps accepting half-reviewed code because there is no shared rule for approvals, required checks, or what a pull request must include before merge.
- Repository policy protects quality and shared trust.
- Pull requests are review and risk-management tools.
- Branch protection turns process into enforceable rules.
Write a lightweight repository policy for a small team covering branch protection, review expectations, merge rules, and required checks.
- Which checks should block merge into `main`?
- What makes a pull request review high-signal instead of superficial?
- When should a team squash merge versus preserve many small commits?
- The repository has clear branch and review policy written down.
- The role of PR review is described beyond 'someone looked at it'.
- Merge readiness is tied to explicit requirements the team can enforce.
Testing Across the Lifecycle: Unit, Integration, E2E, and Release Gates
Testing is not one thing. Unit tests check isolated logic, integration tests check boundaries between components or services, E2E tests check user-facing flows, and smoke tests verify a release is still alive after deployment.
The right testing strategy depends on risk. Not every change needs the same tests, but every important change needs some meaningful evidence before merge or release.
Learners should understand testing as a layered confidence system that supports code review, CI, and release decisions.
1const testPyramid = {
2 unit: "fast and numerous",
3 integration: "boundary confidence",
4 e2e: "critical user journeys",
5 smoke: "post-release sanity checks",
6};A team has some tests but still ships broken flows because they never decided which level of testing should catch which class of mistake.
- Different test types answer different questions.
- Testing strategy should follow risk, not fashion.
- Release confidence comes from layered evidence, not one magic suite.
Pick one feature and define which unit, integration, E2E, and smoke checks should exist before and after release.
- What is the difference between unit and integration confidence?
- Which user flow deserves E2E coverage first?
- Why is '100% coverage' not the same thing as real release confidence?
- Learner can explain the role of each test layer clearly.
- A feature has an explicit pre-merge and post-release test plan.
- Testing is framed as decision support for CI and release, not ceremony.
Continuous Integration: Lint, Test, Build, and Status Checks
Continuous integration means every meaningful change is validated automatically in a shared environment before or around merge. Typical CI checks include linting, tests, build verification, typechecking, security scans, and artifact creation.
The point of CI is not to make engineers wait. It is to catch integration risk early, create consistent quality signals, and keep the main branch trustworthy as a collaboration target.
When learners understand CI, they stop seeing failed checks as punishment and start seeing them as automated code review for repeatable mistakes.
1name: ci
2on: [pull_request]
3jobs:
4 verify:
5 runs-on: ubuntu-latest
6 steps:
7 - run: npm ci
8 - run: npm run lint
9 - run: npm test
10 - run: npm run buildA team merges code that worked locally but breaks in the shared environment because nobody automated lint, test, or build checks before merge.
- CI automates quality checks around shared code changes.
- The main branch stays healthier when merge depends on consistent checks.
- Automation creates repeatable signals humans can trust.
Define the minimum CI pipeline for one repository, including what must run on every pull request and what may run on a slower schedule.
- Which checks belong on every PR versus nightly or release workflows?
- Why should a build check run even when tests pass?
- What does a red CI check protect the team from?
- CI pipeline includes the checks needed to keep `main` trustworthy.
- The learner can explain why each automated check exists.
- Status checks are treated as merge gates, not optional decorations.
Continuous Delivery, Deploys, Releases, and Rollbacks
Continuous delivery and continuous deployment are about what happens after code is merged and validated. A team may automatically prepare deployable artifacts, auto-deploy to staging, or even auto-deploy to production when checks pass.
Deployment is the act of putting code somewhere it can run. Release is the act of exposing that change to users. Those are related but not identical, especially when feature flags, staged rollouts, migrations, or approval gates exist.
Good teams plan rollback and recovery before release day. A release process is healthy when it can stop or reverse change quickly without panic.
1const releaseFlow = {
2 mergedToMain: true,
3 deployedToStaging: true,
4 productionApproval: true,
5 featureFlag: "onboarding_v2",
6 rollbackPlan: "revert + disable flag",
7};A team can deploy, but they still create release anxiety because there is no shared model for staging, approvals, rollout, or rollback behavior.
- Deploy and release are related but different ideas.
- CD turns validated changes into safer delivery pipelines.
- Rollback planning is part of release design, not a last-minute panic step.
Map one change from merged PR to staging deploy to production release, including approvals, feature flags, and rollback steps.
- What is the difference between deployment and release?
- When should a team use staged rollout or feature flags?
- What needs to be true before rollback is safe?
- Learner can explain the difference between CI, CD, deployment, and release.
- The release plan includes rollout, rollback, and verification steps.
- The team can describe what happens after merge without hand-waving.
Capstone: Ship a Change End to End
Now combine the full workflow: make a change locally, commit it cleanly, push a branch, open a pull request, pass automated checks, merge with policy, ship via a release process, and verify the result.
This capstone proves the learner understands engineering as coordinated delivery, not only as editing files. The final artifact should read like a real team's change lifecycle.
A good capstone makes another engineer think, 'yes, this person understands how software actually gets shipped.'
1const shippingChecklist = {
2 localChangeValidated: true,
3 commitsReadable: true,
4 prReviewed: true,
5 ciGreen: true,
6 releasePlanWritten: true,
7 rollbackReady: true,
8};A new engineer needs to demonstrate that they can participate in a team's full shipping workflow, not only submit code snippets for review.
- Software delivery is an end-to-end engineering discipline.
- Each stage of the lifecycle exists to improve trust, collaboration, and safety.
- A strong engineer can explain not just the code, but how that code gets shipped responsibly.
Take one small feature or fix and write its complete path from local branch to reviewed PR to green CI to staged release to rollback-ready production launch.
- What would make another engineer trust this change before merge?
- Which step in the lifecycle still feels underdefined?
- Can you explain the difference between 'code done' and 'change safely shipped'?
- The full lifecycle is explained from local work to released change.
- Policies, tests, CI, and release steps are all present and sequenced correctly.
- The capstone is realistic enough to discuss in onboarding or engineering interviews.