2learn

Управление и версионирование

Что это такое

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

Почему это важно

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

Ключевые идеи

Назовите владельца и маршрут

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

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

Отделяйте дополняющее изменение от ломающего

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

Minor    добавлен новый вариант или токен, ничего существующего не меняется
Patch    исправление отрисовки или документированного состояния
Major    API переименован или удалён, изменено значение по умолчанию, новый обязательный ввод

Дайте окно устаревания и крайний срок

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

Автоматизируйте проверку совместимости, а не суждение

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

Держите каждого потребителя на одной поддерживаемой версии

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

Практика

Напишите страницу управления

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

Готово, когда: потребитель точно знает, как запросить изменение и сколько времени у него на миграцию.

Проведите одно устаревание от начала до конца

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

Готово, когда: один потребитель мигрировал, дата удаления записана там, где он её видит, а трудозатраты зафиксированы для следующего.

Частые ошибки

  • Нет владельца — ничего не решается, и потребители форкают; исправить: назовите одного владельца с заявленным сроком ответа.
  • Централизованное одобрение всего — система становится узким местом, её обходят; исправить: пусть дополняющие изменения выходят без проверки.
  • Ломающее изменение без версии — потребители обнаруживают изменение в проде; исправить: пронумеруйте его, опишите миграцию и задайте окно устаревания.
  • Устаревание без крайнего срока — два API живут вечно; исправить: назначьте дату удаления и опубликуйте её.
  • Много живых мажорных версий — каждый фикс множится, согласованность теряется; исправить: согласуйте дату обновления и предоставьте миграцию.

Что читать дальше

Разобранные примеры

Файлы cookie аналитики ставятся только с вашего согласия. До вашего выбора ничего не загружается и никуда не отправляется.