add images to developer-task-workflow

docs/workflow/FlyWay for postgresql + CICD/FlyWay workflow + CICD.md

@@ -0,0 +1,306 @@
+# Flyway Setup Guide for PostgreSQL + Tomcat Deployment
+
+## Goal
+
+This setup allows automatic database updates during deployment.
+
+Each database modification is added as a new SQL migration file. During CI/CD deployment, Flyway executes only the missing migrations safely and in order.
+
+This avoids:
+
+- giant SQL files
+- duplicate executions
+- manual tracking of DB changes
+- production inconsistencies
+
+---
+
+# Environment
+
+This guide is adapted for:
+
+- PostgreSQL 17
+- Java 17
+- Maven Wrapper (`mvnw.cmd`)
+- Tomcat deployment
+- Existing production databases
+- Windows CI/CD runner
+
+---
+
+# 1. Add Flyway to Maven
+
+## Add Flyway Maven Plugin
+
+In `pom.xml`:
+
+```xml
+<plugin>
+    <groupId>org.flywaydb</groupId>
+    <artifactId>flyway-maven-plugin</artifactId>
+    <version>11.0.0</version>
+</plugin>
+```
+
+---
+
+## 2. Create Migration Folder
+
+Create this folder inside the project:
+
+```text
+src/main/resources/db/migration
+```
+
+---
+
+# 3. Migration Naming Convention while for each Db modification a new file is added
+
+Flyway requires this exact format:
+
+```text
+V<version>__<description>.sql
+```
+
+Examples:
+
+```text
+V1__initial_schema.sql
+V2__task301_add_tables_t1_t2.sql
+V3__add_client_phone.sql
+V4__fix_invoice_indexes.sql
+```
+
+Important:
+
+- Use TWO underscores (`__`) after the version
+- Never rename old migrations after execution
+- Never modify old executed migrations
+
+---
+
+# 4. Existing Database Initialization (One-Time Only)
+
+Since the database already exists in production, Flyway must first create its history table.
+
+## First Migration
+
+Create:
+
+```text
+V1__initial_schema.sql
+```
+
+This file represents the current database structure.
+
+---
+
+## Baseline Existing Database
+
+Run once only:
+
+```cmd
+mvn flyway:baseline ^
+-Dflyway.url=jdbc:postgresql://localhost:5432/TrizTresorie ^
+-Dflyway.user=postgres ^
+-Dflyway.password=YOUR_PASSWORD ^
+-Dflyway.baselineVersion=1
+```
+
+This creates:
+
+```text
+flyway_schema_history
+```
+
+and marks version `1` as already applied WITHOUT executing the SQL.
+
+---
+
+# 5. Adding New Database Changes
+
+Every new database modification must be added as a new migration file.
+
+Example:
+
+```text
+V2__task301_add_tables_t1_t2.sql
+```
+
+Example content:
+
+```sql
+CREATE TABLE table1 (
+    id BIGSERIAL PRIMARY KEY
+);
+
+CREATE TABLE table2 (
+    id BIGSERIAL PRIMARY KEY
+);
+```
+
+Commit the migration file with the application code.
+
+---
+
+# 6. Running Migrations
+
+To execute pending migrations:
+
+```cmd
+mvn flyway:migrate ^
+-Dflyway.url=jdbc:postgresql://localhost:5432/TrizTresorie ^
+-Dflyway.user=postgres ^
+-Dflyway.password=YOUR_PASSWORD
+```
+
+Flyway will:
+
+1. Check `flyway_schema_history`
+2. Detect already executed migrations
+3. Execute only new migrations
+4. Save execution history automatically
+
+---
+
+# 7. CI/CD Integration
+
+Add this step before starting Tomcat.
+
+## Example
+
+```yaml
+# --------------------------------------------------
+# Run database migrations
+# --------------------------------------------------
+- name: Run database migrations
+  shell: cmd
+  run: |
+    cd %WORKSPACE_DIR%
+    mvnw.cmd flyway:migrate ^
+    -Dflyway.url=%DB_URL% ^
+    -Dflyway.user=%DB_USER% ^
+    -Dflyway.password=%DB_PASSWORD%
+```
+
+Recommended:
+
+- Store DB credentials in CI/CD secrets or environment variables
+- Do not hardcode passwords inside the repository
+
+---
+
+# 8. Recommended Developer Workflow
+
+When a developer needs a database change:
+
+## DO
+
+Create a new migration:
+
+```text
+V5__add_product_status.sql
+```
+
+Commit and push.
+
+---
+
+## DO NOT
+
+Do NOT modify:
+
+```text
+V1__initial_schema.sql
+```
+
+or any already executed migration.
+
+Always create a new migration instead.
+
+---
+
+# 9. Important Notes
+
+## Migration Order
+
+Flyway executes migrations in version order:
+
+```text
+V1
+V2
+V3
+V4
+```
+
+---
+
+## Failed Migrations
+
+If a migration fails:
+
+- deployment stops
+- Tomcat should not start
+- database remains protected from partial execution
+
+Fix the migration and rerun deployment.
+
+---
+
+## Production Safety
+
+Do not:
+
+- delete `flyway_schema_history`
+- modify old executed migrations
+- manually rerun executed SQL files
+
+---
+
+# 10. Example Project Structure
+
+```text
+project/
+│
+├── src/
+│   └── main/
+│       └── resources/
+│           └── db/
+│               └── migration/
+│                   ├── V1__initial_schema.sql
+│                   ├── V2__task301_add_tables_t1_t2.sql
+│                   ├── V3__add_client_phone.sql
+│                   └── V4__fix_indexes.sql
+│
+├── pom.xml
+└── mvnw.cmd
+```
+
+---
+
+# 11. Final Deployment Flow
+
+Recommended deployment sequence:
+
+1. Clone source
+2. Build application
+3. Stop Tomcat
+4. Backup configuration
+5. Deploy new application
+6. Restore configuration
+7. Run Flyway migrations
+8. Start Tomcat
+9. Cleanup workspace
+
+---
+
+# Result
+
+With this setup:
+
+- database updates become automatic
+- all environments stay synchronized
+- production deployments become safer
+- developers only add new migration files
+- no manual SQL tracking is needed
+

docs/workflow/FlyWay for postgresql + CICD/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Data Base Modification Workflow + flyway + CICD",
+  "position": 2,
+  "link": {
+    "type": "generated-index",
+    "description": "Standard workflow for Data Base Modification + flyway + CICD."
+  }
+}

docs/workflow/task-workflow/02-merging-and-completing.md

@@ -57,6 +57,10 @@ and used the aspose-cells library for the file generation.
 Tested with datasets of up to 10,000 rows.
 ```
 
+![Task Comment](img/3.png)
+
 ## Step 14 — Stop the Timer
 
 Stop your timer. The task is complete.
+
+![Timer Stop](img/4.png)

docs/workflow/task-workflow/index.md

@@ -23,11 +23,15 @@ The team uses a **rebase-then-merge** workflow. Each task is developed in isolat
 - Read the task carefully, including any comments or attachments.
 - Make sure you understand the requirements before starting. If anything is unclear, ask before writing any code.
 
+![Task Description](img/1.png)
+
 ## Step 2 — Start the Timer
 
 - Start your timer as soon as you begin working on the task.
 - The timer should reflect actual working time on the task, so start it now and not before you have read and understood it.
 
+![Timer Start](img/2.png)
+
 ## Step 3 — Update Your Local `dev` Branch
 
 Before creating your feature branch, make sure your local `dev` is up to date:

i18n/fr/docusaurus-plugin-content-docs/current/workflow/task-workflow/02-merging-and-completing.md

@@ -57,6 +57,10 @@ et utilisation de la bibliothèque aspose-cells pour la génération du fichier.
 Testé avec des jeux de données allant jusqu'à 10 000 lignes.
 ```
 
+![Task Comment](img/3.png)
+
 ## Étape 14 — Arrêter le Chronomètre
 
 Arrêtez votre chronomètre. La tâche est terminée.
+
+![Timer Stop](img/4.png)

i18n/fr/docusaurus-plugin-content-docs/current/workflow/task-workflow/index.md

@@ -23,11 +23,15 @@ L'équipe utilise un workflow de type **rebase-then-merge** (rebasage puis fusio
 - Lisez attentivement la tâche, y compris les commentaires ou les pièces jointes.
 - Assurez-vous de bien comprendre les exigences avant de commencer. Si quelque chose n'est pas clair, demandez avant d'écrire du code.
 
+![Task Description](img/1.png)
+
 ## Étape 2 — Lancer le Chronomètre
 
 - Lancez votre chronomètre dès que vous commencez à travailler sur la tâche.
 - Le chronomètre doit refléter le temps de travail réel sur la tâche, alors lancez-le maintenant et non avant d'avoir lu et compris le ticket.
 
+![Timer Start](img/2.png)
+
 ## Étape 3 — Mettre à Jour votre Branche `dev` Locale
 
 Avant de créer votre branche de fonctionnalité, assurez-vous que votre branche `dev` locale est à jour :