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

@@ -1,306 +0,0 @@
-# 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

@@ -1,8 +0,0 @@
-{
-  "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,10 +57,6 @@ 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,15 +23,11 @@ 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,10 +57,6 @@ 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,15 +23,11 @@ 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 :