В чем залог успешной настройки Continuous Delivery на проектах? Слаженная работа команд разработки, тестирования и инженеров по инфраструктуре. Спасибо, кэп, как говорится :) Но как это реализовать на практике? В этой статье поделимся нашими наработками, как это всё организовать и воплотить в жизнь.

Мы обобщили базовые основы в одну шпаргалку для себя и делимся с вами:

• Какие бывают требования и чем они характеризуются,
• Типы задач и порядок их описания в Issue tracker,
• Как оформлять User story и Tech story,
• Как описывать баги,
• Настройка конвейера развертывания.

Опытные инженеры вряд ли узнают из статьи что-то новое, но надеемся, что начинающим специалистам эта информация пригодится.

Какие бывают требования и чем они характеризуются

Перед каждым проектом стоит ряд требований. Важно все их понимать и не путать.

Бизнес-требования определяют, что система должна делать с точки зрения бизнеса.

Например: приложение должно позволять пользователю осуществлять продажу билетов и дополнительных услуг с целью увеличения продаж агентов.

Пользовательские требования описывают цели и задачи пользователей, которые будут осуществлять работу в системе для реализации бизнес-требований. Пользовательские требования часто представляют в виде User cases.

Например: как пользователю, мне необходимо осуществлять продажу услуг за мили.

Функциональные требования — что система должна делать. Определяют функциональность (поведение) системы, которая должна быть создана разработчиками для того, чтобы пользователи смогли выполнить пользовательские требования.

Нефункциональные требования — как система должна работать. Сюда входят требования к производительности, качеству, ограничения, usability и т. д.

Типы задач и порядок их описания в Issue tracker

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



Начнём с самой эпичной, то есть с Epic.

Epic — это общая задача, в которой собраны все User Story с учётом времени разработки сервиса. Он описывает главную цель продукта или сервиса. Основная цель Epic — собрать задачи и хранить их в одном месте независимо от того, какие новые требования выдвигаются к продукту. Epic всегда больше user story и может даже не умещаться в одной итерации.

Решение Epic-задачи позволяет создать MVP (Minimal Viable Product) — минимальный жизнеспособный продукт. Другими словами, то, что необходимо выпустить, чтобы изучать и адаптировать продукт по откликам от конечных пользователей.

Чем Epic отличается от User Story?

1. Epic — это просто большая история пользователя, отличительной особенностью которой является наличие явной ценности для пользователя.
2. Начиная формировать истории пользователей, т. е. собирая требования к проекту, мы обычно движемся от общего к частному — сначала определяемся с концепцией проекта, выделяем основные персоны (пользователей системы), формируем перечень основных фич, и дальше эти фичи детализируем в отдельные пожелания — User story.

Порядок описания Epic таков:

1. Название / Summary Title — название нового функционала.
2. Описание / Description — пишется по шаблону:
   
   Роль пользователя (как такой-то пользователь, я…) / Действие пользователя (хочу сделать что-то…) / Результат действия (чтобы получить такой результат, который…) / Интерес или выгода (позволит мне получить такие-то выгоды…).
3. Примерный план реализации или краткое описание основных User Stories, которые будут выполнены в рамках Epic с учетом MVP.
4. Вложения / Attachments — прикрепляем переписку, технологии и другую необходимую информацию.

Как оформлять User story и Tech story

Отличие User story и Tech story в том, что Tech Story относится к функциональным требованиям, которые нужно учесть и описать в задаче при разработке продукта. И в роли потребителей здесь выступают части системы.

Описывать их несложно. Главное помнить, зачем все это делается.

Порядок описания User story вполне стандартный:

1. Название / Summary / Title — краткое описание нового функционала или доработки на языке, понятном заказчику.
2. Описание / Description включает в себя основную цель и желаемый результат. Как, <роль пользователя>, я <хочу получить>, с целью <результат действий>.
3. Критерии приёмки / Acceptance Criteria — это список приоритетных критериев продукта. То есть измеримое определение того, что следует сделать с продуктом, чтобы он был принят заинтересованными сторонами проекта.
4. Технические заметки, модели, макеты, структурные схемы страниц.
5. Вложения / Attachments — все необходимые технологии, документы, переписка с заказчиком.

Как описывать баги

Какую информацию нужно указывать, когда депортим баг:

1. Название / Summary / Title кратко описывает суть ошибки и указывает на место, где находится проблема.

2. Описание / Description содержит следующие шаги:

• как воспроизвести ошибку / шаги по воспроизведению,

• текущий результат,

• ожидаемый результат.

3. Вложения / Attachments — все необходимые логи, скриншоты, ссылки на Kibana и другие файлы.

4. Среда / Environment — отметка, в какой среде воспроизводится ошибка, и категория, к которой относится проблема. Например, ошибка на UI, ошибка CORE, ошибка SWS и т. д.

5. Приоритет / Priority позволит каждому члену команды оценить серьёзность проблемы, а менеджеру — увидеть её в списке первых кандидатов в sprint.

И не забывайте ставить корректный уровень приоритета :)

Теперь, когда разобрались с общими принципами работы, расскажем, как организовали конвейер развёртывания.

Настройка конвейера развертывания

Чтобы ускорить поставку наших сервисов до продакшна, мы внедряем новый конвейер развертывания и используем GitFlow для работы с кодом.

Чтобы делать это быстро и динамически, мы развернули несколько GitLab-раннеров, которые запускали все задачи по пушу разработчиков. Благодаря подходу GitLab Flow, у нас появилось несколько серверов: Develop, QA, Release-candidate и Production.

Continuous Integration начал собирать и прогонять тесты по каждому комиту, прогонять unit-тесты и интеграционные тесты, складывать артефакты с поставкой приложения.



Разработка происходит так:

1. Разработчик добавляет новый функционал в отдельной ветке (feature branch). После этого он создает запрос на слияние его ветки с магистральной веткой разработки (Merge Request to Develop branch).
2. Запрос на слияние смотрят другие разработчики, принимают его (или нет) и исправляют замечания. После слияния в магистральную ветку разворачивается специальное окружение, на котором выполняются тесты на поднятие окружения.
3. Когда все эти этапы закончены, QA инженер забирает изменения к себе в ветку “QA” и проводит тестирование.
4. Если QA инженер согласовывает проделанную работу, изменения переходят в ветку Release-Candidate и разворачиваются на окружении, которое доступно для внешних пользователей. На этом окружении заказчик производит приемку и сверку технологий. Затем мы перегоняем всё в Production.

Если на каком-то этапе находятся ошибки, то именно в этой ветке мы их и решаем, после чего выкладываем результат в Develop.

Также мы сделали небольшой плагин, чтобы Redmine мог сообщать нам, на каком этапе находится фича. Это помогает тестировщикам оценить, на каком этапе нужно подключаться к задаче, а разработчикам — править ошибки. Так они видят, на каком этапе произошёл сбой, могут пойти в определенную ветку и воспроизвести её там.



Надеемся, вам было полезно.