CI/CD

This part includes a description of the Continuous Integration / Continuous Deployment (CI/CD) workflow of project.

What Is Automated?

CI/CD is now partially used for main application and fully implemented for report site.

  • Optional CLI-based automation using Makefile and setup.ps1 for local install/test/run tasks

Workflow includes:

  • Run unit and integration tests using pytest
  • Package application with setup.py
  • Automatically publish to PyPI using GitHub Actions when version tag is pushed
  • Auto-deployment of report site via GitHub Pages on every push to main
  • Markdown structure validation during report build (Jekyll)

Why Automate?

Automation is a critical step in modern software development because:

  • Ensures code quality –> repeatable checks
  • Reduces manual errors –> testing and deployment
  • Enables fast feedback –> each commit or pull request
  • Helps maintain project stability –> working in teams

This app is simple and developed by a small team(one person), preparing for CI/CD aligns with industry practices and sets up the project for easier reuse.

How CI/CD Is Implemented

GitHub Actions (for Report Site)

In report repository, GitHub Actions are configured to automate report deployment process.

  • Static site generated by Jekyll, a tool converting Markdown content into navigable website.
  • Every time commit pushed to main branch, workflow automatically builds site and publishes it to GitHub Pages.

automation is defined in the file:
.github/workflows/github-pages.yml

Branch Strategy for CI/CD

My artifact repository has a branching strategy with feature branches:

  • The main branch is deployment-ready and stable branch.
  • Development work is done in branches like error-pages-feature and login-register-pages.
  • After development and testing, changes merged in main, which then becomes release source.

This approach can be a good plan to help isolate experimental work, and having cleaner pull request, and keeps the main branch stable for CI/CD.

This strategy allows clean separation between experimental features and release-ready code. Combined with tagging and GitHub Actions, this enables a partial CI/CD pipeline for production deployment.

For report repository, a simpler setup is used:

  • All updates pushed directly to main, for auto-trigger of GitHub Pages.

This balance between simple deployment and isolated development makes the project easier to manage while still CI/CD-friendly.

GitHub Actions (for Application Repository)

A GitHub Actions workflow is defined in .github/workflows/pypi-deploy.yml. This workflow is triggered when release tag (v1.0.0) is pushed.

Workflow:

  • Installs project dependencies
  • Runs all tests using pytest
  • Builds the package with setup.py,which includes metadata (name, version, license, dependencies, classifiers)
  • Publishes the release to PyPI using twine It enables continuous deployment to PyPI and ensures code correctness for each release.

A second workflow file, python-ci.yml, was added to automate quality checks on main.
It includes:

  • Syntax validation using py_compile
  • Dependency installation (both dev and runtime)
  • Running all tests with pytest helping to catch bugs early and clean builds before publishing.