Module 1: CI/CD Foundations
Why Automation Wins
Every time a person builds, tests and deploys software by hand, there is a chance of a missed step, a wrong file or a forgotten setting. Manual releases are also slow, so teams do them rarely, which makes each release larger and riskier. Automation breaks that cycle. In this course you will learn to automate the path from a code change to running software using GitHub Actions. First, it is worth understanding exactly why automation is worth the effort.
The hidden costs of manual delivery
Picture a hypothetical three-person team in Nairobi building a booking website for a chain of salons. Their release process is a checklist in a shared document:
- Pull the latest code on a laptop.
- Run the tests (if there is time).
- Build the production bundle.
- Copy files to the server by FTP or SSH.
- Run database changes by hand.
- Restart the application and click around to check.
This works until it does not. Someone builds from a branch with unfinished work. The tests are skipped on a busy Friday. The person who knows the server password is on leave. A database change is run twice. None of these are unusual; they are the predictable result of asking people to repeat many detailed steps perfectly.
The costs are not only failures. Manual releases take time from skilled people, create anxiety, and encourage the team to release less often. Features that are finished wait days or weeks before customers can use them.
What automation gives you
- Consistency. A script runs the same steps in the same order every time.
- Speed. A pipeline can test and deploy in minutes, without waiting for a person to be free.
- Fast feedback. Tests run on every change, so you learn about a mistake while it is fresh.
- Traceability. Every run is logged: which commit, which tests, who triggered it, what was deployed.
- Safety. Credentials live in the pipeline's secret store instead of on individual laptops.
- Documentation. The workflow file itself documents exactly how the software is built and released.
Worked example: the same release, automated
The salon booking team moves the checklist into a GitHub Actions workflow. Do not worry about every line yet; you will learn the syntax in this module. Notice how each manual step becomes a named step:
name: build-and-deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Get the code
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Build
run: npm run build
- name: Deploy
run: ./scripts/deploy.sh
env:
DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
Now every push to main runs the same steps. If tests fail, the workflow stops before deploying. The deployment token is stored as an encrypted secret in GitHub rather than in someone's notes. When something goes wrong, the run log shows exactly what happened.
What to automate first
You do not need to automate everything on day one. A sensible order is:
- Running tests and linting on every pull request.
- Building the application in a clean environment.
- Deploying to a test or staging environment.
- Deploying to production, with appropriate approvals.
Choose tasks that are frequent, error-prone or slow. A task done once a year by hand may not be worth automating yet; a task done daily almost always is.
Common mistakes to avoid
- Automating a broken process. If your manual steps include unnecessary work, remove it before scripting it.
- Treating the pipeline as someone else's job. The whole team should understand and maintain it, just like application code.
- Skipping tests to save time. A pipeline without meaningful tests deploys broken code faster.
- Hard-coding secrets in workflow files or scripts. Use the secret store from the start.
- Trying to build the perfect pipeline at once. Start small and improve it in small steps.
Exercise
Write down the exact steps you or your team follow today to release one application, as a numbered list, including who does each step and roughly how long it takes. Mark each step as easy to automate, hard to automate or unnecessary. Circle the first two steps you would automate and explain why in one sentence each.
Key points
- Manual releases are slow, inconsistent and push teams towards large, risky releases.
- Automation gives consistency, speed, fast feedback, traceability and safer credential handling.
- Start by automating tests on pull requests, then builds and deployments.
- Fix the process before you automate it, and keep secrets out of files.