Building Your First CI/CD Pipeline Step by Step

This is the capstone lesson. You will connect Git, automated tests, and a deploy step so pushing code can update a live site without FTP and prayer. Ready? Let's build your first real CI/CD pipeline.

What We Will Build

A GitHub Actions workflow that:

• Runs when code merges to main.
• Builds and tests a .NET web API.
• Deploys to Azure App Service staging slot.

Step-by-Step Build

Step 1: Create a GitHub repo with a .NET project and at least one test project.

Step 2: Create Azure App Service and add publish profile as a GitHub secret.

Step 3: Create .github/workflows/deploy.yml:

name: CI/CD to Azure
on:
  push:
    branches: [main]
jobs:
  build-test-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'
      - run: dotnet restore
      - run: dotnet build --configuration Release --no-restore
      - run: dotnet test --no-build --verbosity normal
      - run: dotnet publish -c Release -o ./publish
      - name: Deploy to Azure Web App
        uses: azure/webapps-deploy@v3
        with:
          app-name: my-student-api
          publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}

Step 4: Push to main and watch the Actions tab turn green.

Step 5: Verify staging URL:

curl -I https://my-student-api-staging.azurewebsites.net/health

Real-World Example

A student hackathon team sets this up Saturday morning. By evening every teammate's merged feature auto-deploys to a demo URL judges can click — no one stays up manually copying DLLs.

Common Misconceptions

"One pipeline fits all projects." Mobile apps, data jobs, and APIs need different steps — start simple and grow.

"Failed deploy means rollback is automatic." Configure slot swap back or redeploy last good artifact — practice this before you need it.

Plan Rollback Before You Need It

Before first production deploy, document rollback:

Option A: Azure deployment slot swap back to previous version.

Option B: Redeploy last known-good pipeline run artifact from GitHub Actions history.

Practice rollback on staging during a calm afternoon — not during demo minutes before judges arrive.

Secrets Hygiene Checklist

• Never commit publish profiles or API keys to Git.
• Use GitHub Secrets or Azure Key Vault references in pipelines.
• Rotate credentials if accidentally exposed — bots scan GitHub within minutes.
• Prefer OIDC federation over long-lived passwords where supported.

Treating secrets carelessly is like posting your ATM PIN on Instagram — automated attackers will notice.

Environment Variables in Pipelines

Store non-secret config like ASPNETCORE_ENVIRONMENT=Staging as pipeline variables. Keep secrets in secret stores. Separate variable groups per environment so production connection strings never leak into student sandbox pipelines by copy-paste mistake.

After your first successful deploy, screenshot the green pipeline and add a README badge showing build status. Open-source projects use these badges for credibility; your portfolio project demonstrates professional habits recruiters recognize immediately during campus placement season.

Pipeline Notifications

Configure Slack or Teams webhooks to post pipeline results. Green builds give quiet confidence; red builds ping the channel immediately. Visibility beats checking Actions tab manually hours later when teammates already merged on broken main.

Add test result publishing so failed tests show names in pipeline UI — 'CheckoutTests.CalculateTotal_FailsWhenDiscountNegative' beats generic 'test failed' messages that send you grep hunting through logs during limited lab period time.

Summary

You now have the skeleton every professional pipeline builds on: trigger, build, test, publish, deploy. Improve tests and add approvals over time — the hard part is starting, and you just did.