Как организовать релиз по

Как организовать релиз

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

Настроить календарь

Настроить дату в корпоративном календаре и убедится что все стейкхолдеры в курсе.

Сделать таблицу в вики

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

Release notes

Это то самое “что именно вошло в релиз”. В первую очередь, этими данными нужно поделится с аналитиками: любые изменения в KPI они могут сравнивать с тем, что вошло в релиз. На основании этих данных они могут делать выводы, какой функционал нужен пользователям, какие идеи хорошие, а какие нет, и что войдет в следующею итерацию.

Внутренний анонс

Другим отделам важно знать когда произошел релиз, чтобы, например, сделать посты в соц. сетях о новой версии продукта (создать инфоповод), следить за KPI (возможен рост или падение метрик) и т.д.

Во время релиза

Создать релизный бранч

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

Отправить уведомление

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

Сделать тэг

Обязательно сделать тэг, когда релиз финализирован, и затянуть фиксы в девелоп-ветку.

Сделать сам релиз

В идеальном варианте у вас должны быть механизмы, которые контролируют релиз: например, сделать релиз только на 10% пользователей или только на не платящих. Это необходимо для того. чтобы уменьшить урон от ошибок, которые возникли в процессе разработки и не были найдены во время тестирования.

Релиз одной кнопкой

Мифический. Безусловно, чем меньше человеческого фактора участвует в релизе, тем лучше. Но это нормально, если не все получается автоматизировать.

Если все пошло не так, как планировалось

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

После релиза

Мониторить

Не забывайте мониторить ошибки, нагрузку на сервера. Также стоит обратить внимание на KPI: если вы сделали релиз и у вас упало DAU, то, возможно, что-то работает не так хорошо, как должно было, либо сломаны сами средства мониторинга. Любую подозрительную активность стоит проверить.

Сообщить об успехах и неудачах

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

Провести ретроспективу

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

Заказать пиццу и отпраздновать

Во время таких посиделок просто коллеги становятся друзьями и боевыми товарищами. А это значит, что в следующем бою друзья не подведут.

Начать подготовку к следующему релизу

Мне очень нравится идея Release train, когда каждый релиз проходит регулярно в четко обозначенные даты. Благодаря этому механизм релиза отлаживается командой. Как я писал выше, не обязательно делать релиз на 100% пользователей: можно выкатить на небольшую группу людей.

Как организовать релиз по

У нас есть два основных принципа:

1. Команда делает проекты качественно, в срок и с прибылью для компании;
2. Большинство решений, связанных с реализацией проектов, команда принимает самостоятельно, так как основные процессы в компании автоматизированы и прозрачны.

Проект любого масштаба мы разделяем на семь обязательных этапов.

1. Выбираем методологию

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

При классической методологии:

Команда будет работать строго по ТЗ. Результат, который вы получите в итоге, будет ровно таким, каким вы его запланировали в самом начале.

При гибкой методологии:

Команда сможет решать вопросы «на ходу», подстраиваться под рынок и менять требования в моменте. Результат, который вы получите «на выходе», может сильно отличаться от предполагаемого.

Если вам нужно быстро запустить MVP-версию продукта и понять, в каком направлении его развивать – выбирайте гибкую методологию.

2. Определяем роли и состав команды

Решив, по какой методологии вы будете делать проект, легче понять, кого набирать в команду и как делегировать задачи. Определите, какие специалисты нужны под проект. Основную экспертизу держите внутри компании, а «руки» можно подключить и на аутсорс.

Классический отдел разработки состоит из следующих сотрудников:

• менеджер проекта: контролирует рабочий процесс, дедлайны, оптимизирует работу сотрудников;
• архитектор: определяет стек технологий, проектирует общую инфраструктуру проекта, его основные компоненты, модули и сервисы;

• frontend- и backend-разработчик/fullstack-разработчик: первые занимаются визуальной и вычислительной частью проекта, а второй, как универсальный солдат, владеет знаниями разных технологий;

• тестировщик: обеспечивает качество программного продукта с самого начала разработки и до его финальной сдачи;

• тимлид: декомпозирует и делегирует задачи, проводит код-ревью и поддерживает боевой дух команды;

• дизайнер: определяет внешний вид продукта, его интерфейс и юзабилити;

• аналитик: проектирует и оптимизирует процессы, руководит внедрением новых IT-систем и адаптирует систему работы к новым задачам;

• системный администратор: осуществляет бесперебойную работу серверов, настраивает площадки для разработчиков и обеспечивает техническую инфраструктуру.

В некоторых из них нет необходимости, если проект небольшой – например, в архитекторе или аналитике. Главное: берите профессионалов, на которых сможете положиться и которые в состоянии принять решение по специфичным вопросам.

3. Проводим CustDev, собираем требования с клиентов, пишем техническое задание

Опросите конечных пользователей, чтобы выявить их потребности и получить максимально реалистичный прототип продукта. Такое исследование нужно провести «на берегу», до начала рабочих действий по проекту, чтобы конечный продукт был жизнеспособен и чтобы сделать продукт под запрос, а не наоборот.

Уделите внимание техническому заданию. ТЗ – гарант, что вы не потратите время зря, не переплатите и получите нужный результат. Кроме того, оно обеспечивает техническое развитие продукта и поможет:

• оценить задачу по бюджету, срокам и объему человеко-часов;
• упростить сдачу-приемку проекта;
• объяснить специалисту, как устроена работа проекта и какую документацию нужно готовить «на выходе».

4. Обеспечиваем команду техническими инструментами

За настройку технической инфраструктуры отвечает системный администратор. Строить боевую инфраструктуру сразу не обязательно – выполните минимальную часть, чтобы обеспечить команде место для работы.

• репозиторий для кодовой базы проекта;
• общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
• рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).

Убедитесь, что у всех членов команды имеется доступ к инструментам разработки и рабочему окружению.

Задача сисадмина – предоставить стабильную и актуальную платформу для разработки проекта, настроить боевое окружение и обеспечить его поддержку.

Учитывайте, в каких условиях будет работать продукт. Среда разработки должна быть максимально приближена к боевой.

5. Планируем работу команды

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

Составляя график, учитывайте сдвиг сроков задач (например, увеличение сроков из-за исправлений ошибок) и продумайте, как одна задача зависит от другой.

Например, нет смысла разрабатывать оформление заказа, пока не разработаешь корзину или каталог. Тестировщик не сможет проверить задачу, пока не положит товар в корзину. Лучше делегировать эту задачу одному человеку, чтобы он делал корзину, а затем оформление.

Здесь же декомпозируйте по задачам техническое задание. Разбейте его на небольшие задачи и распределите трудовые ресурсы так, чтобы каждый сотрудник был полностью загружен задачами.

Постарайтесь избавиться от крупных задач — их сложно оценивать, контролировать, тестировать и запускать в релиз. В таких задачах гораздо чаще встречаются ошибки после релиза в боевую среду. Если задача занимает более 20-человека-часов — декомпозируйте ее на мелкие, иначе она рискует превратиться в «болото».

6. Делегируем задачи, контролируем их выполнение

Делегирование — задача тимлида, который соотносит сложность задачи с уровнем специалистов. Он не отдаст младшему специалисту задачи, которые ему «не по зубам», или обеспечит поддержку, которая позволит ему выполнить задачи правильно.

Убедитесь, что разработчик верно понял задачу. Перед стартом соберите команду вместе и обговорите все этапы работы: каждый должен понимать, что делает команда в целом и какова его роль в этом процессе.

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

Контролируйте сроки — например, можно проводить ежедневные или еженедельные встречи с командой. Это поможет держать руку на пульсе, следить за этапами реализации проекта и вовремя решать возникающие сложности.

Неважно, какую методологию ведения проекта вы выбрали — гибкую или классическую. Следите за сроками: работа над проектом часто превращается в рутину, где легко зациклиться на мелких задачах. Не засыпайте! Отсекайте лишнюю работу, проверяйте задачи и сводите их в единое целое, чтобы адекватно оценить готовность проекта.

7. Выкладываем, тестируем и дорабатываем продукт

Тестирование каждой задачи повышает качество продукта и бережет вас от дефектного релиза с ошибками. Не забудьте про код-ревью — проверку кода, который написал разработчик. Обычно ревью проводит тимлид проекта или кто-то из старших разработчиков. Если возникают спорные моменты, привлекайте автора кода.

Перед выкладкой проведите пусконаладочные работы. Это финальный этап разработки перед запуском: продукт готовят к работе в боевой среде, и команда настраивает боевую инфраструктуру. Не забудьте про системы логирования, резервного копирования и прочие системы выявления сбоев и устранения их последствий.

После этого продукт выкатывается в боевую среду, его финально проверяют тестировщики.

Цифровой продукт нельзя сделать раз и навсегда. Поддерживайте его работу, чтобы он оставался актуальным и полезным для пользователей.

Помните, что завершенных проектов не бывает. Ошибки находят даже после выпуска продукта. Следите за ним даже после успешного выпуска и вовремя исправляйте дефекты.

Чтобы организовать процесс разработки, который будет работать без вашего участия:

1. Отталкивайтесь от методологии: она определит, как, в каком составе и в какие сроки вы будете работать;
2. Создайте команду специалистов и определите роль каждого: на самостоятельную команду можно положиться, ведь она сама принимает решения;
3. Не работайте вслепую: отталкивайтесь от запросов клиентов и создайте понятное, ясное и четкое техническое задание;
4. Обеспечьте рабочее пространство: для разработчиков это не только кресло, стол, кофе и печеньки, а репозиторий, технические инструменты и рабочее окружение;
5. Составьте график реализации проекта: разбивайте большие задачи на мелкие и следите, чтобы рабочий процесс был логичен, а разработчики не сидели без дела;
6. Назначьте ответственного по каждой задаче и контролируйте срок ее выполнения: так вам не придется удивлять разработчиков их «новыми» обязанностями спустя месяц со старта, и вы не затянете процесс даже при гибкой методологии;

Следите за продуктом даже после релиза: в IT-индустрии ни одно решение не будет работать вечно. Обновляйте модули, добавляйте новые технологии и инструменты, чтобы продукт всегда был актуальным.

Три ингредиента идеальных релизов ПО

Соедините одну часть архитектуры с двумя частями командной работы. Добавьте автоматизацию и перемешайте.

Автор: Dan Radigan

Просмотр тем

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

По тому, как проходит поставка кода, т. е. релиз ПО, можно с уверенностью судить о том, насколько верны принципам Agile разработчики ПО. Все усилия по быстрому планированию, разработке кода и тестированию пропадают зря, если на этапе релиза возникают проблемы. Поэтому команды Agile и DevOps применяют автоматизацию. Она помогает объединить усилия разработчиков и операционных команд на ранних этапах, а также внедрить непрерывную интеграцию и немедленно устранять дефекты.

Отличительная черта agile-разработки заключается в том, что код должен поддерживаться в состоянии готовности к релизу. Рациональное планирование и итеративная разработка теряют смысл, если вы не можете поставить код в любой момент, когда сочтете его готовым.

Идеальный релиз программного обеспечения начинается с модульной архитектуры

Какое бы ПО вы ни разрабатывали, лучше всего выпускать продукт чаще и с минимальными усилиями. Чтобы органично вписать релизы в культуру Agile, команда может создать модульную архитектуру (либо провести рефакторизацию существующей). Вместо того чтобы работать над одним внушительным приложением (таким как упомянутый ранее монолит), разбейте его на ранних этапах программы на несколько фрагментов-модулей. Объедините схожие функции в небольшие приложения или компоненты и составьте четкие планы («контракты») API для каждого приложения или компонента. Эти API можно подвергать автоматическому тестированию с каждой новой сборкой, чтобы убедиться в совместимости и сократить риски на этапе выпуска программного обеспечения.

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

Идеальные релизы программного обеспечения строятся на взаимопонимании

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

Чтобы операционные команды владели всей информацией и могли использовать все свои возможности, командам разработчиков нужно следовать следующим рекомендациям.

• Тщательно прорабатывайте спецификацию для каждого релиза ПО. Операционные команды не всегда имеют настолько же четкое представление о ситуации с релизом, какое есть у команды разработчиков.
• Приведите ссылку на каждую задачу релиза в трекере задач и системе управления исходным кодом. Тогда перед глазами операционной команды будет та же картина, что и у разработчиков, если в ходе развертывания возникнут проблемы.
• Иногда проблемы возникают при передаче кода из среды разработки в промежуточную среду. Обозначьте эти проблемы, поскольку они могут появиться вновь во время развертывания кода в рабочей среде.
• Нередко можно столкнуться с затруднениями в процессе развертывания. По этой причине нужно всегда сообщать операционной команде четкий маршрут эскалации, чтобы ничто не мешало решению проблем.

Следующие рекомендации будут полезными для операционных команд, сотрудничающих с разработчиками.

• Если проблемы возникли в рабочей среде, выделите время на поиск основных причин и решений. Тогда эти проблемы можно будет обойти (или аккуратнее устранить) в будущем.
• Переносите данные конфигураций из рабочей среды в промежуточную и среду разработки, чтобы избежать расхождений в конфигурациях.

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

Идеальные релизы программного обеспечения легко переносить из одной среды в другую

Автоматизация, автоматизация и еще раз автоматизация!

Ничто не совершенствует культуру релизов ПО так, как автоматизация. Если релизы ПО до сих пор не автоматизированы, самое время наладить автоматическое развертывание версии в промежуточной среде. Когда все поймут, насколько это просто, следующим закономерным шагом станет автоматизация развертывания в рабочей среде.

Если релиз новой версии ПО сопровождается сложностями, возьмите за правило выпускать новые версии часто, хотя бы в промежуточную среду. Когда команда разработчиков напрямую сталкивается с проблемами, с которыми сопряжен релиз, у нее появляется стимул внедрять инновации, чтобы упрощать (и автоматизировать) выпуск новых версий.

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

Идеальные релизы программного обеспечения — отличная штука!

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

Небольшими частыми релизами ПО проще управлять в рамках предоставления программного обеспечения как услуги (SaaS). В случае с загружаемыми продуктами большое значение имеет тесное сотрудничество между командами разработчиков, специалистов по эксплуатации и инженеров по сборке. Эти группы совместно работают над автоматизацией релизов ПО и заранее адаптируют автоматизацию к предстоящим изменениям в продуктах. Многие команды Atlassian автоматически развертывают каждую успешную сборку главной ветки в среде тестирования. Когда релиз ПО готов к переводу в промежуточную среду или к поставке клиентам, эти команды могут инициировать автоматическое развертывание одной кнопкой.

Поскольку мы являемся разработчиками ПО, на первом плане нашего цикла инновации должен находиться релиз ПО. С кодом, который мы написали, будут взаимодействовать клиенты, и они будут делиться своими впечатлениями. Круто! Если выпуск версий станет вашим привычным занятием в рабочие дни, вам будет проще выводить код в рабочую среду и с гордостью произносить: «Это мой код!»

Релиз-менеджмент: как подготовить проект к запуску за семь шагов

После продолжительной работы проект наконец-то готов: код написан, страницы сверстаны, онлайн-оплата подключена — осталось финально проверить ресурс и передать заказчику. Это последний и важный этап, который называется релиз-менеджмент. Мы сделали пошаговую инструкцию, которая поможет подготовить сайт или приложение для презентации заказчику.

Шаг 1. Запланируйте проверку и подготовьте чек-лист

Подготовку к релизу необходимо внести в план, как и другие этапы работы, чтобы команда могла в спокойном режиме протестировать ресурс и передать его заказчику. Срок зависит от масштаба проекта: если вы делаете простой сайт, то можно провести одну проверку в конце. Если продукт большой и сложный, то лучше проводить испытания поэтапно. А еще важно на старте прописать критерии и методы, с помощью которых вы будете оценивать проект.

Шаг 2. Сравните готовый макет с ТЗ

На этой стадии важно сверить техническое задание с получившимся макетом: все ли разделы соответствуют требованиям, есть ли какие-то неточности, насколько удобен продукт для пользователей. Ошибки необходимо исправить до начала верстки. Кстати, этот же тест можно провести повторно, когда проект уже будет готов.

Шаг 3. Сопоставьте макет с версткой

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

Шаг 4. Проверьте код

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

Шаг 5. Сделайте функциональное тестирование

Например, если вы разрабатываете интернет-магазин, то пройдите регистрацию, заполните личный кабинет, добавьте товары в корзину и оформите заказ. Это можно сделать как в ручном режиме, так и с помощью программ.

Шаг 6. Проведите нагрузочное тестирование

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

Шаг 7. Получите обратную связь от пользователей

Кажется, что уже проверили каждый элемент и можно смело передавать проект заказчику, но сделайте последний тест — покажите сайт нескольким пользователям, которые не участвовали в разработке, и узнайте их мнение. Так вы сможете убедиться, что продукт действительно хорош, или найти неочевидные ошибки.

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

Если вы работаете в IT-области, хотите добиться карьерного роста и испытать свои силы, то реализуйте задуманное в конкурсе «Цифровой прорыв. Сезон: искусственный интеллект». Вы сможете получить классный опыт в решении нестандартных задач, познакомиться с экспертами из индустрии и стать частью большого сообщества.

Читайте нас в Telegram — stranavozmojnostey Поделиться в социальных сетях