app branching strategy
1.0.0
Понять почему?
master -> Последний и величайший тестированный Dev CodeНикаких других постоянных сундуков.
feature/<feature_name>fix/<bug_title>release/v-<version.major>.<version.minor>auto-backmerge/<pr_number> используется для поднятия PRS для мастера для каждого изменения, навязываемого для освобождения ветвей YYMM.DD.NN
NN ➡ номер патча
Пример: 2301.25.00 , 2302.01.04
master? on-merge-master.yml на каждом слиянии, чтобы освоить, мы обновляем полную версию. Основные, второстепенные версии будут изменены, если существующая версия имеет предыдущую дату, в противном случае только номер патча будет увеличен.
Пример :
Существующая версия: 2301.25.02
Если новый коммит подталкивается 25 января 2023 года, версия становится 2301.25.03
Если новый коммит подтолкнут 26 января 2023 года, версия становится 2301.26.00
release/**? On-Merge-Release.yml
release* На каждом коммите мы обновляем номер патча на release* филиалы
release/** на master ? on-merge-release.yml Каждый толчок для release* запустит соответствующий пиар, чтобы master через auto-backmerge/<pr_number> .
PR будет автоматически объединен, если нет конфликтов
? PRIPERA-a-release.yml Создайте филиал выпуска от последнего мастера, с правильной версией в названии филиала.
Действия
? Create-Gaged-release.yml тег
Действия
%% {init: {'gitgraph': {'mainbranchname': 'Master', 'showcommitlabel': true}}} %%
Gitgraph
ID COMMITE: "? 2301.25.00"
Исправление фиксации/рамки
Идентификатор коммита: «Исправить логику»
Идентификатор коммита: "Исправить пользовательский интерфейс"
Оформление Мастера
филиал/дм
Идентификатор коммита: "Добавить DB"
Идентификатор коммита: "Добавить сокет"
Оформление Мастера
Merge Fix/Frames-BUG ID: "PR: Frames Bug"
Идентификатор коммита: "? 2301.25.01"
Функция оформления заказа/DM
Merge Master ID: «Потяните мастер»
Идентификатор коммита: "добавить пользовательский интерфейс"
Оформление Мастера
Функция Merge/DM ID: "PR: функция DM"
Идентификатор коммита: "? 2301.25.02"
master (действияmaster ветвь и перейти к шагу 2 %% {init: {'gitgraph': {'mainbranchname': 'Master', 'showcommitlabel': true}}} %%
Gitgraph
Идентификатор коммита: "? 2301.25.02"
Выпуск филиала/V-2301.25
Оформление Мастера
Идентификатор коммита: «PR: новая функция» Тип: выделить
Идентификатор коммита: "? 2301.26.00"
Выпуск заказа/V-2301.25
фиксированное исправление/релиз-бук
Идентификатор коммита: "Исправить ошибку"
Выпуск заказа/V-2301.25
Исправление слияния/идентификатор релиза: "Pr: выпуск ошибки"
Выпуск заказа/V-2301.25
Branch Auto-Backmerge/Release-Bug
Merge Master ID: «Обновление филиала»
Выпуск заказа/V-2301.25
Идентификатор коммита: "? 2301.25.03" Тэг: "V-2301.25.03"
Оформление Мастера
Merge Auto-Backmerge/Lelepred-Bug Id: "Backmerge"
Оформление Мастера
Идентификатор коммита: "? 2301.26.01"
Действия
Когда мы есть? На всех тестах сделайте вышеупомянутое, чтобы пометить последний коммит от филиала релиза и создать релиз GitHub с автоматическими заметками. И загрузить артефакты в магазины приложений
Исправление проблемы в текущей сборке производства ( v-2301.16.01 )
v-2301.16.01 > Branch: release/v-2301.16 )Остальное такое же, как и обычный поток высвобождения
%% {init: {'gitgraph': {'mainbranchname': 'release/v-2301.16', 'showcommitlabel': true}}} %%
Gitgraph
Идентификатор коммита: "2301.16.04" Тэг: "V-2301.16.04"
ОТДЕЛИТЕЛЬНОЕ ПОСЛЕДНИЕ/СВОБ
Идентификатор коммита: "Исправить сбой"
Оформление выпуска/V-2301.16
Merge HotFix/ID сбоя: "PR Crash"
Идентификатор коммита: "? 2301.16.05"
ОТЧЕТАЕТ HOTFIX/BUG
Идентификатор коммита: "Исправить ошибку"
Оформление выпуска/V-2301.16
Merge HotFix/ID BUG: "PR BUG"
Идентификатор коммита: "? 2301.16.06" TAG: "V-2301.16.06"
Линейная история желательна по разным причинам. Все снова сводится к простоте.
Только разрешение слияния сквоша с помощью одного туловища - самый простой способ достижения линейной истории. Никто не должен думать, правильная вещь происходит автоматически.
Кроме того, в целом у людей есть лучшая дисциплина в отношении названий PR, чем сообщений о совершении, поэтому ваши изменения изменений также выглядят хорошо.
В отличие от приложений сервера, процессы выпуска мобильных приложений, как правило, являются длинными. Обычно требуется 2 или более недель, если мы включим постепенное развертывание до 10%> 20%> 50%> 100%, наблюдая за стабильностью и метриками на этом пути.
Между тем, участники не должны иметь двусмысленности, безопасно ли слияние для освоения прямо сейчас.
После того, как выпуск будет сделан и коммит помечен, у них нет никакой цели. Вот почему мы удаляем их после релиза.
Гантт
Разработка и выбросы приложения титула
DateFormat yyyy-mm-dd
Tickinterval 3day
Раздел разработчик 1
Особенность 2: A, 2022-01-13, 15d
Слияние к мастеру: Crit, Milestone, после A, 0d
Раздел Dev 2
Особенность 1: B, 2022-01-12, 2d
Слияние с мастером: веха, после b, 0d
Обновление библиотеки ⬆: L, 2022-01-16, 1d
Слияние до Мастера: Crit, Milestone, после L, 0d
Исправлена функция 1 ?: B2, после R1, 2d
Слияние для выпуска: Milestone, после B2, 0d
Обновление структуры ⬆: F, 2022-01-22, 1d
Слияние до Мастера: Crit, Milestone, после f, 0d
Секция релиза
Подготовьте релиз 2201.14: веха, после b, 0d
Функция тестирования 1: R1, после B, 4D
Функция тестирования 1: R2, после B2, 1d
Развертывание 2201.14.1 10% - 100%: R3, после R2, 7d
Подготовьте релиз 2201.31: Milestone, 2022-01-31, 0d
Слияние, чтобы Мастер? безопасен и поощряется, даже когда релиз продолжается
Это схема управления версиями на основе даты, которая также
semver , для которых версия больше, чем другая2301.16.00 > 2212.31.07 )И лучше всего избегать вопроса - когда мы выпустили эту версию? навсегда, от всех во всей команде
Даже если ответ на приведенный выше вопрос не так важен для вашей команды, это одинаково хорошо, если не лучше, чем semver . Который, большинство команд используют по умолчанию. Семантическое управление версиями ( semver ) имеет смысл для библиотек. Потребители вашей библиотеки хотят знать, когда произойдут нарушающие изменения, а когда нет. И менеджеры пакетов пользуются этим соглашением, чтобы безопасно обновлять зависимости. Пользователи мобильных приложений / магазины приложений не имеют таких ожиданий от версий приложений. Они едва заботятся.
Мои команды используют схемы версий на основе даты более года, и это здорово!
