Sharrit/docs/RELEASE_BUILD.md

ShaarIt - Instructions de Build Release

Prérequis

• Android Studio ou Gradle CLI
• Java JDK 8+ installé

Création du Keystore (à faire une seule fois)

Via ligne de commande:

keytool -genkey -v -keystore shaarit-release.keystore -alias shaarit -keyalg RSA -keysize 2048 -validity 10000

Informations à fournir:

• Mot de passe keystore: (notez-le précieusement!)
• Nom et prénom: Votre nom
• Unité organisationnelle: (ex: Development)
• Organisation: Votre entreprise
• Ville: Votre ville
• Province/État: Votre province
• Code pays: CA (pour Canada)

Configuration de la signature

Option 1: Variables d'environnement (recommandé)

Créez un fichier local.properties (ne pas commiter!) avec:

SHAARIT_KEYSTORE_PATH=../shaarit-release.keystore
SHAARIT_KEYSTORE_PASSWORD=votre_mot_de_passe
SHAARIT_KEY_ALIAS=shaarit
SHAARIT_KEY_PASSWORD=votre_mot_de_passe_cle

Option 2: Fichier séparé

Créez keystore.properties (ne pas commiter!) avec:

storeFile=../shaarit-release.keystore
storePassword=votre_mot_de_passe
keyAlias=shaarit
keyPassword=votre_mot_de_passe_cle

Build Release

Méthode 1: Script PowerShell build.ps1 (recommandé)

Le script build.ps1 automatise le versioning et le build. Il gère automatiquement l'incrémentation de la version dans version.properties et lance le build approprié.

Syntaxe de base:

.\build.ps1 [-Type Debug|Release] [-Bump Major|Minor|Patch|None] [-OutputFormat APK|AAB] [-Clean]

Paramètres:

• -Type: Type de build (Debug par défaut, Release pour la production)
• -Bump: Type d'incrémentation de version (Patch par défaut)
• -OutputFormat: Format de sortie (APK par défaut, AAB pour Google Play Store)
• -Clean: Effectue un clean avant le build (optionnel)

Exemples d'utilisation:

1. Build Debug avec incrément de Patch (le plus courant):

   .\build.ps1
   # Résultat: version 1.0.1 → 1.0.2, build Debug APK
   

2. Build Release APK avec incrément de Minor (nouvelle fonctionnalité):

   .\build.ps1 -Type Release -Bump Minor
   # Résultat: version 1.0.2 → 1.1.0, build Release APK
   

3. Build Release AAB pour Google Play Store:

   .\build.ps1 -Type Release -Bump Minor -OutputFormat AAB
   # Résultat: version 1.0.2 → 1.1.0, build Release AAB
   

4. Build Release avec incrément de Major (version majeure):

   .\build.ps1 -Type Release -Bump Major -Clean
   # Résultat: version 1.1.0 → 2.0.0, build Release APK avec clean
   

5. Build Debug sans changer la version (pour tests rapides):

   .\build.ps1 -Type Debug -Bump None
   # Résultat: version inchangée, recompilation Debug APK
   

6. Build Release AAB pour hotfix (patch uniquement):

   .\build.ps1 -Type Release -Bump Patch -OutputFormat AAB
   # Résultat: version 1.0.2 → 1.0.3, build Release AAB
   

7. Build complet avec clean et version majeure:

   .\build.ps1 -Type Release -Bump Major -OutputFormat AAB -Clean
   # Résultat: version 1.1.0 → 2.0.0, build Release AAB avec clean complet
   

Fichiers générés (avec renommage automatique):

• Debug APK: app/build/outputs/apk/debug/ShaarIt-debug-x.x.x.apk
• Release APK: app/build/outputs/apk/release/ShaarIt-x.x.x.apk
• Release AAB: app/build/outputs/bundle/release/ShaarIt-x.x.x.aab (pour Google Play Store)

Format de nommage:

• Debug: ShaarIt-debug-{VERSION_NAME}.apk
• Release APK: ShaarIt-{VERSION_NAME}.apk
• Release AAB: ShaarIt-{VERSION_NAME}.aab

Note: Le format AAB n'est disponible que pour les builds Release. Les builds Debug génèrent toujours des APK. Les fichiers sont automatiquement renommés après chaque build réussi.

Méthode 2: Gradle manuel (si nécessaire)

Si vous préférez utiliser Gradle directement:

Debug build (pour tester):

./gradlew assembleDebug

L'APK sera dans: app/build/outputs/apk/debug/app-debug.apk

Release build (pour production):

./gradlew assembleRelease

L'APK sera dans: app/build/outputs/apk/release/app-release.apk

Bundle AAB (pour Google Play Store):

./gradlew bundleRelease

Le bundle sera dans: app/build/outputs/bundle/release/app-release.aab

⚠️ Note: Avec la méthode manuelle:

• Vous devez gérer le versioning manuellement dans version.properties
• Les fichiers conservent leurs noms par défaut (app-debug.apk, app-release.apk, app-release.aab)
• Aucun renommage automatique n'est effectué

Vérification du build

Vérifiez l'APK signé:

jarsigner -verify -verbose -certs app/build/outputs/apk/release/app-release.apk

Checklist avant publication

Si vous utilisez build.ps1 (recommandé):

• Version automatiquement incrémentée par le script
• Type de bump approprié choisi (Major/Minor/Patch)
• Tests passés
• ProGuard configuré et testé
• APK/AAB généré et vérifié
• Captures d'écran prêtes pour le store
• Description de l'app rédigée
• Icône et assets graphiques finalisés

Si vous utilisez Gradle manuel:

• Version code incrémenté dans version.properties
• Version name mise à jour dans version.properties
• Tests passés
• ProGuard configuré et testé
• APK signé et vérifié
• Captures d'écran prêtes pour le store
• Description de l'app rédigée
• Icône et assets graphiques finalisés

Workflow recommandé avec build.ps1:

1. Développement et tests avec .\build.ps1 -Bump None
2. Quand prêt pour release:
   • Hotfix: .\build.ps1 -Type Release -Bump Patch
   • Nouvelle fonctionnalité: .\build.ps1 -Type Release -Bump Minor
   • Version majeure: .\build.ps1 -Type Release -Bump Major
3. Vérifier l'AAB généré dans app/build/outputs/bundle/release/
4. Soumettre sur Google Play Console

Système de Versioning Automatique

Le projet utilise un système de versioning sémantique (SemVer) automatisé:

Fichiers impliqués:

• version.properties: Source unique de vérité pour la version

  VERSION_NAME=1.0.1
  VERSION_CODE=3
  

• build.ps1: Script qui incrémente la version et lance le build
• app/build.gradle.kts: Lit version.properties pour configurer BuildConfig
• Settings → À propos: Affiche dynamiquement BuildConfig.VERSION_NAME et BuildConfig.VERSION_CODE

Règles de versioning:

• Major (X.0.0): Changements cassants, refactoring majeur
• Minor (X.Y.0): Nouvelles fonctionnalités, rétrocompatibles
• Patch (X.Y.Z): Corrections de bugs, petites améliorations
• VERSION_CODE: Toujours incrémenté pour Google Play Store (doit être unique)

Exemples de progression:

1.0.0 (code: 1) → Patch → 1.0.1 (code: 2)
1.0.1 (code: 2) → Minor → 1.1.0 (code: 3)
1.1.0 (code: 3) → Major → 2.0.0 (code: 4)

Notes de sécurité

⚠️ IMPORTANT: Ne jamais commiter ces fichiers:

• *.keystore
• *.jks
• keystore.properties
• local.properties (sauf template)

Ajoutez au .gitignore:

*.keystore
*.jks
keystore.properties