app branching strategy
1.0.0
Comprendre le pourquoi?
master -> Code de développement plus récent et le plus grandAucun autre tronc permanent.
feature/<feature_name>fix/<bug_title>release/v-<version.major>.<version.minor>auto-backmerge/<pr_number> utilisé pour élever des PR pour maîtriser pour chaque modification poussée pour libérer les branches YYMM.DD.NN
NN ➡️ Numéro de patch
Ex: 2301.25.00 , 2302.01.04
master? On-Merge-Master.yml sur chaque fusion pour maîtriser, nous mettons à jour la version complète. Les versions majeures et mineures seront modifiées si la version existante est d'une date précédente, sinon seul le numéro de correctif sera augmenté.
Exemple :
Version existante: 2301.25.02
Si un nouvel engagement est poussé le 25 janvier 2023, la version devient 2301.25.03
Si un nouvel engagement est poussé le 26 janvier 2023, la version devient 2301.26.00
release/**? On-Merge-Release.yml
release* Sur chaque engagement, nous mettons à jour le numéro de correctif sur les succursales release*
release/** sur master ? On-Merge-Release.yml Chaque poussée pour release* déclenchera un PR correspondant pour master via une branche auto-backmerge/<pr_number> .
Le PR sera automatiquement fusionné s'il n'y a pas de conflits
? Préparez-a-Release.yml Créez une branche de version du dernier maître, avec la bonne version dans le nom de la branche.
Actes
? Créer-Tagged-Release.yml Tag Le dernier engagement dans une branche de version avec la bonne version et les notes de version
Actes
%% {init: {'gitgraph': {'mainbranchname': 'maître', 'showCommitLabel': true}}} %%
gitgraph
ID de validation: "? 2301.25.00"
Fix de branche / Frames-Bug
Commit ID: "Fix Logic"
Commit ID: "Fix UI"
maître de caisse
fonctionnalité de branche / dm
Commit ID: "Ajouter DB"
ID de validation: "Ajouter une prise"
maître de caisse
Merger Fix / Frames-Bug ID: "PR: Frames Bug"
Commit ID: "? 2301.25.01"
Fonction de paiement / DM
Merger Master ID: "Pull Master"
Commit ID: "Ajouter une interface utilisateur"
maître de caisse
Fuurez la fonctionnalité / ID DM: "PR: fonctionnalité DM"
Commit ID: "? 2301.25.02"
master (actionsmaster et passez à l'étape 2 %% {init: {'gitgraph': {'mainbranchname': 'maître', 'showCommitLabel': true}}} %%
gitgraph
Commit ID: "? 2301.25.02"
Libération de succursale / V-2301.25
maître de caisse
ID de validation: "PR: nouvelle fonctionnalité"
ID de validation: "? 2301.26.00"
Version de paiement / V-2301.25
Fix de branche / boug de libération
Commit ID: "Correction du bug"
Version de paiement / V-2301.25
Merger ID Correct / Release-Bug: "PR: Release Bug"
Version de paiement / V-2301.25
Branche Auto-Backmerge / Release-Bug
Merger Master ID: "Mettre à jour la branche"
Version de paiement / V-2301.25
ID de commit: "? 2301.25.03" Tag: "V-2301.25.03"
maître de caisse
Merge Auto-Backmerge / Release-Bug ID: "Backmerge"
maître de caisse
Commit ID: "? 2301.26.01"
Actes
Une fois que nous sommes? Sur tous les tests, faites ce qui précède pour marquer le dernier engagement de la branche de version et créez une version GitHub avec des notes de version automatisées. Et télécharger les artefacts dans les magasins d'applications
Fixer un problème dans la construction de production actuelle ( v-2301.16.01 )
v-2301.16.01 -> Branche: release/v-2301.16 )Le reste est le même que le flux de libération normal
%% {init: {'gitgraph': {'mainbranchname': 'release / v-2301.16', 'showCommitLabel': true}}} %%
gitgraph
ID de validation: "2301.16.04" Tag: "V-2301.16.04"
branche hotfix / crash
Commit ID: "Fix Crash"
Version de paiement / V-2301.16
fusionner Hotfix / Crash ID: "PR Crash"
Commit ID: "? 2301.16.05"
branche hotfix / bug
Commit ID: "Correction du bug"
Version de paiement / V-2301.16
fusion ID Hotfix / Bug: "PR Bug"
ID de validation: "? 2301.16.06" Tag: "V-2301.16.06"
L'histoire linéaire est souhaitable pour diverses raisons. Tout se résume à nouveau à la simplicité.
Permettre uniquement de la fusion de la courge avec un seul tronc est le moyen le plus simple d'atteindre l'historique linéaire. Personne n'a à penser, la bonne chose se produit automatiquement.
En général, les gens ont une meilleure discipline en ce qui concerne les titres des relations publiques que de commettre des messages, donc vos changers sont également beaux.
Contrairement aux applications de serveur, les processus de libération des applications mobiles ont tendance à être longs. Il est courant de prendre 2 semaines ou plus si nous incluons le déploiement progressif à 10%> 20%> 50%> 100% tout en observant la stabilité et les mesures en cours de route.
Pendant ce temps, les contributeurs ne devraient pas avoir une ambiguïté de savoir s'il est sûr de fusionner pour maîtriser dès maintenant.
Une fois la version effectuée et que le commit est tagué, ils n'ont pas de but. C'est pourquoi nous les supprimons après la libération.
gantt
Développement et versions des applications de titre
dateformat yyyy-mm-dd
TickInterval 3 jours
Section Dev 1
Caractéristique 2: A, 2022-01-13, 15D
Fusionner le maître: critique, jalon, après un, 0d
Section Dev 2
Caractéristique 1: B, 2022-01-12, 2D
Fusionner pour maîtriser: jalon, après b, 0d
Mise à niveau de la bibliothèque ⬆️: L, 2022-01-16, 1D
Fusionner le maître: critique, jalon, après l, 0d
Fix Feature 1 ?: B2, après R1, 2d
Fusionner pour libérer: jalon, après B2, 0D
Mise à niveau du cadre ⬆️: F, 2022-01-22, 1D
Fusionner le maître: critique, jalon, après f, 0d
Release de section
Préparer la version 2201.14: jalon, après B, 0D
Fonctionnement de test 1: R1, après B, 4D
Fonctionnement de test 1: R2, après B2, 1D
Déploiement 2201.14.1 10% - 100%: R3, après R2, 7d
Préparer la version 2201.31: Milestone, 2022-01-31, 0d
Fusion pour maîtriser? est sûr et encouragé même lorsqu'une libération est en cours
C'est un schéma de version de version basé sur des dates qui est également
semver pour lesquelles la version est supérieure à celle de l'autre2301.16.00 > 2212.31.07 )Et le meilleur de tous évite la question - quand avons-nous publié cette version? pour toujours, de quiconque dans toute l'équipe
Même si répondre à la question ci-dessus n'est pas si importante pour votre équipe, c'est tout aussi bon, sinon mieux que semver . Qui, la plupart des équipes utilisent par défaut. Le versioning sémantique ( semver ) a du sens pour les bibliothèques. Les consommateurs de votre bibliothèque veulent savoir quand il y a des changements de rupture et quand il n'y en a pas. Et les gestionnaires de packages profitent de cette convention pour améliorer en toute sécurité les dépendances. Les utilisateurs d'applications mobiles / les magasins d'applications n'ont pas de telles attentes à partir des versions d'applications. Ils se soucient à peine.
Mes équipes utilisent des schémas de verseing basés sur des dattes depuis plus d'un an et c'est génial!
