04‐workflow - xzima/gradle-semantic-release-example GitHub Wiki

Как должен выглядеть сценарии работы разработчика с repo

WorkFlow - это поэтапный процесс, которому разработчик должен следовать для внесения изменений в код, работы с задачами, организации release и deploy приложения.

Обновление зависимости

Если renovate обнаружил новую версию зависимости, то для того, чтобы выполнить обновление зависимости, нужно:

поставить галочку напротив нужной зависимости в Dependency Dashboard, в результате чего будет созданы:
- ветка в формате renovate/{deps-update-name} из ветки develop. Далее r1
- PR r1 -> develop
провести review PR
выполнить merge PR посредством rebase если в ветке содержится 1 commit, иначе посредством squash

Добавление новой функциональности

создать задачу из шаблона Feature Request
- добавить заголовок(обязательно на английском, желательно согласно соглашению и не более трех слов)
- добавить описание, согласно шаблону
- добавить теги
взять задачу в работу, посредством указания Assignees, в результате чего будут созданы:
- ветка в формате feature/i{issue-number}, из ветки develop. Далее f1
- Draft PR f1 -> develop
реализовать необходимые изменения в ветке f1
после того как все изменения внесены, преобразовать Draft PR в PR, назначить reviewers при необходимости
дождаться выполнения всех необходимых проверок и review для PR
сделать squash
- если после merge, должно произойти закрытие задачи, то commit должен содержать: Closes: #{issueId}
- commit должен соответствовать соглашению
- заголовок должен соответствовать заголовку задачи и включать номер PR(стандартное поведение для github)
- в результате:
  - PR закрывается
  - ветка удаляется
  - если указан в commit Closes: #{issueId}, то происходит автоматическое закрытие задачи
  - изменения попадают в develop
  - после выкатки release candidate, задача помечается как released on @rc
  - после выкатки release, задача помечается как released

Добавление нового исправления

создать задачу из шаблона Bug Report
- добавить заголовок(обязательно на английском, желательно согласно соглашению и не более трех слов)
- добавить описание, согласно шаблону
- добавить теги
  - bug - для исправления нового релиза
  - hotfix - для исправления старого релиза
взять задачу в работу, посредством указания Assignees, в результате чего будут созданы:
- ветка в формате bug/i{issue-number}, из ветки develop или master в зависимости от тега. Далее:
  - source-ветка будет называться - b1
  - target-ветка будет называться - target
- Draft PR b1 -> target
реализовать необходимые изменения в ветке b1
после того как все изменения внесены, преобразовать Draft PR в PR, назначить reviewers при необходимости
дождаться выполнения всех необходимых проверок и review для PR
сделать squash
- если после merge, должно произойти закрытие задачи, то commit должен содержать: Closes: #{issueId}
- commit должен соответствовать соглашению
- заголовок должен соответствовать заголовку задачи и включать номер PR(стандартное поведение для github)
- в результате:
  - PR закрывается
  - ветка удаляется
  - если указан в commit Closes: #{issueId}, то происходит автоматическое закрытие задачи
  - изменения попадают в target
  - после выкатки release candidate, задача помечается как released on @rc
  - после выкатки release, задача помечается как released

Создание кандитата релиза

создать ветку rc из develop, при этом будет создан PR rc -> master(gitflow)
выполнить все необходимые манипуляции, необходимые перед релизом
вызвать workflow release с указанием ветки rc, в результате чего будут созданы:
- создан git tag
- создан release candidate
после создания release candidate будет запущена сборка артефакта
- сборка артефакта требует согласования, так что для продолжения потребуется approve, после чего сборка будет продолжена
- если сборка артефакта не нужно, то можно выполнить reject

Создание стабильного релиза

должна существовать ветка rc и PR rc -> master(gitflow)
выполнить merge PR, посредством merge(no-ff), что приведет к созданию PR master -> develop(gitflow), для обратной синхронизации
вызвать workflow release с указанием ветки master, в результате чего будут созданы:
- создан git tag
- создан release
после создания release будет запущена сборка артефакта
- сборка артефакта требует согласования, так что для продолжения потребуется approve, после чего сборка будет продолжена
- если сборка артефакта не нужно, то можно выполнить reject
после завершения выкатки релиза следует выполнить обратную синхронизацию, выполнив merge PR master -> develop(gitflow), посредством merge(no-ff)

Порядок работы с временными ветками

Создание feature branch

Когда вы начинаете работу над новой функцией, создавайте ветку из develop.

git checkout -b feature/issue-{ID}-{short_describe} develop

Слияние готовой функции в develop

Чтобы объединить feature branch с develop вы должны запушить свою локальную ветку и создать PR в develop. Это делается для того, чтобы пользователь мог управлять CI и выполнять все проверки автоматически перед слиянием.

git push -u origin feature/issue-{ID}-{short_describe}

Когда PR создан должен запуститься CI. В большинстве случаев он будет иметь следующие стадии lint test build.

Кнопка слияния должна быть отключена до тех пор, пока не пройдут все проверки. (Необязательно) Кнопка слияния также может быть отключена, пока PR не получит два одобрения, или это может быть просто соглашение в команде.

Когда в ветке разработки уже есть новые функции и требуется исправление в production окружении, тогда:

создать hotfix branch из master
создать commit исправления с сообщением fix: what was fixed
создать PR в master

Pull Request

Это делается для того, чтобы пользователь мог управлять CI и выполнять все проверки автоматически перед слиянием.

Когда PR создан должен запуститься CI. В большинстве случаев он будет иметь следующие стадии lint test build.

Источники

conventional commits