|
| 1 | +# **Development Workflow & Architecture Guide** |
| 2 | + |
| 3 | +This document outlines the standardized development workflow, repository architecture, and branching strategy for this project. Adhering to these guidelines ensures consistency, maintainability, and a scalable development process. |
| 4 | + |
| 5 | +## 1. Technology Stack |
| 6 | + |
| 7 | +The project is built upon the following core technologies: |
| 8 | + |
| 9 | +- **Backend**: FastAPI |
| 10 | +- **Backend Package Manager**: Poetry |
| 11 | +- **Frontend**: React + JavaScript |
| 12 | +- **Database**: PostgreSQL |
| 13 | +- **Caching**: Redis |
| 14 | +- **Containerization**: Docker |
| 15 | + |
| 16 | +## 2. Architectural Overview: A Multi-Repo Strategy |
| 17 | + |
| 18 | +To promote scalability, team autonomy, and clear separation of concerns, this project adopts a **multi-repo architecture**. Each core component of the system resides in its own dedicated repository. This approach allows for independent development cycles, testing, and deployment. |
| 19 | + |
| 20 | +Our architecture is composed of three main repositories: |
| 21 | + |
| 22 | +### 2.1. Backend Service (`project-backend`) |
| 23 | + |
| 24 | +This repository contains all code related to the FastAPI backend service. Its primary responsibility is to handle business logic, interact with the database, and expose a RESTful API. |
| 25 | + |
| 26 | +**Folder Structure:** |
| 27 | +``` |
| 28 | +project-backend/ |
| 29 | +├── .github/ # CI workflows: tests, builds, and publishes the Docker image |
| 30 | +│ └── workflows/ |
| 31 | +│ └── main.yml |
| 32 | +├── src/ |
| 33 | +│ └── app/ # Main Python package |
| 34 | +│ ├── api/ # API routers & endpoints |
| 35 | +│ ├── db/ # Database session management & base models |
| 36 | +│ ├── models/ # SQLAlchemy ORM models (database table definitions) |
| 37 | +│ ├── schemas/ # Pydantic schemas for validation/serialization |
| 38 | +│ ├── core/ # Business logic (services, utilities, etc.) |
| 39 | +│ ├── config/ # settings.py & constants.py for configuration |
| 40 | +│ └── main.py # FastAPI application entrypoint |
| 41 | +├── Alembic/ # Database migrations managed with Alembic |
| 42 | +│ ├── versions/ # Generated migration files |
| 43 | +│ ├── env.py # Alembic environment setup |
| 44 | +│ └── script.py.mako # Template for new migrations |
| 45 | +├── tests/ # Unit and integration tests |
| 46 | +├── alembic.ini # Alembic configuration file |
| 47 | +├── py.ini # Python tool configurations (flake8, mypy, etc.) |
| 48 | +├── .env.example # Template for environment variables |
| 49 | +├── .gitignore # Files and paths ignored by Git |
| 50 | +├── docker-compose.override.yml # Local overrides (e.g., hot-reload) |
| 51 | +├── docker-compose.test.yml # Docker Compose setup for isolated testing |
| 52 | +├── docker-compose.yml # Base Docker Compose configuration for development |
| 53 | +├── Dockerfile # Instructions to build the production Docker image |
| 54 | +├── poetry.lock # Locked dependency versions for Poetry |
| 55 | +├── pyproject.toml # Poetry project configuration (including src layout) |
| 56 | +└── README.md # Setup instructions and project overview |
| 57 | +
|
| 58 | +``` |
| 59 | + |
| 60 | +**Key Responsibilities:** |
| 61 | +* To be testable in isolation. |
| 62 | +* To produce a versioned Docker image (`backend:<tag>`) as its main artifact. |
| 63 | + |
| 64 | +### 2.2. Frontend Service (`project-frontend`) |
| 65 | + |
| 66 | +This repository contains all code for the React web application. Its responsibility is to provide the user interface and interact with the backend via its API. |
| 67 | + |
| 68 | +**Folder Structure:** |
| 69 | +``` |
| 70 | +project-frontend/ |
| 71 | +├── .github/ |
| 72 | +│ └── workflows/ |
| 73 | +│ └── main.yml # CI: Tests and publishes the frontend Docker image |
| 74 | +├── public/ # Static assets (index.html, favicon, etc.) |
| 75 | +├── src/ # Application source code |
| 76 | +│ ├── api/ # Functions for backend API calls |
| 77 | +│ ├── components/ # Reusable UI components |
| 78 | +│ ├── hooks/ # Custom React hooks |
| 79 | +│ ├── mocks/ # Service worker mocks for API (for isolated testing) |
| 80 | +│ ├── pages/ # Page components |
| 81 | +│ └── index.js # React application entrypoint |
| 82 | +├── .env.example |
| 83 | +├── .gitignore |
| 84 | +├── docker-compose.yml # Base local development definition |
| 85 | +├── Dockerfile # Multi-stage build for a lean production image |
| 86 | +├── package.json |
| 87 | +├── package-lock.json |
| 88 | +└── README.md # Setup instructions for the frontend service |
| 89 | +``` |
| 90 | + |
| 91 | +**Key Responsibilities:** |
| 92 | +* To be testable in isolation (using a mocked API). |
| 93 | +* To produce a versioned, production-ready Docker image (`frontend:<tag>`), typically served by Nginx. |
| 94 | + |
| 95 | +### 2.3. Infrastructure & E2E Tests (`project-master`) |
| 96 | + |
| 97 | +This repository is the "glue" that holds the system together. It does not contain application code but rather the configuration to orchestrate, test, and deploy the entire system. |
| 98 | + |
| 99 | +**Folder Structure:** |
| 100 | +``` |
| 101 | +project-master/ |
| 102 | +├── .github/ |
| 103 | +│ └── workflows/ |
| 104 | +│ ├── e2e-tests.yml # CI: Runs End-to-End tests on a complete stack |
| 105 | +│ └── deploy.yml # CD: Handles deployment to environments |
| 106 | +├── e2e-tests/ # End-to-End test suite (e.g., Cypress, Playwright) |
| 107 | +│ ├── cypress/ # Test code |
| 108 | +│ └── cypress.config.js |
| 109 | +├── environments/ # Environment-specific configurations |
| 110 | +│ ├── staging/ |
| 111 | +│ │ ├── docker-compose.yml # Docker Compose file for the Staging environment |
| 112 | +│ │ └── .env.example |
| 113 | +│ └── production/ |
| 114 | +│ ├── docker-compose.yml # Docker Compose file for the Production environment |
| 115 | +│ └── .env.example |
| 116 | +├── scripts/ # Deployment and utility scripts |
| 117 | +│ ├── deploy-staging.sh |
| 118 | +│ └── deploy-prod.sh |
| 119 | +└── README.md # Main project README: explains the overall architecture |
| 120 | +``` |
| 121 | + |
| 122 | +**Key Responsibilities:** |
| 123 | +* To define the composition of services for each environment (Staging, Production). |
| 124 | +* To run End-to-End tests that validate the integration between services. |
| 125 | +* To manage the Continuous Deployment (CD) process. |
| 126 | + |
| 127 | +## 3. Branching Strategy: Git Flow |
| 128 | + |
| 129 | +To manage code development and releases in a structured manner, we use the **Git Flow** branching model. |
| 130 | + |
| 131 | +### Git Flow Workflow Diagram |
| 132 | + |
| 133 | +```mermaid |
| 134 | +--- |
| 135 | +title: Git Flow |
| 136 | +--- |
| 137 | +
|
| 138 | +gitGraph |
| 139 | + commit id: "Initial commit" |
| 140 | + branch develop |
| 141 | + checkout develop |
| 142 | + commit id: "Setup Project" |
| 143 | +
|
| 144 | + branch feature/user-authentication |
| 145 | + checkout feature/user-authentication |
| 146 | + commit id: "feat: Add login form" |
| 147 | + commit id: "feat: Add form validation" |
| 148 | + checkout develop |
| 149 | + merge feature/user-authentication |
| 150 | +
|
| 151 | + branch release/v1.0.0 |
| 152 | + checkout release/v1.0.0 |
| 153 | + commit id: "fix: Pre-release bug fixes" tag: "v1.0.0" |
| 154 | + checkout main |
| 155 | + merge release/v1.0.0 |
| 156 | + checkout develop |
| 157 | + merge release/v1.0.0 |
| 158 | +
|
| 159 | + checkout main |
| 160 | + branch hotfix/critical-login-bug |
| 161 | + checkout hotfix/critical-login-bug |
| 162 | + commit id: "fix: Critical production bug" tag: "v1.0.1" |
| 163 | + checkout main |
| 164 | + merge hotfix/critical-login-bug |
| 165 | + checkout develop |
| 166 | + merge hotfix/critical-login-bug |
| 167 | +``` |
| 168 | + |
| 169 | +--- |
| 170 | + |
| 171 | +### Git Flow Explained |
| 172 | + |
| 173 | +This workflow is built upon two long-lived branches and several temporary, supporting branches. |
| 174 | + |
| 175 | +#### Main Branches |
| 176 | + |
| 177 | +1. **`main`** |
| 178 | + * **Purpose**: This branch contains **production-ready, stable code**. Every commit on `main` represents a new, official release. |
| 179 | + * **Rules**: You should **never** commit directly to `main`. It only receives merges from `release/*` and `hotfix/*` branches. Each merge should be tagged with a version number (e.g., `v1.0.0`). |
| 180 | + |
| 181 | +2. **`develop`** |
| 182 | + * **Purpose**: This is the main **integration branch** for ongoing development. It contains all completed and tested features that are planned for the next release. |
| 183 | + * **Rules**: It's the base for creating new `feature/*` branches. It reflects the most up-to-date state of development. |
| 184 | + |
| 185 | +#### Supporting Branches |
| 186 | + |
| 187 | +3. **`feature/*`** (e.g., `feature/user-authentication`) |
| 188 | + * **Purpose**: To develop a new, specific feature in isolation. |
| 189 | + * **Lifecycle**: |
| 190 | + 1. Branched off of **`develop`**. |
| 191 | + 2. Once development is complete, a **Pull Request (PR)** is opened to merge the changes back into **`develop`**. |
| 192 | + 3. After the merge, the `feature/*` branch can be deleted. |
| 193 | + |
| 194 | +4. **`release/*`** (e.g., `release/v1.2.0`) |
| 195 | + * **Purpose**: To prepare for a new production release. This branch is used for final bug fixes, documentation updates, and last-minute testing. It freezes the feature set for the release. |
| 196 | + * **Lifecycle**: |
| 197 | + 1. Branched off of **`develop`** when it's decided that the next version is feature-complete. |
| 198 | + 2. When ready, it is merged into **`main`** (and tagged) and also back into **`develop`** to ensure any fixes made during the release phase are not lost. |
| 199 | + 3. After merging, the `release/*` branch can be deleted. |
| 200 | + |
| 201 | +5. **`hotfix/*`** (e.g., `hotfix/critical-login-bug`) |
| 202 | + * **Purpose**: To quickly patch a critical bug discovered in the production version (`main`). |
| 203 | + * **Lifecycle**: |
| 204 | + 1. Branched off of **`main`** (from the specific version tag). |
| 205 | + 2. Once the fix is ready, it is merged into **`main`** (and a new patch version tag is created, e.g., `v1.0.1`). |
| 206 | + 3. It is also merged into **`develop`** to ensure the fix is included in future releases. |
| 207 | + 4. After merging, the `hotfix/*` branch can be deleted. |
| 208 | + |
| 209 | +## 4. Continuous Integration / Continuous Delivery (CI/CD) Pipeline |
| 210 | + |
| 211 | +A robust CI/CD pipeline guarantees that every change pushed to the repository is automatically validated, packaged, and—when appropriate—promoted to the next environment. |
| 212 | +Our pipeline is built with **GitHub Actions** and follows a layered approach that mirrors the Git Flow branching model. |
| 213 | + |
| 214 | +We will start to describe the CI part related to push and PR in the develop branch of the backend service. |
| 215 | + |
| 216 | +### 4.1 CI for project-backend on `develop` |
| 217 | + |
| 218 | +#### 4.1.1 Goals |
| 219 | + |
| 220 | +* **Fast feedback** – linting, type-checking, and unit tests finish in under a minute for every Pull Request. |
| 221 | +* **Confidence in integration** – migrations, integration tests, and Docker smoke-tests run on every push to `develop`. |
| 222 | +* **Deployment safety** – only artifacts produced from a green pipeline can be released or deployed. |
| 223 | +* **Parity with production** – the same multi-stage Dockerfile is built and probed in CI, preventing “works-on-my-machine” surprises. |
| 224 | + |
| 225 | +### 4.1.2 Pipeline Layers |
| 226 | + |
| 227 | +* **Quick Suite (PR to `develop`)** |
| 228 | + *Runs in seconds; no external services or containers.* |
| 229 | + |
| 230 | + * Black, isort, Flake8 |
| 231 | + * mypy static type-checking |
| 232 | + * Unit tests only (`pytest -m "not integration"`) |
| 233 | + |
| 234 | +* **Full Suite (push to `develop`)** |
| 235 | + *Runs in a few minutes; includes real services and Docker.* |
| 236 | + |
| 237 | + * All steps from the Quick Suite |
| 238 | + * PostgreSQL service container started via `services:` |
| 239 | + * Alembic migrations applied to the test database |
| 240 | + * Full test suite, including `@pytest.mark.integration` tests |
| 241 | + * Multi-stage Docker build of the backend image |
| 242 | + * Smoke test: container started with Uvicorn → `curl /health` |
| 243 | + |
| 244 | + |
| 245 | +### 4.1.3 Key Implementation Details |
| 246 | + |
| 247 | +* **Service containers** – PostgreSQL 17 is spun up in CI with a health-check to ensure migrations run against a live instance. |
| 248 | +* **Test markers** – integration tests are isolated with `@pytest.mark.integration`, enabling selective execution. |
| 249 | +* **Caching** – Poetry’s download cache is restored to cut installation time; Docker layer cache is reused between builds. |
| 250 | +* **Smoke test logic** – after the image is built, CI launches it in detached mode, polls the `/health` endpoint, prints logs, and stops the container. The job fails if the endpoint is unreachable. |
| 251 | +* **Secrets management** – database credentials and registry tokens are stored in GitHub Secrets and injected as environment variables only at runtime. |
| 252 | + |
| 253 | + |
0 commit comments