Skip to content

Instantly share code, notes, and snippets.

@lesovsky
Created October 13, 2023 04:00
Show Gist options
  • Save lesovsky/6cc9e40ed54df5b3f5aebb3b5f0de816 to your computer and use it in GitHub Desktop.
Save lesovsky/6cc9e40ed54df5b3f5aebb3b5f0de816 to your computer and use it in GitHub Desktop.
Integration Readiness Review

Integration Readiness Review

Статус: Черновик

Цель

Для интеграции стороннего компонента в основной продукт, этот компонент должен удовлетворять набору требований:

  • стабильность и качество
  • принадлежность и сопровождаемость
  • документация

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

Флоу

При появлении запроса на интеграцию, создается IRR-задача (Integration Readiness Review) в которой проводится анализ компонента на соответствие требованиям. Каждый пункт закрывается ссылкой на соответствующие документы, формы, веб-интерфейсы и т.д. Ревью выполняется тимлидом/техлидом основного продукта. В результате ревью получается документ. Компонент может как соответствовать (позитивный сценарий), так и не соответствовать (негативный сценарий) требованиям. В случае негативного сценария для соответствия могут быть заведены соответствующие задачи. Также в случае негативного сценария, вышестоящее руководство оценив риски может настоять на интеграции, беря на себя ответственность за последствия (снижение качества основного продукта, увеличение негативного фидбека от клиентов, сдвиг сроков релизов и пр.).

Integration Readiness Checklist

Тестирование

  • в процесс разработки продукта должны быть внедрены авто тесты (CI) на минорные изменения
  • в процесс разработки продукта должны быть внедрены (авто)тесты на мажорные изменения (main, release, hotfix)
  • при наличии пакетов должно быть внедрено тестирование пакетов

Процессы

  • должен быть устоявшийся механизм для создания заявок на добавление/изменение функциональности
  • процесс доработки должен быть формализован, исполнители должны быть обозначены явно
  • у продукта должна быть владелец, команда разработки, поддержки/сопровождения

Эксплуатация

  • продукт должен быть развернут как минимум у N клиентов
  • продукт должен быть в эксплуатации не менее N месяцев

Релизный цикл

  • продукт должен быть в стадии General Availability
  • у продукта должен быть Roadmap

Документация

  • у продукта должна быть стабильная публичная документация (будь то API, CLI или сервис)

Команда

  • контрибьюторы
  • владелец компонента (например проджект-менеджер, в случае смежников)
  • тимлид/техлид проекта (в случае смежников)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment