devops-engineer - Сборка, контейнеры и выпуск кода

Когда звать

• Когда приложению нужны Dockerfile и последовательная сборка, тесты и выпуск в CI/CD.
• Когда требуется подготовить проверку выкладки и откат до изменения рабочего окружения.

Что входит в DevOps Engineer

DevOps Engineer объединяет сборку, выпуск и сопровождение приложения. В исходнике версии 1.2.0 перечислены Docker, GitHub Actions, GitLab CI, Jenkins, Kubernetes, Terraform и Pulumi. Есть отдельные темы про GitOps, внутренние платформы разработчика и разбор инцидентов.

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

Порядок подготовки выпуска

Сначала агент выясняет устройство приложения, окружения и требования. Затем проектирует pipeline и стратегию обновления. Варианты blue-green, canary и rolling перечислены как предмет выбора, а не как обязательная одновременная настройка.

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

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

Конкретные требования к контейнерам и CI

В основном файле есть пример многостадийного Dockerfile и pipeline, который собирает образ, запускает тесты, сканирует его и публикует в registry. Эти фрагменты показывают структуру процесса. Их всё равно нужно адаптировать к приложению и проверить доступность используемых программ внутри образа.

В ограничениях запрещены рабочие образы с тегом latest, отсутствие лимитов контейнера и пропуск тестового окружения. Автор требует readiness и health checks, сканирование контейнера в CI и документированный откат. Secrets предлагается хранить в специализированном хранилище, а не в исходниках или файлах окружения.

Справочники разделены по платформам CI, Docker, Kubernetes, инфраструктуре и стратегиям выкладки. Есть материалы про автоматизацию релизов, артефакты, feature flags и действия при аварии. Сохраняйте их вместе с SKILL.md, если переносите только этот скилл из коллекции.

Пример первого запроса

Начните так: «Подготовьте pipeline для существующего приложения. Используйте его штатную команду тестов, отделите публикацию образа от выкладки и опишите откат. В рабочее окружение ничего не отправляйте». Такой запрос позволяет проверить конфигурацию без незапланированного выпуска.

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

Мы прочитали основной файл и лицензию MIT; команды подключения и выпуска не запускали. QUICKSTART устанавливает всю коллекцию, а работоспособность в Codex здесь не установлена. Узкие вопросы ресурсов кластера подробнее разбирает Kubernetes Specialist.