19 октября 2018
Хардкор

Как организовать CI/CD на проекте: от постановки задач до настройки конвейера развертывания

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

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

 

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

Перед каждым проектом стоит ряд требований. Важно все их понимать и не путать. Бизнес-требования определяют, что система должна делать с точки зрения бизнеса. Например: приложение должно позволять пользователю осуществлять продажу билетов и дополнительных услуг с целью увеличения продаж агентов. Пользовательские требования описывают цели и задачи пользователей, которые будут осуществлять работу в системе для реализации бизнес-требований. Пользовательские требования часто представляют в виде User cases. Например: как пользователю, мне необходимо осуществлять продажу услуг за мили. Функциональные требования — что система должна делать. Определяют функциональность (поведение) системы, которая должна быть создана разработчиками для того, чтобы пользователи смогли выполнить пользовательские требования. Нефункциональные требования — как система должна работать. Сюда входят требования к производительности, качеству, ограничения, usability и т. д. tracker

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

Итак, мы описали виды требований. Теперь разобьём их на типы задач, расшифруем каждый тип и расскажем, как правильно его описывать. image Начнём с самой эпичной, то есть с 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 относится к функциональным требованиям, которые нужно учесть и описать в задаче при разработке продукта. И в роли потребителей здесь выступают части системы. Описывать их несложно. Главное помнить, зачем все это делается. image

 

Порядок описания 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. И не забывайте ставить корректный уровень приоритета :) Теперь, когда разобрались с общими принципами работы, расскажем, как организовали конвейер развёртывания. delivery

 

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

Чтобы ускорить поставку наших сервисов до продакшна, мы внедряем новый конвейер развертывания и используем 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 мог сообщать нам, на каком этапе находится фича. Это помогает тестировщикам оценить, на каком этапе нужно подключаться к задаче, а разработчикам — править ошибки. Так они видят, на каком этапе произошёл сбой, могут пойти в определенную ветку и воспроизвести её там. Надеемся, вам было полезно.

 

Оригинал опубликован на Habr.ru