Зачем
До этого публикация контента Build зависела от ручного суждения: соответствие контента требованиям, полнота структуры и корректность чтения runtime после публикации не имели единых точек проверки. Как только формат контента расходился с ожиданиями runtime, проблема обычно обнаруживалась только после публикации.
Цель этого изменения — не добавить функциональность, а превратить «можно ли публиковать контент» в вопрос, на который можно ответить до публикации: контент сначала проходит проверку контракта, затем CI-шлюзы и только потом попадает в процесс публикации.
Что изменилось
Изменения сосредоточены в нескольких взаимосвязанных частях: workflow, каталог контента, документация, модуль контента runtime, скрипты и тесты.
На стороне контента введены определения schema и topics, которые делают явной связь между заметками, variant и topic; на стороне скриптов выполняется проверка контента по контракту; на стороне тестов покрываются оба пути проверки — PHP и Node; на стороне workflow предпросмотр и шлюзы связываются в цепочку, так что до публикации необходимо пройти проверки.
Сама публикация завершается одним развёртыванием в production; запись о развёртывании вносится в документацию репозитория и помечается соответствующей меткой проверки. Конкретные версии, коммиты, дайджесты артефактов, количество тестов и счётчики корпуса см. в блоке facts выше.
Как мы это проверили
Проверка состоит из двух уровней. Первый уровень — автоматические проверки: два набора проверок, PHP и Node, выполняются в CI, и настроено несколько шлюзов, продолжение возможно только после прохождения всех. Второй уровень — проверка в production: после развёртывания артефакта в production runtime сообщил о своём состоянии и объёме загруженного контента.
Нужно различать два среза корпуса на разные моменты времени:
- Производственный корпус на момент развёртывания 1.3.5 | 5 заметок / 15 variant / 13 topics
- Текущий авторский корпус | 6 заметок / 18 variant (из них 1 ещё не опубликована)
Первое — снимок runtime на момент развёртывания, второе — текущее состояние контента в репозитории. Их несовпадение нормально: в репозитории могут быть ещё не опубликованные черновики.
- Версия
- 1.3.5
- Основной коммит релиза
- 57bf785a0bcd6e886397de776cbe7bd7156fd64c
- Production provenance (коммит)
- 4b4ec32a3aac70a8222ca7255f0db38fb6683200
- Развёрнутый артефакт
- weour-core-1.3.5.zip
- SHA-256 артефакта
- f660c0d9b48cbe774a3ba10d380eedfbf9a4fee5cf1a49c97c024ee7c1ee28ab
- SHA-256 манифеста плагина
- 952f570124787702fc8c71ce6ebd5410dca3099730b212d805189f3764d2a703
- Среда развёртывания
- production
- Состояние развёртывания
- deployed
- Состояние runtime
- ready
- Версия runtime
- 1.3.5
- Число модулей runtime
- 12
- Количество тестов
- PHP 1100 проверок / Node 97 проверок
- Число шлюзов
- 5
- Производственный корпус на момент развёртывания
- 5 заметок / 15 variant / 13 topics
- Текущий авторский корпус
- 6 заметок / 18 variant (из них 1 ещё не опубликована)
Что это не значит
Это не значит, что публикация контента с этого момента не требует ручного суждения. Конвейер проверяет контракт и структуру, а не то, уместен ли сам контент и стоит ли его публиковать.
Это не значит, что весь контент в репозитории уже опубликован. Текущее количество контента в репозитории больше, чем количество в runtime на момент развёртывания; разница — это ещё не опубликованные черновики.
Это также не значит, что данный процесс охватывает все будущие формы контента. Эта проверка относится к текущему контракту контента и пути чтения runtime; формы за пределами контракта в объём этой проверки не входят.
Наконец, это не является обещанием относительно последующих версий, сроков или возможностей. Здесь зафиксированы одна уже состоявшаяся публикация и проверка, а также подтверждающие её доказательства.