# Gitops Delivery

> Подготовить или проверить поставку через GitOps-контроллер, включая продвижение между средами, расхождения состояния и откат. Использовать, когда развёртыванием управляет версионируемое целевое состояние, а не для обычного редактирования манифестов.

- Skill: `fbakiyev/gitops-delivery` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fbakiyev/gitops-delivery`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fbakiyev/gitops-delivery/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fbakiyev (https://skillmd.com/u/fbakiyev)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/fbakiyev/gitops-delivery

---


# Поставка через GitOps

## Установи, что управляет работающей средой

- Определи исходную ревизию, итоговую конфигурацию после рендеринга, целевую среду, контроллер сверки состояния и принадлежащие ему ресурсы. Проверь, меняют ли эффект предлагаемой правки сверка состояния, удаление лишних ресурсов или обработка результатов проверок работоспособности.
- Отделяй изменения источника от наблюдаемых расхождений работающей среды. Прямая правка может быть перезаписана контроллером, а успешный commit не доказывает изменения целевой среды.
- Определи идентичности артефактов достаточно точно для повторного развёртывания. Изменяемый tag сам по себе не доказывает, какой образ тестировали или продвигали между средами.

## Подготовь и проверь поставку

1. Выполни рендеринг фактических целевых overlays и values, затем изучи полученный diff ресурсов. Проверь удаления, замены из-за неизменяемых полей, ссылки на секреты и охват namespace или кластера.
2. Изучи порядок зависимостей и миграции. Git revert может вернуть конфигурацию, оставив несовместимую схему БД или необратимый внешний эффект.
3. До разрешённого развёртывания определи путь продвижения, отката или исправления новой версией, критерии работоспособности и условия остановки. У исключений из сверки состояния должны быть срок действия и ответственный.
4. Подтверди, что контроллер принял нужную ревизию, ресурсы сошлись к целевому состоянию и пройдена репрезентативная проверка сервиса. Если часть ещё не завершена, сообщай об этих этапах отдельно.
5. Отрази аварийные изменения работающей среды в объявленном источнике либо зафиксируй принятое исключение и порядок возобновления обычной сверки. Не объявляй расхождение устранённым, пока источник и работающая среда не совпадают.

## Результат

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

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

Эти проверки применяют принципы версионируемого состояния и его сверки из [OpenGitOps](https://opengitops.dev/).