6. Continuous Integration and Continuous Deployment with GitHub Actions

6.1 Overview of the Automation Strategy

The continuous integration and continuous deployment (CI/CD) process is implemented through GitHub Actions using a workflow definition located at .github/workflows/workflow.yml. This workflow is designed to automate, in a unified and reproducible manner, the validation, documentation generation, and release management phases of the project lifecycle. By integrating these activities into a single automated pipeline, the repository ensures consistency between code changes, documentation updates, and published releases, while reducing manual intervention and the risk of human error.

6.2 Workflow Architecture and Execution Logic

The workflow is composed of several logically separated jobs, each responsible for a specific stage of the CI/CD process. These jobs are executed according to clearly defined triggering conditions, primarily based on repository events and branch context. The structure reflects a progressive validation model in which foundational checks are performed first, followed by documentation deployment and release creation when the code reaches a stable state.

6.3 Environment Setup and Dependency Initialization

The initial job, referred to as the setup phase, is executed on every push and on every pull request. Its primary purpose is to establish a controlled and reproducible execution environment. During this phase, a Python runtime environment is provisioned, ensuring that subsequent jobs operate under consistent interpreter conditions. All dependencies defined under the pipeline group are then installed, which guarantees that the tools required for validation, documentation generation, and automation are available before any further processing occurs. This step functions as a foundational safeguard, as failures at this stage prevent downstream jobs from executing under incomplete or misconfigured conditions.

6.4 Documentation Build and Deployment on the Main Branch

When changes are merged into the main branch, the workflow activates an additional job dedicated to documentation management. In this phase, the project documentation is built using MkDocs, a static site generator specifically designed for technical documentation. The resulting site is then automatically deployed to GitHub Pages, ensuring that the published documentation always reflects the current state of the main codebase.

Version management of the documentation is handled through mike, which enables the coexistence of multiple documentation versions corresponding to different project releases. This approach allows users to consult documentation aligned with specific versions of the software, thereby improving traceability and long-term maintainability. The deployment process is fully automated and does not require manual approval once the workflow conditions are satisfied.

6.5 Automated Release Creation and Versioning

Also restricted to the main branch, the release creation job formalizes the delivery of a new software version. During this stage, the workflow programmatically determines the current project version and uses this information to create a new GitHub release. Release notes are generated automatically, typically by aggregating relevant commit messages or changes since the previous release. This ensures that each release is consistently documented and that users have immediate access to a structured summary of modifications, enhancements, and fixes.

By integrating release creation into the CI/CD pipeline, the workflow enforces a direct relationship between the main branch state and published artifacts, reducing discrepancies between source code and released versions.

6.6 GitHub Pages Configuration and Activation

For the automated documentation deployment to function correctly, GitHub Pages must be configured to use GitHub Actions as its source. This configuration is performed within the repository settings by navigating to the Pages section and selecting GitHub Actions as the publication source. Once this setting is applied, every push to the main branch triggers the documentation build and deployment process defined in the workflow. As a result, the documentation site is continuously updated without requiring any additional manual steps, ensuring alignment between the repository content and its public technical documentation.