Why CI/CD, and What It Actually Automates
Continuous Integration / Continuous Deployment means every commit automatically triggers a build and test run — and, when you're ready, an automatic deployment — instead of you manually repeating those steps yourself.
Continuous Integration (CI): every push builds and tests automatically. Push a commit (from the Git Integration course), and a pipeline elsewhere — not your machine — checks out the code, builds it, and runs your test suite (from the Testing course), reporting pass/fail back to you, typically visible right on your pull request.
Continuous Deployment (CD): a passing build can deploy automatically. Beyond just build-and-test, a full CI/CD pipeline can take a passing build and actually publish it — to a staging environment automatically, and to production either automatically or with a manual approval gate, depending on how much automation a team is comfortable with.
Why this matters beyond "it's automated": a human forgetting to run tests before merging, or manually deploying inconsistently, are real, common failure modes. CI/CD makes "did the tests pass" and "was this deployed the same way every time" structural guarantees instead of relying on someone remembering.
Two major platforms cover most real-world CI/CD: GitHub Actions (workflow files live in .github/workflows/, triggered by GitHub events) and Azure DevOps Pipelines (defined in azure-pipelines.yml, deeply integrated with Azure). This course covers both, since which one applies depends on where your repository actually lives.
Visual Studio doesn't run the pipeline itself — it helps you author, trigger, and monitor it. The actual build/test/deploy execution happens on the CI platform's own servers (GitHub's runners, Azure's build agents), not on your machine — Visual Studio's role is authoring the pipeline definition and giving you visibility into its results without leaving the IDE.
Why this matters for you
Once "did this pass its tests" and "how was this deployed" stop depending on a human remembering to do them consistently, a real category of "it worked on my machine" problems simply stops happening.
▶️ Before the next lesson
Check whether your project's repository already has a .github/workflows/ folder or an azure-pipelines.yml file — if either exists, you already have some CI/CD set up, even if you haven't looked at it yet.