В чем ключ к успешной настройке непрерывной поставки в проектах? Скоординированная работа команд разработки, тестирования и инфраструктуры.
Спасибо, кэп, как говорится :) А как это реализовать на практике? В этой статье мы поделимся своими лучшими практиками, как все это организовать и реализовать.
Мы свели для себя основы в одну шпаргалку и делимся с вами:
- Каковы требования и чем они характеризуются? ,
- Типы проблем и порядок их описания в трекере проблем ,
- Как написать пользовательскую и техническую историю ,
- Как описывать ошибки ,
- Настройка конвейера развертывания .
Каковы требования и чем они характеризуются?
Каждый проект сталкивается с рядом требований.Важно их все понимать и не путать.
Бизнес-требования определить, что система должна делать с точки зрения бизнеса.
Например: приложение должно позволять пользователю продавать билеты и дополнительные услуги, чтобы увеличить агентские продажи.
Требования пользователя описать цели и задачи пользователей, которые будут работать в системе для реализации бизнес-требований.
Требования пользователей часто представляются в виде пользовательских кейсов.
Например: мне как пользователю нужно продавать услуги за мили.
Функциональные требования — что должна делать система.
Определите функциональность (поведение) системы, которая должна быть создана разработчиками, чтобы пользователи могли выполнять требования пользователей.
Нефункциональные требования — как должна работать система.
Сюда входят требования к производительности, качеству, ограничениям, удобству использования и т. д.
Типы проблем и порядок их описания в трекере проблем
Итак, мы описали виды требований.Теперь разобьем их на типы задач, расшифруем каждый тип и расскажем, как его правильно описать.
Начнем с самого эпического, то есть Epic. Эпический — общая задача, в которой собираются все пользовательские истории с учетом времени разработки сервиса.
Он описывает основную цель продукта или услуги.
Основная цель Epic — собирать задачи и хранить их в одном месте, какие бы новые требования не предъявлялись к продукту.
Epic всегда больше, чем пользовательская история, и может не уместиться даже в одну итерацию.
Решение проблемы Epic позволяет создать MVP (Minimal Viable Product) — минимально жизнеспособный продукт. Другими словами, что необходимо выпустить, чтобы изучить и адаптировать продукт на основе отзывов конечных пользователей.
Чем Epic отличается от User Story?
- Epic — это просто большая пользовательская история, отличительной чертой которой является то, что она представляет для пользователя очевидную ценность.
- Приступая к формированию пользовательских историй, т. е.
сбора требований к проекту, мы обычно движемся от общего к частному — сначала определяем концепцию проекта, выявляем основных людей (пользователей системы), создаем список основных особенности, а затем детализируем эти возможности в индивидуальные пожелания - История пользователя.
Порядок описания Эпика следующий:
- Название / Краткое название — название нового функционала.
- Описание - пишется по шаблону:
Роль пользователя (например, такой-то пользователь, я.
) / Действие пользователя (я хочу что-то сделать.
) / Результат действия (получить такой результат, что.
) / Интерес или выгода (будет позвольте мне получить такие-то льготы.
).
- Пример плана реализации или краткое описание основных пользовательских историй, которые будут завершены в рамках Epic с учетом MVP.
- Вложения — прикрепите переписку, технологии и другую необходимую информацию.
Как написать пользовательскую историю и техническую историю
Разница между Пользовательской историей и Технической историей заключается в том, что Техническая история относится к функциональным требованиям, которые необходимо принять во внимание и описать в задаче при разработке продукта.И части системы здесь выступают в роли потребителей.
Их легко описать.
Главное – помнить, для чего все это делается.
Процедура описания пользовательской истории вполне стандартна:
- Title/Summary/Title – краткое описание нового функционала или улучшения на понятном заказчику языке.
- Описание/Описание включает в себя основную цель и желаемый результат. Нравиться, , я , с целью .
- Критерии приемки — это список приоритетных критериев продукта.
То есть измеримое определение того, что необходимо сделать с продуктом, чтобы он был принят участниками проекта.
- Технические примечания, модели, макеты, схемы структуры страниц.
- Вложения - все необходимые технологии, документы, переписка с заказчиком.
Как описывать ошибки
Какую информацию следует предоставить при сообщении об ошибке: 1. Название / Краткое содержание / Название кратко описывает суть ошибки и указывает, где находится проблема.2. Описание/Описание содержит следующие шаги: • как воспроизвести ошибку/шаги по воспроизведению, • текущий результат, • Ожидаемый результат. 3. Вложения — все необходимые логи, скриншоты, ссылки на Кибану и другие файлы.
4. Среда — отметка, в какой среде воспроизводится ошибка, и категория, к которой относится проблема.
Например, ошибка пользовательского интерфейса, ошибка CORE, ошибка SWS и т. д. 5. Приоритет позволит каждому члену команды оценить серьезность проблемы, а менеджер увидит ее в списке первых кандидатов в спринте.
И не забудьте установить правильный уровень приоритета :) Теперь, когда мы поняли общие принципы работы, расскажем, как организовать конвейер развертывания.
Настройка конвейера развертывания
Чтобы ускорить доставку наших сервисов в производство, мы внедряем новый конвейер развертывания и используем GitFlow для работы с кодом.Чтобы сделать это быстро и динамично, мы развернули несколько бегунов GitLab, которые выполняли все задачи по подталкиванию разработчиков.
Благодаря подходу GitLab Flow у нас теперь есть несколько серверов: Develop, QA, Release-candidate и Production. Непрерывная интеграция начала собирать и запускать тесты для каждого коммита, выполнять модульные и интеграционные тесты, а также добавлять артефакты в поставляемое приложение.
Развитие происходит следующим образом:
- Разработчик добавляет новый функционал в отдельную ветку (feature Branch).
После этого он создает запрос на слияние своей ветки с основной веткой разработки (Merge Request to Develop).
- Другие разработчики смотрят мерж-реквест, принимают его (или нет) и исправляют комментарии.
После слияния в основную ветку разворачивается специальная среда, на которой выполняются тесты по поднятию среды.
- Когда все эти этапы пройдены, QA-инженер переносит изменения в свою ветку «QA» и проводит тестирование.
- Если QA-инженер одобряет проделанную работу, изменения перемещаются в ветку Release-Candidate и развертываются в среде, доступной внешним пользователям.
В этой среде заказчик принимает и проверяет технологии.
Затем мы переносим все в производство.
Это помогает тестировщикам оценить, на каком этапе им нужно подключиться к задаче, а разработчикам — исправить ошибки.
Таким образом они смогут увидеть, на каком этапе произошел сбой, и смогут перейти в конкретную ветку и воспроизвести его там.
Мы надеемся, что вы нашли это полезным.
Теги: #pm #управление проектами #qa #управление качеством #пользовательская история #ошибки #системные требования #EPIC #ci #непрерывная интеграция #Тестирование веб-сервисов #Управление проектами #DevOps
-
Os1: Примитивное Ядро Rust Для X86
19 Dec, 24 -
10 Атак На Веб-Приложения В Действии
19 Dec, 24
