Skip to content

Latest commit

 

History

History
97 lines (84 loc) · 9.27 KB

workflow.md

File metadata and controls

97 lines (84 loc) · 9.27 KB
Raw

Github and Team workflow for JuJa SQLcmd

Процесс работы над задачами, проведение code review, организация работы в команде, работа с ветками

1. Процесс создания задачи

  1. Задачи создаются в колонке ToDo в проекте для каждого участника.
  2. Описание задачи должно быть максимально полным и понятным для понимания.
  3. Если задача является продолжением другой, то в описании к ней должна быть ссылка на предыдущую.

2. Процесс начала работы над задачей

  1. Выбраем задачу в колонке ToDo. Поиск новых задач необходимо начинать сверху списка.
  2. Перенести задачу в колонку In progress.
  3. Перед созданием ветки для задачи необходимо залить последнюю версию upstream репозитория. Ссылка, как сделать.
  4. В своем репозитории необходимо создать ветку для задачи. Формат названия ветки "task number"-"feature name". Пример: 123-important-feature.
  5. Приступить к работе над задачей.

3. В процесс работы над задачей

  1. Во время работы необходимо придерживаться Java Code Convention.

  2. Сообщения в коммитах должны быть в формате #123: commit message.

  3. На задачу должны быть обязательно написаны тесты:

    • 100% покрытие unit тестами.
    • Все критические моменты покрываем integration тестами.
    • Все эндпоинты покрываем acceptance тестами и по возможности integration тестами.

  4. После того, как работа закончена, необходимо залить ветку с задачей в свой fork-репозиторий на github и сделать pull request в upstream репозиторий в ветку, в которой ведется разработка проекта.

    • Имя pull request должно быть в формате #123 important feature.
    • Pull request должен быть связан с задачей, это делается добавлением строки connect to #123 в поле с описанием.
    • После создания pull request, Travis CI автоматически запустит сборку проекта. Необходимо проверить, чтобы она прошла удачно. Если сборка не пройдет, необходимо изучить log travis и устранить ошибки. Увидеть, как прошла сборка, можно в github, если открыть pull request. Лог сборки можно посмотреть, кликнув на Details.

  5. После этого необходимо перенести задачу в колонку Verify.

  6. Для того, чтобы задача была добавлена в ветку разработки команды, необходимо наличие 4 approve in code review (это значение может меняться в зависимости от проекта и договоренностей в команде).

4. Если не удается решить задачу

  1. Попросить коллег про помощь в общем чате команды.
  2. Если для решения данной задачи нужно решение другой задачи, необходимо в исходном коде оставить комментарий //TODO или @todo c описанием того, что надо сделать и ссылкой на задачу, которая нужна. Если такой задачи нет, ее необходимо добавить в ToDo проекта.

5. Если задача заблокирована другой задачей

(в процессе работы над задачей необходим функционал, которого еще нет и нет возможности это легко обойти)

  1. Добавить комментарий к своей задаче blocked with #123. Если эту задачу уже кто-то делает, необходимо связаться с ним и договориться о дальнейших шагах.
  2. Если решение блокирующей задачи затягивается, текущую необходимо вернуть в колонку ToDo и вернуться к пункту 2.

6. Проведение review

  1. Делать code review должен каждый участник команды.
  2. К code review допускаются только задачи, для которых Travis успешно выполнил прогон тестов.
  3. Ревьювер должен придерживаться следующих правил:
    • В начале ревью необходимо начать этот процесс на github. Более подробно в документации.
    • Если замечаний нет, то завершить процесс review с отметкой Approved.
    • Если есть комментарии, оставить их, используя Comment.
    • Если есть существенные замечания, которые должны быть устранены до merge, необходимо оставить Request changes.
    • Статусы Comment и Request changes - не разрешают сделать merge pull request, пока не будет реакции владельца pull request и не будет выставлен статус Approved.
  4. После того, как условие по количеству ревью выполнено, владелец pull request должен уведомить team lead или человека у которого есть права на merge, провести финальное ревью и сделать merge в ветку разработки.
  5. После успешного принятия изменений задача передвигается в колонку Done и ответственный за нее разработчик переходит к пункту 2.
  6. Если в процессе ревью необходимы существенные доработки, задача возвращается в колонку In progress и разработчик переходит к пункту 3. Закрывать при этом pull request не нужно. Все изменения, которые будут попадать в ветку, с которой он был сделан, автоматически будут подтягиваться в pull request.

7. Разное

  1. Если условие задачи непонятно, необходимо запросить дополнительные сведения.
  2. Если задача слишком объемная, необходимо обсудить с team lead пути, как разбить ее на несколько, и сделать эту операцию, используя пункт 1. После этого необходимо выбрать новую задачу, используя пункт 2.
  3. Добавлять изменения без кодревью в основную ветку проекта запрещается.

Линки на tutorial, для самых частых операции при работе с github

Following the GitHub flow
  1. Create a branch from the repository.
  2. Create, edit, rename, move, or delete files.
  3. Send a pull request from your branch with your proposed changes to kick off a discussion.
  4. Make changes on your branch as needed. Your pull request will update automatically.
  5. Merge the pull request once the branch is ready to be merged.
  6. Tidy up your branches using the delete button in the pull request or on the branches page.