Разбор обновления до установки пакетов
Обновление одного верхнего пакета может изменить транзитивный код, источники и install-скрипты. В этом уроке составим карточку ревью до сетевой установки. Она должна объяснять необходимость изменения и будущий объём проверки, не имитируя выполненный аудит.
Сравниваем модели v1 и v2 «Контура выпуска». Все имена и advisory вымышлены; архив не содержит настоящей скачанной зависимости. Пользователь запретил установки и тесты, поэтому работа ограничивается исходными авторскими данными.
Читаем разницу как набор решений
В update-review.md причина обновления сформулирована предметно: нужна обработка дополнительного формата входных данных. Это отделяет продуктовую необходимость от желания иметь последнюю версию. Далее карточка перечисляет прямое изменение lab-render, транзитивный parser и новый lifecycle-скрипт. Каждое имеет собственный статус рассмотрения.
Манифест заявляет диапазон, дерево выбирает версии, исходники пакета объясняют поведение. Эти документы дополняют друг друга. Наш fixture не содержит настоящих исходников lab-render, поэтому соответствующее поле остаётся source_review_pending. Нельзя объявить пакет проверенным только потому, что таблица diff полностью заполнена. Ревью модели и ревью кода — разные результаты.
Для изменения источника нужно отдельное внимание. Реестровый пакет, Git-ссылка и локальная папка имеют разные механизмы получения. Сохраните resolved, тип происхождения и предполагаемый способ фиксации. Если эти сведения отсутствуют, карточка не назначает установку автоматически. В нашем примере источники .example заведомо не предназначены для скачивания.
Скрипт требует проверки ресурсов: зачем он нужен, что читает, куда пишет, выполняет ли сеть, какие команды вызывает. Ответы можно получить только по соответствующему коду и условиям, а не по имени postinstall. У полезного нативного пакета такой скрипт может быть необходим; у другого — избыточен. В лаборатории неизвестные ответы остаются в карточке.
Рассмотрим разрешение из прошлого урока. Оно относится к lab-native 1.2.3. Если модель обновляет его до 1.3.0, прежнее ревью не переносится автоматически. Сначала рассматривают новую версию, затем создают ограниченное решение. Карточка связывает изменение allowScripts с конкретным экземпляром и не предлагает массовое утверждение ради успешной установки.
Критерий принятия и отложенное выполнение
Для будущего принятия зададим наблюдаемый результат: требуемый формат обрабатывается, прежние страницы сохраняют адреса, лишние файлы и секреты не попадают в артефакт. Это план проверки, а не её выполнение. Карточка execution_status: not_run остаётся честной независимо от подробности ожидаемых ответов.
Обновление может потребовать несовместимого изменения API. В таком случае ревью должно включать затронутый собственный код и миграцию, а не только новую запись lockfile. Автоматическая команда исправления зависимостей способна сделать более широкое изменение, чем предполагалось. Для нашей узкой лаборатории решение сначала описывается, затем сравнивается с продуктовой задачей.
Сохраните варианты «принять после проверки», «отложить», «заменить приём» и «удалить ненужную зависимость». Последний вариант иногда проще обновления: если собственный код не использует возможность, пакет может не быть необходим. Но отсутствие прямого импорта не всегда доказывает ненужность; сборщик и плагины могут подключаться иначе. Причину решения нужно объяснить.
Результат — карточка с известной разницей, неизвестным исходным кодом и будущими критериями. Следующий урок добавит учебную запись advisory. Она покажет, почему найденная уязвимость тоже требует связи с конкретной стадией и доступным путём воздействия.
Ревью удобно передавать вместе с исходной задачей. Иначе другой человек увидит только технический diff и не поймёт, какая возможность должна появиться. В нашей карточке причина и ожидаемый артефакт находятся в первых строках. Это помогает отделить необходимую работу от случайных попутных обновлений.
Если решение отложено, запишите причину и срок следующего разбора. Слово pending без владельца постепенно превращается в забытое исключение. Для вымышленной лаборатории это роль demo-maintainer; в собственном проекте понадобится действительный ответственный. Ни роль, ни дата не заменяют проверки, но позволяют сохранить процесс открытым и понятным после завершения текущей редакционной партии.
| Изменение | Состояние решения |
|---|---|
| lab-render | Продуктовая необходимость описана, но настоящие исходники пакета не получены и не просмотрены. |
| lab-parser | Транзитивная версия должна рассматриваться вместе с родителем, а не исчезать из краткой карточки обновления. |
| lab-native | Новая версия требует отдельного решения о скриптах и не наследует прежнее содержательное ревью. |
| Проверка результата | Критерии описаны для будущего выполнения; в этой подготовке программы, тесты и установки запрещены. |
Передача карточки другому разработчику
Представьте, что обновление рассматривает человек, который не видел исходный запрос. Открыв update-review, он должен понять нужную возможность, изменённые компоненты и причину остановки. Если документ содержит только номер версии и кнопку approve, полезного ревью ещё нет. В нашей карточке неизвестные исходники названы прямо, поэтому автор не может принять модель за просмотр кода.
Объясните, какой факт изменит решение. Например, просмотр конкретного install-скрипта подтвердит необходимость локального файла, но не решит вопрос источника архива. Согласованность lockfile позволит определить дерево, но не подтвердит прежние страницы. Каждый критерий закрывает собственный пробел. Это помогает не принимать одно успешное свидетельство за завершение всей работы.
При оценке варианта удаления зависимости посмотрите на продуктовую задачу. Если нужная возможность реализуется небольшой собственной функцией, такой выбор может снизить область доверия. Но он увеличивает ответственность за собственный код и сопровождение. Карточка должна назвать этот обмен, а не объявить отсутствие зависимостей универсально лучшей архитектурой.
Для параллельной работы полезно разделить владельца продуктового результата и владельца политики. Первый знает, зачем нужен формат. Второй следит за правами и источником. В маленькой команде роли объединяются, однако вопросы остаются самостоятельными. В нашей лаборатории такая запись показывает, как передавать задачу без скрытого разрешения на установку или публикацию.
Наконец, сохраните версию карточки после изменения решения. Отложенное обновление может быть принято позднее по новому основанию. Если переписать старое pending без истории, пропадёт объяснение, почему предыдущий выпуск оставался на старом дереве. Журнал принятия дополняет технический diff и связывает его с фактической жизнью проекта.
Если критерий готовности нельзя наблюдать на выбранном результате, уточните его до начала установки. Например, сохранение адресов относится к выходным страницам, а необходимость сети относится к поведению скрипта. Один общий пункт не должен скрывать разные предметы проверки.
Полный основной артефакт update-review.md выбранного состояния:
# Карточка обновления MODEL-UPDATE-01
fictional:true; execution_status:not_run.
Причина: дополнительный формат данных. Изменения: lab-render 1.4.2→1.5.0, lab-parser 0.8.0→0.9.0, lab-native 1.2.3→1.3.0. Исходники реестровых пакетов не получены: source_review_pending.
Решение: отложить установку до отдельного ревью. Ожидаемая проверка: нужный формат, сохранение адресов, политика install-скриптов, отсутствие лишнего содержимого результата. Секреты, CI и публикация не используются. Owner: demo-maintainer.Все исходники серии: папка lesson-04 содержит полный самостоятельный снимок, собственный проект и авторские модели. Исполнение примеров, npm, установки, аудит, тесты, CI, настройки и публикация не выполнялись.