app branching strategy
1.0.0
Das Warum verstehen?
master -> neuester und der größte Code für Entwickler getestetKeine anderen ständigen Stämme.
feature/<feature_name>fix/<bug_title>release/v-<version.major>.<version.minor>auto-backmerge/<pr_number> Wird verwendet, um PRs für jede Änderung zu meistern YYMM.DD.NN
NN ➡️ Patch -Nummer
Ex: 2301.25.00 , 2302.01.04
master? On-Merge-Master.yml Bei jeder Zusammenführung von Master Up aktualisieren wir die Vollversion. Major, kleinere Versionen werden geändert, wenn die vorhandene Version eines früheren Datums ist, andernfalls wird nur die Patch -Nummer erhöht.
Beispiel :
Bestehende Version: 2301.25.02
Wenn am 25. Januar 2023 ein neues Komitee vorangetrieben wird, wird die Version 2301.25.03
Wenn am 26. Januar 2023 ein neues Komitee vorangetrieben wird, wird die Version 2301.26.00
release/**? On-Merge-Release.yml
release* aktualisieren* In jedem Commit aktualisieren wir die Patch -Nummer in release* -Diails
release/** auf master ? On-Merge-Release.yml Jeder Drücken zur release* löst einen entsprechenden PR über einen auto-backmerge/<pr_number> -Ast master .
Die PR wird automatisch zusammengeführt, wenn keine Konflikte vorliegen
? prepe-a-release.yml erstellen Sie einen Release-Zweig vom neuesten Master mit der richtigen Version im Zweignamen.
Aktionen
? create-markged-release.yml Tag das neueste Komitee in einer Release-Filiale mit dem richtigen Versions-Tag- und Release-Notizen
Aktionen
%% {init: {'gitgraph': {'mainbranchname': 'Master', 'showCommitlabel': true}}} %%
Gitgraph
Commit ID: "? 2301.25.00"
Zweig-Fix/Rahmenbug
Commit ID: "Logik beheben"
Commit ID: "Fix UI" “
Checkout Master
Zweig -Feature/DM
Commit ID: "DB hinzufügen"
Commit ID: "Socket hinzufügen"
Checkout Master
Merge Fix/Frames-Bug ID: "PR: Frames Bug" "
Commit ID: "? 2301.25.01"
Checkout -Funktion/DM
Merge Master ID: "Pull Master"
Commit ID: "UI hinzufügen"
Checkout Master
Merge -Funktion/DM ID: "PR: Feature DM"
Commit ID: "? 2301.25.02"
master (Aktionen abmaster Branch und gehen Sie zu Schritt 2 %% {init: {'gitgraph': {'mainbranchname': 'Master', 'showCommitlabel': true}}} %%
Gitgraph
Commit ID: "? 2301.25.02"
Branch Release/V-2301.25
Checkout Master
Commit ID: "PR: Neue Funktion" Typ: Highlight
Commit ID: "? 2301.26.00"
Checkout Release/V-2301.25
Branch Fix/Release-Bug
Commit ID: "Fehler beheben"
Checkout Release/V-2301.25
Merge Fix/Release-Bug ID: "PR: Release-Fehler"
Checkout Release/V-2301.25
Branch Auto-Backmerge/Release-Bug
Merge Master ID: "Filiale aktualisieren"
Checkout Release/V-2301.25
Commit ID: "? 2301.25.03" Tag: "V-2301.25.03"
Checkout Master
Merge Auto-Backmerge/Release-Bug-ID: "Backmerge"
Checkout Master
Commit ID: "? 2301.26.01"
Aktionen
Sobald wir sind? Führen Sie bei allen Tests das oben genannte aus, um das neueste Commit aus der Release -Zweigstelle zu markieren und eine GitHub -Version mit automatisierten Versionshinweise zu erstellen. Und laden Sie die Artefakte in die App Stores hoch
Behebung eines Problems im aktuellen Produktionsbau ( v-2301.16.01 )
v-2301.16.01 > Branch: release/v-2301.16 )Der Rest ist der gleiche wie der normale Freisetzungsfluss
%% {init: {'gitgraph': {'mainbranchname': 'release/v-2301.16', 'showCommitLabel': true}}} %%
Gitgraph
Commit ID: "2301.16.04" Tag: "V-2301.16.04"
Branch Hotfix/Crash
Commit ID: "Crash beheben"
Checkout Release/V-2301.16
Merge Hotfix/Crash ID: "PR -Crash" zusammenführen
Commit ID: "? 2301.16.05"
Branch Hotfix/Fehler
Commit ID: "Fehler beheben"
Checkout Release/V-2301.16
Merge Hotfix/Fehler -ID: "PR -Fehler" zusammenführen
Commit ID: "? 2301.16.06" Tag: "V-2301.16.06"
Die lineare Geschichte ist aus verschiedenen Gründen wünschenswert. Alle sind wieder auf den Einfachheit herab.
Das Zusammenführen von Squashs mit einem einzigen Stamm ist der einfachste Weg, um eine lineare Geschichte zu erreichen. Niemand muss denken, das Richtige passiert automatisch.
Auch im Allgemeinen haben die Menschen eine bessere Disziplin in Bezug auf PR-Titel als Begehen von Nachrichten, sodass auch Ihre Änderungslogs gut aussehen.
Im Gegensatz zu Server -Apps sind mobile App -Release -Prozesse in der Regel lang. Es ist üblich, 2 oder mehr Wochen zu dauern, wenn wir die allmähliche Einführung von 10%> 20%> 50%> 100% aufnehmen, während wir Stabilität und Metriken auf dem Weg beobachten.
In der Zwischenzeit sollten die Mitwirkenden nicht mehrdeutig haben, ob es sicher ist, sich für den Meister zu verschmelzen.
Sobald die Veröffentlichung erfolgt und das Commit markiert ist, haben sie keinen Zweck. Deshalb löschen wir sie nach der Veröffentlichung.
Gantt
Entwicklung und Veröffentlichung der Titel -App -App
DateFormat yjyy-mm-dd
Tickinterval 3 Tage
Abschnitt Devel 1
Feature 2: A, 2022-01-13, 15d
Zusammenführen mit Master: Crit, Milestone, nach a, 0d
Abschnitt Devel 2
Feature 1: B, 2022-01-12, 2d
Zusammenführen mit Master: Meilenstein nach B, 0d
Bibliotheks-Upgrade ⬆️: L, 2022-01-16, 1D
Führen Sie mit Master zusammen: kritisch, milestone, nach l, 0d
Fix Feature 1 ?: B2, nach R1, 2d
Führen Sie die Veröffentlichung zusammen: Meilenstein nach B2, 0d
Framework-Upgrade ⬆️: F, 2022-01-22, 1d
Führen Sie mit Master zusammen: kritisch, meilenstein, nach f, 0d
Abschnittsfreigabe
Erstellen Sie Release 2201.14: Meilenstein nach B, 0d
Testmerkmal 1: R1, nach B, 4d
Testmerkmal 1: R2, nach B2, 1d
Rollout 2201.14.1 10% - 100%: R3, nach R2, 7d
Erstellen Sie Release 2201.31: Meilenstein, 2022-01-31, 0d
Verschmelzung zum Meister? ist sicher und ermutigt, auch wenn eine Freilassung andauert
Es ist ein datebasiertes Versionungsschema, das auch ist
semver -Vergleiche, für die die Version größer ist als die anderen2301.16.00 > 2212.31.07 )Und das Beste von allen vermeidet die Frage - wann haben wir diese Version veröffentlicht? für immer von irgendjemandem im gesamten Team
Auch wenn die Beantwortung der obigen Frage für Ihr Team nicht so wichtig ist, ist es ebenso gut, wenn nicht sogar besser als semver . Was, was die meisten Teams standardmäßig verwenden. Semantic Versioning ( semver ) ist für Bibliotheken sinnvoll. Verbraucher Ihrer Bibliothek möchten wissen, wann sich Veränderungen vorstellen und wann nicht. Und Paketmanager nutzen diese Konvention, um Abhängigkeiten sicher zu aktualisieren. Mobile App -Benutzer / App -Stores haben keine derartigen Erwartungen an App -Versionen. Sie kümmern sich kaum.
Meine Teams verwenden seit mehr als einem Jahr date -basierte Versionungsschemata und es ist großartig!
