Working with tasks

TASKS.rst

Choosing a task

A developer should take top unfinished task (higher priority tasks are on top) in the backlog that is assigned to him or first unsigned task if there is not any task that is assigned to him. In latter case he/she should confirm chosen task with a team leader.

Create a branch for a task

1. Get the lastest code base from upstream:

   git fetch upstream
   

2. Create a branch in the local repository:

   git checkout upstream/<name of the upstream branch you submit changes to>
   git checkout -b <branch name>
   
   # Branches are named after tasks:
   # TASK_ID_task_summary
   # For example http://myjira.com/browse/PROJ-4
   # PROJ-4_improve_unittests
   

Closing the task

Задача считается завершенной, если она успешно прошла ревизию кода (code review) и тестирование, в результате чего была переведена в статус Done. Решение всех возникающих вопросов при выполнении задачи, в том числе привлечение других членов команды и сотрудников компании (при необходимости), эскалация проблем и делегирование, являются ответственностью и обязанностью разработчика, на которого возложено выполнение задачи.

В большинстве случаев задача должна быть сделана в одном коммите. Создание нескольких коммитов для одной задачи допустимо, но должно быть обосновано. Также несколько коммитов возможно в случае исправления дефектов после мержа первоначального pull request.

Для завершения задачи необходимо выполнить следующие действия:

1. При необходимости добавить описание новой функциональности в файл CHANGE.rst

2. При необходимости добавить описание ручной миграции в файл MIGRATE.rst

3. Добавить измененные файлы в staging area:

   git status
   git add <имя файла>
   # или добавление в интерактивном режиме
   git add -i
   

4. Сделать commit:

   git commit -m <название коммита>
   # Название первоначального коммита должно быть сформировано на основе названия задачи и
   # иметь следующий формат:
   # TASK_ID: task summary
   # Например для задачи http://jira.saprun.com/browse/PLATFORMTB-4
   # PLATFORMTB-4: Restrict order creation to users who confirmed their mobile phone
   # Последующие коммиты должны иметь формат:
   # TASK_ID: описание смысла коммита
   # Например для задачи http://jira.saprun.com/browse/PLATFORMTB-4
   # PLATFORMTB-4: Code review fixups
   

5. Забрать последнюю версию кода из upstream репозитория:

   git fetch upstream
   

6. [Рекомендовано] Сделать резервную ветку на случай неудачного ребейза:

   git branch <название ветки_before_rebase>
   

7. Если с момента создания ветки были изменения в релизную ветку (upstream/release/yy.mm.dd) выполнить rebase на релизную ветку (upstream/release/yy.mm.dd):

   # git rebase upstream/release/yy.mm.dd
   # yy.mm.dd заменить на год, месяц, день соответствующие релизу, например:
   # git rebase upstream/release/15.08.11
   

8. Проверить следующее:

1. Корректность зависимостей миграций
2. Заполнение CHANGE.rst (добавляем только важную для конечных пользователей информацию)
3. Заполнение MIGRATE.rst (при необходимости)

1. Выполнить push в origin:

   git push origin <название ветки>
   # если был rebase, то использовать force
   git push origin <название ветки> -f
   

2. Сделать pull request своей ветки в релизную ветку (upstream/release/yy.mm.dd) в bitbucket

3. Добавить в задачу коментарий следующего вида и назначить на релиз менеджера (Dmitry Mugtasimov):

   Please, merge:
   <ссылка на pull request>
   

4. Добавить в задачу коментарий следующего вида:

   QA notes:
   Описание минимальных проверок, которые ожидается от QA, либо описание того, что и как было