Жизненный цикл релиза TRIKStudio

Политика работы с TRIKStudio строго подчиняется процессу работы, описанному в документе Процесс, но имеет ряд особенностей, связанных с тем, что TRIKStudio — продукт, доступный широкой публике и используемый сторонними людьми. Посему процесс работы более строго регламентирован.

• Работа ведётся короткими итерациями, длительностью от двух недель до месяца. Результатом итерации является выкладываемый для широкой публики релиз.
• Жизненный цикл релиза состоит из следующих фаз:
  1. Планирование. На этой фазе производится анализ и оценка существующих задач (требований и открытых багов), с помощью Product Owner задачи сортируются по приоритетности, отбираются задачи на спринт, назначается дата релиза. Длительность фазы — 1-2 дня.
  2. Разработка. На этой фазе выполняются задачи, запланированные на спринт, и ничего больше. Исключительные ситуации смены приоритетов разработки описаны ниже.
  3. Тестирование. На этой фазе собирается инсталлятор, выполняются все автоматические тесты, проводится ручное регрессионное тестирование согласно тестовым сценариям, тестируется вся новая функциональность и процесс инсталляции на чистой виртуалке. Критические замечания исправляются в процессе тестирования, замечания с более низким приоритетом откладываются на следующий спринт (о типах замечаний и политике работы с ними см. Багтрекер). Длительность фазы — 2-3 дня.
  4. Выкладывание. Собранный и протестированный инсталлятор выкладывается на Google Drive так, чтобы он был доступен неавторизванному пользователю, ссылка на него — на http://robots.qreal.ru/, на обоих сайтах публикуется новость (согласно документу Выкладывание новой версии TRIKStudio вручную).
• Схема именования релиза: robots-<major version>.<minor version>.<release>.
  • release увеличивается на 1, если версия содержит только исправления и незначительные улучшения.
  • minor version увеличивается на 1, если версия имеет новую достаточно крупную функциональность.
  • major version увеличивается на 1 при крупных изменениях в системе. При этом не гарантируется совместимость по формату сохранённых файлов.

О работе с задачами

• Источником задач могут служить как запросы пользователей, так и задачи, предложенные членами команды.
• Все задачи заносятся в проект на PivotalTracker, в Icebox.
• Задачи заносятся ASAP.
• PivotalTracker — инструмент разработчиков, пользователи должны пользоваться другими способами сообщения о задачах (например, Google+ сообщество)
• На фазе планирования выполняется оценка всех неоцененных задач в очках сложности, одно очко примерно соответствует 4 человекочасам.
• Далее с помощью Product Owner-а выполняется приоритизация задач, приоритетные задачи помещаются в Backlog в трекере и сортируются по приоритету.
• Далее с помощью Product Owner-а отбираются задачи на следующий спринт, после чего в трекере заводится Release с датой следующего релиза.

Правила работы с ветками в git

• В релиз может быть включена только замердженная в master функциональность. В случае, если master имеет нежелательную для включения в релиз функциональность из других проектов, допустимо отводить релизный бранч для роботов, который после релиза мерджится в master.
• Вся разработка членами команды разработчиков ведётся в feature-бранчах внутри основного репозитория. Например, при правке бага из багтрекера от текущего master-а отводится новый бранч с номером бага (заранее это все делать забывают, поэтому опция "commit to new branch" в TortoiseGit оказывается весьма полезной), правки выкладываются в неё. Когда разработка закончена и изменения готовы к мерджу, из бранча делается пуллреквест, который проходит стандартную процедуру ревью из Процесс. Бранч после мерджа удаляется.
• Разработка не членами команды (например, студентами) ведётся в своих репозиториях, отфорканных от основного, когда они заканчивают разработку, делают пуллреквест в master по стандартной процедуре.

Правила выкладывания релиза

• Ещё раз, в релиз может быть включена только замердженная в master функциональность или функциональность из бранча текущего релиза.
• Вся новая функциональность (и важные изменения в старой) должна быть соответствующим образом отражена в пользовательской документации (https://github.com/qreal/qreal/tree/master/plugins/robots/editor/doc/html).
• Вся новая функциональность (и важные изменения в старой) должна быть протестирована.
• По возможности на новую функциональность должны быть юнит-тесты.
• Релиз должен выкладываться по правилам, описанным в Выкладывание новой версии TRIKStudio вручную или в Выкладывание новой версии TRIKStudio автоматизированно.
• После выпуска релиза в гите на коммит, по которому собирался инсталлятор, ставится тэг с именем релиза.

Исключительные ситуации

• В случае, если релиз выпускается по тем или иным причинам без прохождения полного цикла тестирования, он получает статус Release Candidate, что отражается в добавлении -RC<candidate number> к имени релиза. candidate number продвигается по мере исправления критических ошибок и выкладывания на сайт, до выкладывания основного релиза. При выпуске RC на сайте появляется новость о выпуске экспериментальной версии и отдельная ссылка на её скачивание. При выпуске "нормального" релиза после RC ссылки на RC удаляются.
• В случае возникновения срочных задач, не запланированных на текущий спринт, которые не могут быть отложены на следующий, спринт прерывается и переходит на фазу планирования.