Development instruction

Инструкция по ведению разработки в нашем проекте

В этой инструкции идет речь о разработке непосредственно кода, не об аналитике или построении архитектуры. Но, с известными допущениями, все сказанное ниже применимо и к этим областям.

---

Ремарки

Устройство задач

Если Вы не ознакомились с устройством нашей системы labels для issues, крайне рекомендуется это сделать.

Начало работы

Написание кода возможно только на основании задачи, отмеченной label-ом task или bug . В случае, если в процессе написания кода/тестирования Вы поняли, что необходимо что-то доработать в части кода, не относящейся непосредственно к тому, что Вы пишете, Вам следует зайти на страницу нашего репозитория и создаете issue.

Перед непосредственной разработкой убедитесь, что Вы потратили достаточно времени на планирование и анализ архитектуры Вашего будущего решения. В противном случае не поскупитесь выделить время на проектирование, потому что разработка без анализа приводит чае всего к плачевным последствиям. Было бы хорошо, если Вы обсудите с другими участниками Вашу архитектуру или способ решения issue.

Ситуация, когда разработчик начинает править что-то в части кода, не относящейся к той задаче, над которой он работает, нежелательна.

ВНИМАНИЕ! Разработчик создаёт PR после выполнения первой task из feature. Сразу после этого тестировщик подключается к проверке решения.

Ситуация, когда разработчик начинает работать над решением какой-то задачи, имеющей issue, не уведомив остальных об этом путем перемещения карточки задачи в InProgress на доске проекта в разделе Projects, недопустима.

---

Инструкция

1. Создание issue. Если Вы хотите начать работать над задачей, отсутствующей в issues, то сперва Вам необходимо создать issue. Затем — подумать, а так ли необходимо решать Вашу задачу до тех задач, что были запланированы.

2. Выбор задач(и). Задачи для разработки выбираются среди открытых issue с метками task, bag. Рекомендуется выбирать задачи, прикрепленные к ближайшему по дате milestone. Желательно выбирать задачи, прикрепленные к одному проекту. Распределение основных и самых важных задач проходит на командных встречах. Дополнительные задачи участники могут брать по своему желанию.

3. Перемещение задач(и) в InProgress. Необходимо найти нужное issue и написать в комментарий "task in progress". Этим действием Вы уведомите остальных членов команды, что Вы взяли в разработку эти задачи и они автоматически переместятся в колонку InProgress.

4. Создание ветки. git checkout -b branch_name У себя в локальном репозитории Вам необходимо создать ветку, в которой Вы будете вносить изменения. Все изменения в рамках решения Вашей задачи должны быть только в этой ветке. Если у Вас есть незакрытый pull request с изменениями по предыдущей задаче, то Вам все равно необходимо создавать ветку на базе основной ветки. Если Вам необходимо прервать работу над задачей, чтобы решить другую задачу, Вы должны сохранить изменения в Вашей ветке (с помощью git commit или git stash) и перейти в другую ветку. Политика коммитов в рамках решения задачи в отдельной ветке не ограничивается, однако рекомендуется делать коммиты для небольших законченных участков кода, для более удобной работы с изменениями. Ветки стоит именовать в связи с тем, что Вы собираетесь делать. То есть если решаете task_Z, прикреплённую к feature_Y и/или idea_X, то название ветки должно совпадать с названием feature — feature_Y. Иногда, если задач слишком много можно выделять ветки и для отдельных задач, но такие ситуации обычно обговариваются отдельно.

5. Отправка изменений. git push --set-upstream origin branch_name После того, как Вы поняли, что Ваша задача решена корректно, его необходимо отправить в наш репозиторий. Для этого Вам необходимо выполнить push Вашей ветки в наш командный репозиторий.

6. Pull Request. Чтобы добавить Ваши изменения к основному коду, необходимо запросить pull request. Это делается следующим образом:

   • Откройте страницу Вашей ветки на github;

   • Нажмите Compare & Pull request либо New pull requst;

   • Добавьте описание к Вашему pull request, указав с помощью цитирования по знаку # те issues, которые Вы решаете этим pull request-ом;

   • Запросите review от участников команды, которые работают в области, к которой относится Ваша задача;

   • Добавьте на Ваш pull request метки, соответствующие Вашей задаче;

   • Прикрепите Ваш pull request к тому проекту, к которому относятся Ваши issues;

   • Прикрепите Ваш pull request к тому milestone, к которому относятся Ваши issues;

   • Нажмите open pull request.

7. Процесс review. При этом Вы будете с некоторыми поправками проходить по пунктам 4-7, пока для Вашего pull request не будет подтверждено достаточное количество review.

8. Тестирование и доработка. Тестирование производится когда Ваш pull request одобрен, но merge еще не произведен. В случае, если обнаружены неполадки в работе, доработайте Ваше решение.

9. Merge pull request-а. Если этот PR закрыл все задачи по feature, тогда не забудьте удалить Вашу ветку.