Integration Readiness Review

main.md

Integration Readiness Review

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

Цель

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

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

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

Флоу

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

Integration Readiness Checklist

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

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

Процессы

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

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

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

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

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

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

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

Команда

• контрибьюторы
• владелец компонента (например проджект-менеджер, в случае смежников)
• тимлид/техлид проекта (в случае смежников)