From Code to Cloud: A Beginner’s Guide to CI/CD with GitHub Actions

Intergrating a simulator ecommerce site with mysql, redis

how to connect an express application to postgres and setup jwt authentication

Setting up jwt authentication, routes and a postgres connection

Creating a server in node(Express)

Simulator commerce: APIs

Server side with javascript 

AppFlow Tracker is an open-source Django + React application. Every code snippet and workflow file in this article is live and working in the repository. You can run the app right now — no setup required.

Before we talk about automation, let’s get the app running. You have two options.

Option A — Pull the Docker images (fastest, no code needed)

# 1. Pull both images from Docker Hub
docker pull kennjenga/appflow-tracker-backend:latest
docker pull kennjenga/appflow-tracker-frontend:latest

services:
	backend:
		image: kennjenga/appflow-tracker-backend:latest
		environment:
			SECRET_KEY: local-demo-only
			DEBUG: "True"
			ALLOWED_HOSTS: localhost,127.0.0.1
			CORS_ALLOWED_ORIGINS: http://localhost,http://127.0.0.1
			DJANGO_DB_PATH: /app/db/db.sqlite3
		volumes:
			- sqlite_data:/app/db
		expose:
			- "8000"
	frontend:
		image: kennjenga/appflow-tracker-frontend:latest
		ports:
			- "80:80"
		depends_on:
			- backend
volumes:
	sqlite_data:

# 2. Start the app
docker compose up

# 3. Open your browser
#    App:       http://localhost
#    API docs:  http://localhost/api/v1/docs
#    Admin:     http://localhost/admin

Option B — Clone the repository and run locally

# 1. Clone
git clone https://github.com/Kennjenga/appflow-tracker.git
cd appflow-tracker

# 2. Copy the Docker env file
cp .env.docker.example .env.docker

# 3. Build and start (first run downloads base images + installs deps)
docker compose up --build

# 4. Create an admin user (first run only)
docker compose exec backend python manage.py createsuperuser

Docker Compose built two containers from the source code:

One running the built React app via Nginx

It also connected them on a private network.

The GitHub Actions workflows we’re about to study are what 

 and pushed them to Docker Hub automatically.

GitHub Actions is an automation platform 

You write a YAML file, put it in a special folder in your repository, and GitHub automatically runs it whenever something happens:

No extra accounts. No separate CI/CD server. It’s already there.

your-project/
├── src/
├── tests/
└── .github/
	└── workflows/
		├── pr-tests.yml          ← runs on every Pull Request
		└── docker-publish.yml    ← runs on every push to master

Two YAML files can be enough for two fully automated pipelines.

Everything in GitHub Actions is built from four building blocks:

An event is what kicks the workflow off. You choose which events to listen for.

on:
	push:               # Code was pushed to the repo
		branches:
			- master
	pull_request:       # A PR was opened or updated
		branches:
			- master
			- staging
	schedule:           # Runs on a timer (cron syntax)
		- cron: '0 2 * * *'   # Every day at 2 AM UTC
	workflow_dispatch:  # Manual "Run workflow" button in GitHub UI

One YAML file equals one workflow. A workflow contains one or more jobs.

Each job runs on its own fresh virtual machine (a 

jobs:
	test:
		runs-on: ubuntu-latest
		steps: [...]
	build:
		runs-on: ubuntu-latest
		needs: test
		steps: [...]
	deploy:
		runs-on: ubuntu-latest
		needs: build
		steps: [...]

steps:
	- name: Checkout code
		uses: actions/checkout@v4
	- name: Install dependencies
		run: pip install -r requirements.txt
	- name: Run tests
		run: pytest
		env:
			SECRET_KEY: $ secrets.SECRET_KEY 

 Every time a developer opens or updates a Pull Request targeting 

, this pipeline automatically runs the full test suite. If any test fails, the PR is blocked from merging.

: automatically validating every code change before it touches a protected branch.

# ════════════════════════════════════════════════════════════════════════════
#  CI Pipeline — Runs on every Pull Request targeting master or staging
#
#  What this pipeline does:
#    Job 1 (backend-tests)  → Install Python deps → Run pytest
#    Job 2 (frontend-tests) → Install Node deps  → Run Vitest → Vite build
#
#  Both jobs run in PARALLEL (no `needs:` between them).
#  The PR is only considered green when BOTH jobs pass. ✅
# ════════════════════════════════════════════════════════════════════════════

name: PR Tests

# ── TRIGGER ─────────────────────────────────────────────────────────────────
on:
	pull_request:
		branches:
			- master
			- staging

# ── JOBS ─────────────────────────────────────────────────────────────────────
jobs:
	backend-tests:
		name: 🐍 Backend — pytest
		runs-on: ubuntu-latest
		defaults:
			run:
				working-directory: backend
		steps:
			- name: Checkout repository
				uses: actions/checkout@v4

			- name: Set up Python 3.12
				uses: actions/setup-python@v5
				with:
					python-version: '3.12'

			- name: Cache pip dependencies
				uses: actions/cache@v4
				with:
					path: ~/.cache/pip
					key: pip-$ runner.os -$ hashFiles('**/requirements.txt') 
					restore-keys: |
						pip-$ runner.os -

			- name: Install dependencies
				run: pip install -r requirements.txt

			- name: Django system check
				run: python manage.py check
				env:
					SECRET_KEY: ci-only-not-a-real-secret
					DEBUG: "True"

			- name: Run pytest
				run: pytest --tb=short -v
				env:
					SECRET_KEY: ci-only-not-a-real-secret
					DEBUG: "True"

	frontend-tests:
		name: ⚛️ Frontend — Vitest + Build
		runs-on: ubuntu-latest
		defaults:
			run:
				working-directory: frontend
		steps:
			- name: Checkout repository
				uses: actions/checkout@v4

			- name: Set up Node.js 20
				uses: actions/setup-node@v4
				with:
					node-version: '20'

			- name: Cache node_modules
				uses: actions/cache@v4
				with:
					path: frontend/node_modules
					key: node-$ runner.os -$ hashFiles('**/package-lock.json') 
					restore-keys: |
						node-$ runner.os -

			- name: Install dependencies
				run: npm ci

			- name: Run Vitest tests
				run: npm run test

			- name: Production build check
				run: npm run build
				env:
					VITE_API_BASE_URL: http://localhost:8000/api/v1

Developer opens a PR → master or staging
			↓
	[Event: pull_request fires]
			↓
┌───────────────────┐   ┌───────────────────────┐
│ 🐍 backend-tests  │   │ ⚛️ frontend-tests      │  ← run in PARALLEL
│ 1. Checkout code  │   │ 1. Checkout code       │
│ 2. Setup Python   │   │ 2. Setup Node 20       │
│ 3. Cache pip      │   │ 3. Cache node_modules  │
│ 4. pip install    │   │ 4. npm ci              │
│ 5. Django check   │   │ 5. npm run test        │
│ 6. pytest         │   │ 6. npm run build       │
└────────┬──────────┘   └──────────┬────────────┘
		│   both must pass ✅      │
		└──────────┬──────────────┘
					↓
		PR gets a green checkmark → team can safely merge

5. Workflow 2 — Docker Hub Publish (CD)

, this pipeline builds Docker images for the backend and frontend, and pushes them to Docker Hub.

: automatically shipping a new version after every passing merge.

name: Build & Push to Docker Hub

on:
	push:
		branches:
			- master
	workflow_dispatch:

env:
	REGISTRY: docker.io
	BACKEND_IMAGE: kennjenga/appflow-tracker-backend
	FRONTEND_IMAGE: kennjenga/appflow-tracker-frontend

jobs:
	build-backend:
		name: Backend — Build & Push
		runs-on: ubuntu-latest
		permissions:
			contents: read
		steps:
			- name: Checkout repository
				uses: actions/checkout@v4

			- name: Set up Docker Buildx
				uses: docker/setup-buildx-action@v3

			- name: Log in to Docker Hub
				uses: docker/login-action@v3
				with:
					username: $ secrets.DOCKERHUB_USERNAME 
					password: $ secrets.DOCKERHUB_TOKEN 

			- name: Extract metadata (tags & labels)
				id: meta-backend
				uses: docker/metadata-action@v5
				with:
					images: $ env.BACKEND_IMAGE 
					tags: |
						type=raw,value=latest,enable=is_default_branch
						type=sha,prefix=sha-,format=short

			- name: Build and push backend image
				uses: docker/build-push-action@v6
				with:
					context: ./backend
					file: ./backend/Dockerfile
					push: true
					tags: $ steps.meta-backend.outputs.tags 
					labels: $ steps.meta-backend.outputs.labels 
					cache-from: type=gha,scope=backend
					cache-to: type=gha,mode=max,scope=backend
					platforms: linux/amd64,linux/arm64

	build-frontend:
		name: Frontend — Build & Push
		runs-on: ubuntu-latest
		permissions:
			contents: read
		steps:
			- name: Checkout repository
				uses: actions/checkout@v4

			- name: Set up Docker Buildx
				uses: docker/setup-buildx-action@v3

			- name: Log in to Docker Hub
				uses: docker/login-action@v3
				with:
					username: $ secrets.DOCKERHUB_USERNAME 
					password: $ secrets.DOCKERHUB_TOKEN 

			- name: Extract metadata (tags & labels)
				id: meta-frontend
				uses: docker/metadata-action@v5
				with:
					images: $ env.FRONTEND_IMAGE 
					tags: |
						type=raw,value=latest,enable=is_default_branch
						type=sha,prefix=sha-,format=short

			- name: Build and push frontend image
				uses: docker/build-push-action@v6
				with:
					context: ./frontend
					file: ./frontend/Dockerfile
					push: true
					tags: $ steps.meta-frontend.outputs.tags 
					labels: $ steps.meta-frontend.outputs.labels 
					build-args: |
						VITE_API_BASE_URL=/api/v1
					cache-from: type=gha,scope=frontend
					cache-to: type=gha,mode=max,scope=frontend
					platforms: linux/amd64,linux/arm64

Developer merges PR → master
		↓
[Event: push to master fires]
		↓
┌──────────────────────────┐   ┌───────────────────────────┐
│ build-backend             │   │ build-frontend             │  ← PARALLEL
│ 1. Checkout               │   │ 1. Checkout                │
│ 2. Setup Buildx           │   │ 2. Setup Buildx            │
│ 3. Login to Docker Hub    │   │ 3. Login to Docker Hub     │
│ 4. Generate :latest tag   │   │ 4. Generate :latest tag    │
│    and :sha-abc1234 tag   │   │    and :sha-abc1234 tag    │
│ 5. Build + Push image     │   │ 5. Build + Push image      │
└──────────────────────────┘   └───────────────────────────┘
					↓
Images are updated on Docker Hub

username: $ secrets.DOCKERHUB_USERNAME 
password: $ secrets.DOCKERHUB_TOKEN 

 are encrypted key-value pairs stored in GitHub, never in your code.

Copy the token immediately. It is only shown once.

GitHub masks secrets in logs. Even if a step prints a secret, it will show as 

Without caching, every pipeline run downloads all dependencies from scratch. For a Python + Node project this can add minutes per run. Caching can cut repeat runs down dramatically.

✅ Published

vaAp1m-aMuLBjQuE1MqdF.jpg

https://ik.imagekit.io/jlez6y282/portfolio/ecommere.jpeg?updatedAt=1739433063139

https://ik.imagekit.io/jlez6y282/portfolio/postgres_jwt_setup.jpeg?updatedAt=1739432722583

articles

https://images.unsplash.com/photo-1730994424470-e9351ec61da8?w=500&auto=format&fit=crop&q=60&ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwcm9maWxlLXBhZ2V8MXx8fGVufDB8fHx8fA%3D%3D

https://ik.imagekit.io/jlez6y282/portfolio/apis1.jpeg?updatedAt=1741849528304

https://images.unsplash.com/photo-1659079631665-eb95370fb173?q=80&w=1330&auto=format&fit=crop&ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D

THE LEDGER:
EDITORIAL INSIGHTS

From Code to Cloud: A Beginner’s Guide to CI/CD with GitHub Actions

Njenga AI

From Code to Cloud: A Beginner’s Guide to CI/CD with GitHub Actions

CONTEXTUAL EXPLORATION

Hardware Accelerators

Zero Trust Compute

Graph Theory in UX

Njenga AI