Рецепт гладкого релиза: PMy на заметку

  • Tutorial
Всё ближе момент, когда мы выпустим в свет наше решение, свежее, новенькое и сияющее. Волнительно? Не очень, ведь мы его уже проверили со всех сторон.

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

На основе этого плана мы ставим задачи разработчикам и «аудиторам» — коллегам из других отделов, которые проводят ревью решения (да, это тоже лайфхак). Надеемся, эта шпаргалка пригодится для подготовки к релизу продукта в прод.



Инфраструктура


  1. Подготовлены с нашей стороны и приняты заказчиком требования к UAT и Prod инфраструктуре на стороне заказчика. Подготовлена сама инфраструктура на стороне заказчика, предоставлен доступ.
  2. (Для корпоративных мобильных приложений) Согласована схема распространения приложения на устройства пользователей (магазин приложений / MDM система / что-то еще). Заказчиком организована закупка устройств.
  3. Настроен конвейер CI/CD и/или прописана технология обновления решения.
  4. Продумана стратегия резервного копирования и восстановления и подготовлена соответствующая инфраструктура.
  5. Продумана и реализована система технического мониторинга решения и диагностики проблем (ELK стек, средства мониторинга k8s и т.д.)

Первоначальное наполнение решения


  1. Исторические данные. Решено, из каких источников и на какую глубину нужно мигрировать данные, есть технология/механизм/инструменты миграции.
  2. Продумана процедура и подготовлены инструменты (утилиты, скрипты) проверки корректности (полноты, консистентности) мигрированных исторических данных.
  3. Наполнены справочники.
  4. Перенесены пользователи / оргструктура.

Интеграция


  1. Проверена работоспособность интеграционных сервисов в UAT/Prod окружении. Есть версионность сервисов со стороны заказчика и/или с заказчиком согласована процедура подготовки к обновлению версии сервисов на их стороне.
  2. Настроена панель мониторинга или инструменты доступности сервиса для «мгновенной» проверки, на чьей стороне проблемы.

Обучение пилотной группы пользователей


  1. Подготовлены демо-стенды для демонстрации решения заказчику, организованы доступы, организованы раздачи приложения и тестовые девайсы.
  2. Определена группа внедрения со стороны заказчика и привлечена на тестирование при подготовке релиза еще на QA окружении — проведены демонстрации.
  3. Проведены итоговые тест-сессии/демо-сессии с пилотной группой пользователей.
  4. Подготовлены материалы для пользователей: сценарии демонстрации, короткие “How-to” со скринами/роликами, демонстрирующими бизнес-действие.

Передача решения


  1. План передачи исходников, план настройки серверов сборки на стороне заказчика.
  2. План передачи исходников и ресурсов UI: макеты, UI kit, инструкция по использованию UI kit.
  3. Подготовлены архитектурные документы (топология инфраструктуры, технология деплоя и т.д.) для передачи заказчику на эксплуатацию.
  4. Проведен инструктаж и тренировочный деплой с админами заказчика.
  5. Проверено, что еще нужно сделать для формальной/юридической передачи в эксплуатацию в соответствии с требованиями договора с заказчиком.
  6. Проработана процедура постановки решения на техподдержку на стороне заказчика (первая линия) и на нашей стороне (вторая линия). Настроена система учета обращений.

Пользовательская документация


  1. Руководство пользователя / инструкции в согласованном с заказчиком формате (сценарии, ролики и т.п.)

Бизнес-мониторинг


  1. Выработано и согласовано с заказчиком понимание того, какие бизнес-показатели решения (KPI) мы будем отслеживать и анализировать.
  2. Есть данные и инфраструктура для мониторинга бизнес-показателей: например, аналитический куб со статистикой продаж в системе, Grafana со статистикой активности пользователей.

Выбор момента для релиза


  1. Выбрано удобное время для релиза/переключения на новую версию с учетом пиковых загрузок текущего функционала решения, времени доступности пользователей, времени доступности инженеров с обеих сторон и т.п.
  • +12
  • 4,1k
  • 3
True Engineering
87,95
Лаборатория технологических инноваций
Поделиться публикацией

Комментарии 3

    0

    Круто. Только один вопрос. Эта схема выдержит хотя бы два честных релиза в месяц? Честных — в смысле, что хотя бы в подготовке релиза только один релиз (потому что если 5 последующих в работе, то сбой в последнем аффектит ещё 4) и честный в том смысле, что со всеми перечисленными мероприятиями.

      +1

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


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

        +1
        Я думаю, это больше применимо к первому выходу в prod среду. Для последующих релизов, скорее всего, есть более короткий план или чек-лист.

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