Deployment, Hosting, and CI/CD

Deployment is the process of getting your website from your local machine into a live environment where real users can access it. In modern web development, deployment is not just “uploading files”. It includes building your code, configuring environments safely, releasing changes in a controlled way, and being able to roll back if something goes wrong.

This topic covers:

• Build pipelines (what happens between code and a live site)
• Environment variables (how to store configuration safely)
• Staging vs production (why you need more than one environment)
• Common hosting options (where your site can live)
• CI/CD (how to automate repeatable, low-risk releases)

---

1) What a Build Pipeline Does

A build pipeline is a set of steps that turns your source code into a deployable artefact. It helps you deliver consistent results every time.

Typical pipeline stages

1. Checkout code

   • Pull the latest code from your Git repository (for example, main branch).

2. Install dependencies

   • For Node-based projects, this usually means npm ci (preferred for CI) or npm install.

3. Run quality checks

   • Linting (code style and common mistakes): ESLint, Stylelint
   • Type checks (if using TypeScript)
   • Unit tests and/or integration tests

4. Build

   • Convert your source files into production-ready output.
   • Examples:
     • A React/Vue/Angular app builds into static files (HTML/CSS/JS bundles).
     • A back-end app may build into a Docker image or compiled output.

5. Package artefact

   • Save the build output for deployment (for example, dist/, a Docker image, or a zipped bundle).

6. Deploy

   • Upload static files to hosting (CDN/object storage), or deploy an app to a server/container platform.

7. Post-deploy checks

   • Smoke tests (basic “does it load?” checks)
   • Health checks (API responds, database connectivity, etc.)

Why this matters

• Consistency: builds are repeatable and not dependent on your laptop.
• Quality: problems are caught before users see them.
• Speed: automation reduces manual effort and mistakes.

---

2) Environments: Development, Staging, Production

Most real-world projects use multiple environments so you can test safely before releasing to the public.

Development (local)

• Runs on your machine (for example, localhost:3000).
• Fast feedback for coding.
• Uses test credentials and local databases.

Staging (pre-production)

• A “production-like” environment used for final testing.
• Should be as similar to production as possible:
  • Similar server setup
  • Similar database type
  • Similar environment variables (but different secrets)

Production (live)

• Real users access this environment.
• Uses real domains, real data, and strict security.
• Changes must be controlled and traceable.

Key principle

You should never test risky changes directly in production. Use staging to confirm that the build, configuration, and deployment are correct.

---

3) Environment Variables (Config and Secrets)

Environment variables are values provided to your application at runtime (or build time) to configure it without changing code.

What should go into environment variables?

• API base URLs (staging vs production)
• Database connection strings
• Authentication secrets (JWT secret, OAuth client secret)
• Third-party service keys (email provider, payment gateway)
• Feature flags (enable/disable a feature)

What should NOT be committed to Git?

• Passwords
• Private keys
• Tokens
• Any production secrets

A good rule: If it would cause damage when leaked, it must be a secret and stored securely.

Build-time vs runtime variables (important for front-end)

• Front-end apps (like React/Vite/Next static output) often bake certain variables into the build. If you build with the wrong values, you might need to rebuild to correct them.
• Back-end apps typically read environment variables at runtime when the server starts.

Safe ways to manage secrets

• Use the hosting platform’s secret manager (for example, “Environment Variables” section in your host dashboard).
• Use GitHub Actions Secrets (or similar) for CI pipelines.
• Use a .env file locally, and add it to .gitignore.

---

4) Staging vs Production: Practical Differences

Domains and URLs

• Staging: staging.yourdomain.co.za or yourapp-staging.hostingapp.com
• Production: www.yourdomain.co.za (or yourdomain.co.za)

Data

• Staging should use test data (or anonymised copies if needed).
• Production uses real user data and must be protected (POPIA-aware handling).

Access control

• Staging can be protected (basic auth, IP allowlists, login-only).
• Production must be publicly accessible, but locked down for admin routes.

Release strategy

• Deploy to staging first → verify → deploy to production.
• Keep the ability to roll back to the previous working version.

---

5) Common Hosting Options (and When to Use Them)

There is no single “best” hosting choice. The right option depends on your site type:

A) Static hosting (best for static sites and front-end SPAs)

Good for: portfolios, landing pages, documentation, many React/Vue builds (if they don’t require a server to render)

• Host generated files (HTML/CSS/JS) on a CDN.
• Often very fast and cost-effective.
• Examples of features:
  • Automatic HTTPS
  • Global CDN
  • Simple rollbacks

Watch out for SPA routing:
Single Page Apps need rewrite rules so that /about still loads your index.html. Your host typically provides a “redirects/rewrites” configuration.

B) Traditional web hosting (shared hosting)

Good for: simple websites, some CMS installs (depending on provider)

• Often includes cPanel/Plesk.
• Easy to start but limited control.
• Can become restrictive for modern build tooling and CI/CD.

C) Virtual Private Server (VPS)

Good for: full control, custom setups, learning server management

• You manage the server: updates, security patches, firewall, reverse proxy (Nginx), process manager, backups.
• More responsibility, more flexibility.

D) Platform-as-a-Service (PaaS)

Good for: back-end APIs, full-stack apps, production-ready deployment with less ops work

• You push code; the platform builds and runs it.
• Built-in logs, scaling options, managed env vars.
• Often supports “Review apps” or staging environments.

E) Container hosting (Docker/Kubernetes-based platforms)

Good for: consistent deployments, microservices, teams with DevOps maturity

• Package your app and dependencies into a Docker image.
• Great consistency between staging and production.
• More moving parts (but very powerful).

F) Managed CMS hosting

Good for: CMS-based sites (WordPress, headless CMS platforms)

• Many tasks are handled for you: backups, updates, caching.
• Useful if the project includes a CMS-based deliverable.

---

6) CI/CD: Continuous Integration and Continuous Delivery/Deployment

CI/CD is a way to automate building, testing, and releasing software so every change can be delivered reliably.

Continuous Integration (CI)

CI means that when you push code:

• It automatically runs checks (lint, tests, build)
• It alerts you if something breaks
• It helps keep main branch healthy

Goal: catch issues early.

Continuous Delivery vs Continuous Deployment

• Continuous Delivery: every change is ready to deploy, but a human triggers the production release.
• Continuous Deployment: every change that passes checks is automatically deployed to production.

In many teams, delivery is preferred for production (more control), while staging can be fully automated.

---

7) A Typical CI/CD Workflow Using Git

A simple, effective workflow might be:

1. Create a branch: feature/contact-form
2. Open a Pull Request (PR) into main
3. CI runs automatically on the PR:
   • Lint
   • Tests
   • Build
4. Code review happens
5. Merge PR into main
6. CD deploys:
   • Automatically to staging
   • After approval, deploy to production

Branch protection (recommended)

• Require CI checks to pass before merging
• Require at least one code review
• Prevent direct pushes to main

This reduces the chances of “it works on my machine” reaching production.

---

8) Setting Up a Basic CI/CD Pipeline (Conceptual Steps)

Even though tooling differs, the setup usually follows the same pattern.

Step 1: Define triggers

Decide when the pipeline runs:

• On pull requests (CI)
• On merges to main (deploy to staging)
• On tags like v1.2.0 (deploy to production)

Step 2: Add your build steps

Typical Node front-end example:

• Install dependencies
• Run lint
• Run tests
• Build production assets

Step 3: Add deployment steps

Depends on hosting:

• Upload static build folder to your static host
• Deploy server app to your PaaS
• Build and push Docker image to a registry, then deploy

Step 4: Store secrets safely

Add secrets (API keys, tokens) in:

• CI system secret storage (not in the repo)
• Hosting platform environment variables

Step 5: Add verification

After deploy:

• Run a smoke test (home page loads, API health endpoint returns 200)
• Optionally run end-to-end tests against staging

---

9) Releases, Versioning, and Rollbacks

Versioning

A common approach is Semantic Versioning:

• MAJOR.MINOR.PATCH (for example, 2.4.1)
  • MAJOR: breaking changes
  • MINOR: new features (backwards compatible)
  • PATCH: bug fixes

Rollbacks

A good deployment system supports rollbacks:

• Static hosting often allows “redeploy previous build”
• PaaS platforms often keep previous releases
• Containers can roll back to a previous image tag

Plan rollbacks before you need them.

---

10) Deployment Checklist (Practical)

Before deploying to production, confirm:

• [ ] Build passes locally and in CI
• [ ] Tests pass (unit/integration; basic E2E if available)
• [ ] Linting and formatting checks pass
• [ ] Environment variables are set correctly for production
• [ ] Secrets are stored securely (not in code)
• [ ] HTTPS is enabled and working
• [ ] SPA rewrites/redirects are configured (if relevant)
• [ ] Error logging/monitoring is enabled (at least basic logs)
• [ ] A rollback path exists (previous release available)

---

Knowledge Check (Quick Questions)

1. What is the difference between staging and production?
2. Why should secrets never be committed to Git?
3. What is the difference between Continuous Delivery and Continuous Deployment?
4. Name two hosting options suitable for a static website and explain why.

---

Mini Activity: Design Your Deployment Plan

Choose one of your course projects (for example, your PWA or CMS-based site) and write:

• Your hosting choice and why it fits
• Your environments (development/staging/production) and URLs
• The environment variables you need (no real secrets—use placeholder names)
• Your CI steps (lint, test, build)
• Your CD steps (deploy staging, approval, deploy production)
• How you would roll back if the release fails

This plan will guide you when you implement a real pipeline later in the lesson.