Не так давно на внутреннем митапе по стандарту разработки прозвучал провокационный вопрос, который заставил задуматься многих, особенно Максима Морева, куратора инженерного производства в нашем банке:
А что за потребность всё делать %-as-code? Какая от этого польза? Зачем число коммитящих в код?
«Потому что иначе мы останемся в прошлом, где ручные процессы замедляют каждый наш шаг», — ответил Макс.
Концепция As Code — естественное продолжение эволюции разработки, где всё — от инфраструктуры до документации — становится кодом. Такой подход превращает хаос в управляемую систему.
Каждый коммит — это шаг в будущее, а код — нить в живой ткани реальности.
Основные подходы As Code:
⭕️ Infrastructure as Code (IaC)
Что это: описание инфраструктуры (серверов, сетей, БД) в виде кода (с помощью Terraform, Ansible, CloudFormation).
Зачем: чтобы инфраструктура была воспроизводимой, предсказуемой и управляемой.
Пример: вместо ручного создания серверов в облаке — код, который разворачивает их одной командой.
⭕️ Documentation as Code (Doc as Code) см. пост выше
Что это: написание документации в формате Markdown/AsciiDoc и хранение в Git.
Зачем: чтобы документация не устаревала и была частью процесса разработки.
Пример: документация API лежит в репозитории рядом с кодом и обновляется вместе с ним.
⭕️ Architecture as Code (AaC)
Что это: описание архитектуры системы в виде кода (например, с помощью DSL — Domain Specific Language).
Зачем: чтобы архитектура была понятной, проверяемой и легко изменяемой.
Пример: использование инструментов вроде Structurizr или PlantUML для описания диаграмм и зависимостей.
⭕️ Policy as Code (PaC)
Что это: описание правил и политик (безопасности или доступа) в виде кода.
Зачем: чтобы автоматизировать проверку и обеспечить соответствие требованиям.
Пример: использование Open Policy Agent (OPA) для описания политик безопасности.
➡️ Еще больше о концепции в статье Максима