Раздел: Методология разработки. Назначение: согласованный подход к подготовке и передаче изменений; это требование к работе автора, а не заявление о наличии автоматической системы внедрения.

Начать с наблюдаемой проблемы и ожидаемого результата. Определить продукт, installation root, owners и текущие revisions, уже применённые этапы, затронутые данные и потребителей. Условия из старой карточки или расшифровки сверяются заново. Рабочие ветки и installed modules определяет конфигурация и статус репозиториев; отсутствие checkout не компенсируется похожим продуктом.

Человек должен получить небольшой, цельный и проверяемый комплект: изменение, основание его применимости, полный сценарий применения и критерии результата. Для согласованных изменений ShariX Open/shared и Platform поставка разделяется по продуктам: общий код входит в root patch ShariX Open, Platform-owned адаптации — в её root patch. Shared на Platform приходит опубликованным Git commit, а не повторным применением первого patch. Если изменений для продукта нет, не создают пустой patch ради количества файлов. Самостоятельный внешний продукт, например Moodle plugin, имеет собственную базу и сценарий при наличии такого задания.

Сценарий помещается в тот же архив, что и patch, и доступен отдельной ссылкой. Один diff, многотомный набор промежуточных файлов или общий совет «обновите зависимости» не заменяют его. Не требуют распаковывать исходники поверх checkout и не создают второй installer. В командах указывают /tmp/ИМЯ.patch, когда оператор разместит patch в /tmp; автор не заявляет, что сам уже загрузил его на сервер.

1. В начале установить scope и прочитать текущие README/CODING_POLICY/AGENTS владельцев и актуальные Wiki runbooks. Различать исходники продукта, shared и работающую установку; не выдавать название доски за достаточное доказательство.
2. Проанализировать цепочку route → view/form/serializer → service/policy → модель/событие → consumer. Найти существующую функцию и библиотечный UI-элемент до создания нового. Не фиксировать только поверхностное совпадение имени.
3. Сохранять единственного владельца бизнес-состояния. Для handlers сохранять typed Blockly → deterministic Python → provenance; учитывать внешние пользовательские действия, API, таймеры и доставку событий. BPMN — описание, не исполняемый источник runtime.
4. Подготовить цельную поставку на проверенной базе. Дать человеку короткий маршрут: какой файл взять, где он должен лежать, из какого каталога и под какой ролью выполнить действия, что является успехом, когда остановиться.
5. Явно перечислить «Выполнено автором», «Выполняет оператор», «Не проверено». Не писать «всё работает» по compile/import или по результату другого продукта. Не скрывать предупреждения и не выдавать запланированную миграцию за выполненную.
6. Не угадывать SSH, systemd unit, секреты, актуальную ветку, базу данных и права пользователя. Неизвестное обозначать параметром с точным способом получения через штатную конфигурацию/runtime identity. Секреты не переносить в текст, логи и команды.
7. Проверить инструкцию как последовательность человеческих действий: есть ли все входные файлы, не требует ли шаг результата, который ещё не создан, корректны ли пути и роли, понятно ли поведение после отказа. Ссылки на артефакты должны вести к реальным подготовленным файлам.

Эти требования не дают дополнительных разрешений: подготовка patch, публикация Git, Wiki и внедрение на сервере — разные действия с собственным поручением. Необратимые или неавторизованные операции не скрывают внутри шага «проверка».

Сначала прочитать актуальную процедуру установки ShariX Open и публикацию owning repositories. Здесь фиксируется порядок передачи, а не универсальная команда для любого сервера.

1. Зафиксировать backup/restore point для затронутых данных и согласовать окно, если требуется schema/data change. Проверить статус всех owners, отсутствие незавершённых Git операций и совпадение базы; отдельно учесть частично применённый прошлый этап.
2. Оператор переносит подготовленные файлы в /tmp. Под назначенным deploy login переходит в фактический installation root. Для данного проекта последние подтверждённые пути — /opt/sharix-open-webapp-base и /opt/pre-sharix-platform-webapp-base; другой путь подтверждается заново.
3. Выполнить предусмотренный сценарием dry-run на точной базе. Применение multi-repository root patch должно учитывать самостоятельные owners: успешный dry-run только корневого Git не подтверждает файлы модулей. Не продолжать после failed hunk и не игнорировать .rej; сверить фактические before/after и исправить поставку.
4. Проверить изменения, опубликовать согласованный набор owning repositories штатным repositories.sh. При configured non-operational branch использовать документированный update-start → update-publish → update-finish. Consumer получает опубликованный shared-код через Git; затем сверяет SHA.
5. Выполнить точные дополнительные шаги данного изменения: необходимые миграции/переводы/static/env sync. Они должны быть названы в сценарии; не генерировать новые migrations автоматически на рабочем сервере.
6. Для уже подготовленного исходного состояния от deploy выполнить следующие фазы, останавливаясь при ошибке.

./bin/install.sh deploy --strict --use-current-checkouts --permissions=check --deps=auto --no-restart &&
./bin/install.sh restart &&
./venv/bin/python manage.py check &&
./bin/check_acceptance.sh --with-runtime-audit

Это последовательность фаз, а не разрешение выполнить весь блок после отказа первой команды. deploy может менять schema/config/data; –use-current-checkouts исключает обновление Git, –no-restart откладывает запуск. Успех preparation не доказывает готовность runtime state.

Если restart сообщает Restart permissions are not installed или Runtime state needs its managed isolated directory, сверить сообщение с текущим runbook: необходимый штатный root activate –strict –use-current-checkouts –permissions=check готовит managed state/grants. Затем новый deploy login и повтор только restart. Root bootstrap, полный deploy, рекурсивный repair, ручной chmod или симлинк не назначают вместо диагностики.

HTTP-диагностика после restart рекомендательная: отсутствие ответа/таймаут/HTTP-код остаётся видимым WARNING и не подменяет исход перезапуска службы. Permissions/service state/source/provenance errors блокируют продолжение. Имена units берутся из runtime identity, не из hostname.

При несовпадении базы, failed hunk, source conflict, незавершённой миграции или blocking guard не переходить к следующей фазе. Сначала записать, что фактически выполнено, и сравнить текущее состояние с ожидаемым. Обратное применение patch допустимо только после проверки его применимости и отсутствия новых изменений; rollback данных/миграций может требовать отдельного плана и backup. Не выполнять reset –hard, удаление файлов или повтор неизвестного POST ради «чистого» результата.

Одновременно уточняют контракт владельца, README и контекстную web-справку по роли. Wiki описывает использование и разработку продукта, Moodle — учебные объяснения. Изменённую страницу перечитывают, сохраняют её идентичность и concurrent edits, используют preview/base hash и каноническую GET-сверку. Уведомление даётся одним обзором связного этапа со ссылками; внутренние страницы не попадают в публичную группу.

Проверены опубликованные исходники указанных ревизий. Это source-анализ; он не подтверждает применённую версию, конфигурацию или успешный сценарий конкретного сервера.

• sharix-open-webapp-base: CODING_POLICY.md — f65376cdb5a3.
• sharix-open-webapp-base: bin/repositories.sh — f65376cdb5a3.
• sharix-open-webapp-base: bin/install.sh — f65376cdb5a3.
• sharix-open-webapp-base: bin/utils/install_modes.sh — f65376cdb5a3.
• sharix-open-webapp-base: bin/check_acceptance.sh — f65376cdb5a3.
• sharix-open-handlers-backend: ticket_blockly_codegen.py — 50baf376e224.
• sharix-open-handlers-backend: tools/check_canonical_ticket_codegen.py — 50baf376e224.