> ## Content Index
> Fetch the complete content index at: https://admin.kod.ru/llms.txt
> Use this file to discover other available public pages before exploring further.

# Почему As Code — это не просто тренд, а новая реальность разработки
- URL: https://admin.kod.ru/as-code-new-dev-reality/
- Published: 2025-07-02T12:43:55.000Z
- Updated: 2025-07-02T12:44:31.000Z
- Description: Практический взгляд на культуру As Code в масштабах крупной IT-компании.
- Author: Газпромбанк
- Tags: Блоги

В IT-командах часто происходит одно и то же: правила, договоренности, решения живут отдельно от кода — в чатах, документах, в головах людей. 

Кто-то пишет тесты одним образом, кто-то иначе. Один деплоит в ручном режиме, другой автоматизировал на коленке в обход всех процессов. Со временем все это превращается в такой хаос, что проще снести и написать с нуля.

Хаос необходимо упорядочить — и тут на помощь приходит As Code. Это не просто методология, а философия, где все — от инфраструктуры до документации и политик безопасности — становится кодом. В этой статье я расскажу, почему подход As Code стал критически важен для современных IT-компаний и как он эволюционировал.

![](https://admin.kod.ru/content/images/2025/07/-----.png)

На одном митапе по стандарту разработки нам с Head of Profession задали вопросы, которые зависли в воздухе, как нерешенный баг в коде: 

> «А что за потребность все делать с помощью As Code? Какая от этого польза? Зачем число коммитящих в код?»

Мы, как архитекторы инженерной культуры, внедряем лучшие практики и подходы: **Infrastructure as Code**, **API First**, **unit-тесты**, **компонентное тестирование**, **TBD** (Trunk Based Development), **GitOps**, **Doc As Cod**. Мы дорабатываем пайплайны, как инженеры, собирающие сеть в подвале старого дата-центра. Мы создаем условия для Continuous Deployment с продуктовыми платформами, где [blue-green deployment](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html?ref=admin.kod.ru) и [canary deployment](https://cloud.google.com/deploy/docs/deployment-strategies/canary?ref=admin.kod.ru) становятся порталами для перехода прода из одного состояния в другое.

Каждый коммит — шаг в будущее, где код становится не просто текстом, а нитью в живой ткани новой реальности. Число коммитящих — это не просто метрика, это сигнал, что система жива, дышит, развивается. И когда кто-то спрашивает «Зачем?», я отвечаю: «Потому что иначе мы останемся в прошлом, где ручные процессы, как старые провода, тянут нас назад в тишину, замедляя каждый шаг. Мы строим мир, где As Code не просто слова, код — наша новая реальность. И каждый, кто коммитит, становится частью этой вселенной».

В момент осознания вопроса я провалился на другой слой реальности, задумался об истории As Code и собрал этот текст из разбросанных по сети слепков. Эта статья — не руководство по Terraform или Kubernetes, а скорее практический взгляд на культуру As Code в масштабах крупной IT-компании.

## Эволюция As Code: от истоков до современности

Концепция As Code возникла как ответ на ключевые вызовы IT-индустрии: рост сложности систем и ускорение темпов изменений. Она был естественным продолжением эволюции разработки — код стал не только инструментом создания программ, но и способом управления инфраструктурой, документацией, архитектурой и политиками.

**У появления этого подхода было несколько предпосылок:**

1. **Автоматизация и стандартизация.** В 1990-х годах с развитием DevOps и agile-методологий возникла потребность в автоматизации процессов разработки и управления инфраструктурой. Новые задачи стали основой для появления подходов, где все описывается в виде кода.
1. **Распространение систем контроля версий.** В 2005 году появился Git, который стал инструментом для управления изменениями, что позволило хранить и версионировать не только код, но и документацию, конфигурации и архитектуры.

Корнями As Code уходит в 1970-е годы. Ранние инструменты, такие как **Unix “Make”** и **PXE boot**, заложили фундамент для автоматизации конфигураций. Позже они эволюционировали в современные подходы: Infrastructure as Code, Documentation as Code, GitOps и другие. Это подчеркивает, что As Code — не просто тренд, а естественное развитие технологий, которое упрощает управление сложными системами.

## Почему все теперь в Git?

С развитием подхода As Code универсальным инструментом управления изменениями стал Git. Это произошло благодаря нескольким ключевым причинам. 

- **История изменений:** Git хранит всю историю изменений, что позволяет отслеживать, кто, когда и что делал. Это критически важно для анализа и отката ошибок.
- **Коллаборация:** над проектом может работать несколько человек, и они не будут мешать друг другу.
- **Прозрачность:** все изменения видны, их можно обсудить, проверить и улучшить через механизмы pull/merge requests.
- **Автоматизация:** Git интегрируется с CI/CD — Continuous Integration / Continuous Deployment. Это позволяет автоматизировать тестирование, сборку и деплой. Работа в Git позволяет «все иметь под рукой» и упрощает создание систем поддержки и контроль стандартов ИТ-производства.
- **Безопасность:** Git позволяет контролировать доступ к коду и данным через ролевую модель и механизмы проверки изменений.

### Как появился Git?

Git был создан в 2005 году как ответ на кризис в разработке ядра Linux. Ранее команда Linux использовала проприетарную систему контроля версий BitKeeper, но юридические споры лишили программистов этой возможности. Linux-сообщество осталось без инструмента для управления кодом. Существующие системы — например, CVS или Subversion — не подходили для масштабных проектов.

Линус Торвальдс, создатель Linux, решил разработать собственную систему, которая бы отвечала потребностям крупных проектов:

- была быстрой,
- поддерживала распределенную разработку,
- гарантировала сохранность данных (через хеши SHA-1).

Git был создан всего за 10 дней. Первая версия была настолько проста, что Торвальдс называл ее «игрушечной». При этом она уже решала ключевые задачи. Инструмент разработали с **акцентом на децентрализацию**: каждый разработчик имеет полную копию репозитория, что делает процесс гибким и устойчивым.

Создание Git — прекрасный пример проактивной позиции: если тебя что-то не устраивает, ты сам создаешь инструмент для решения задачи. Реагируешь на боль не нытьем, а делом, и оставляешь проблему позади. Этот инструмент родился из необходимости и стал революцией в мире разработки. Простота, скорость и распределенный подход сделали его незаменимым инструментом для команд любого масштаба.

*Эволюция Git:*

- **2005*: первый релиз Git;*
- **2008*: появление GitHub, который популяризировал Git среди разработчиков;*
- **Сейчас*: Git де-факто стал стандартом для контроля версий, который используют разработчики по всему миру.*

![](https://admin.kod.ru/content/images/2025/07/2-.png)

# Основные подходы As Code

## Infrastructure as Code (IaC)

IaC — это описание в виде кода инфраструктуры: серверов, сети баз данных. Например, с помощью Terraform, Ansible, CloudFormation. Инструмент позволяет сделать инфраструктуру воспроизводимой, предсказуемой и легко управляемой. Вместо ручного создания серверов в облаке вы можете описать их в коде и развернуть одной командой.

Когда мы слышим термин Infrastructure as Code, то обычно думаем о современных инструментах, таких как Chef, Ansible или Terraform. Однако сама идея управления инфраструктурой и конфигурациями через код уходит корнями в 1970-е годы. Уже тогда инженеры сталкивались с необходимостью автоматизировать управление парками машин, будь то физические или виртуальные системы.

Одним из первых инструментов, позволявших автоматизировать сборку и настройку программного обеспечения, был **Unix “Make”** (1976). Хотя Make не стал полноценным инструментом управления инфраструктурой, он заложил основы для автоматизации задач конфигурации. Следующим важным шагом к автоматизации стал **PXE boot** (1981). Он позволял загружать и настраивать по сети целые машины — это стало прообразом современных подходов к управлению инфраструктурой.

Хотя эти ранние инструменты не считаются полноценными решениями для управления инфраструктурой, они создали основу для современных подходов. Unix “Make” и PXE boot показали, что автоматизация конфигураций возможна и необходима, особенно с ростом сложности систем. 

**Как дальше складывалась эволюция IaC:**

- **1990-е:** следующий этап развития начался с появлением **CFEngine (1993)**. Это был один из первых инструментов, позволявших управлять конфигурациями на множестве машин.
- **2000-е:** с развитием облачных технологий и DevOps появились более мощные инструменты, такие как **Puppet (2005)** и **Chef (2009)**. Они сделали управление через код отраслевым стандартом.
- **2010-е:** **Ansible (2012)** и **Terraform (2014)** стали лидерами в области IaC. Они предложили более гибкие и мощные решения для управления облачной инфраструктурой.
- **2013:** появился **Docker**, который произвел революцию в контейнеризации. Он обеспечил легкость в создании, развертывании и масштабировании приложений, а также упростил процессы управления инфраструктурой.
- **2014:** **Kubernetes** предложил автоматизацию развертывания, масштабирования и управления контейнизированными приложениями.
- **2017:** создан **Pulumi**, который позволил управлять ресурсами облачной инфраструктуры с использованием таких языков программирования, как Go, JavaScript, TypeScript, Python, Java, C# и YAML. Благодаря этому инструменту разработчики смогли быстрее интегрировать IaC в свои процессы и создавать более сложные сценарии для автоматизации.
- **2021:** появился **Brainboard**, который значительно упростил разработку, визуализацию и управление инфраструктурой как кодом. Он предложил графический интерфейс для создания и изменения архитектуры облаков. Это помогло сделать IaC доступным не только для разработчиков, но и для более широкого круга пользователей, в том числе для аналитиков и проектировщиков.

Эволюция IaC уходит корнями в историю зарождения машин. С тех пор задачи, с которыми мы сталкиваемся, остались прежними — просто мы решаем их через новые слои абстракции, создавая все более сложные и эффективные инструменты для автоматизации инфраструктуры и управления ею.

### Documentation as Code (Docs as Code)

Подход Docs as Code позволяет разрабатывать техническую документацию с помощью тех же инструментов, что и код. Документы создаются в формате, который легко версионировать и хранить в Git, — например, **Markdown** или **AsciiDoc**. 

Это дает значительные преимущества:

- **актуальность** — документация API или архитектуры хранится в репозитории рядом с кодом, благодаря чему всегда остается актуальной;
- **версионирование —** легко отслеживать изменения и возвращаться к предыдущим версиям;
- **интеграция в процесс разработки** — документация становится частью DevOps-практики и развивается в Git вместе с кодом.

Подход Docs as Code начал развиваться в 2000-х годах. В это время крупные компании, такие как Microsoft, начали использовать внутренние инструменты для генерации документации из исходного кода. Например, документация .NET Framework уже создавалась с помощью автоматизированных процессов.

В 2010-х годах термин Docs as Code был популяризирован. Тогда такие инструменты, как Markdown, AsciiDoc и Sphinx, стали широко использовать для создания и управления документацией в репозиториях Git.

### Architecture as Code (AaC)

AaC позволяет описывать архитектуру системы в виде кода — например, с помощью DSL. Благодаря этому она становится понятной, проверяемой и легко изменяемой. С помощью таких инструментов, как Structurizr или PlantUML, можно генерировать архитектуры программного обеспечения в коде, чтобы интегрировать их в процессы разработки.

Подход Architecture as Code начал развиваться в 2010-х годах с появлением **Structurizr** (2014) и других инструментов. Сегодня AaC используют для описания в формате, который можно версионировать и тестировать. Например, [C4-модель](https://c4model.com/?ref=admin.kod.ru) помогает разработчикам и архитекторам лучше понимать сложные системы.

Хотя конкретные компании редко публично афишируют использование C4-модели или Aac, есть несколько примеров, где эти подходы активно применяются.

**Крупные технологические компании**

- **Microsoft** использует C4-модель, чтобы документировать архитектуры своих облачных сервисов, таких как, допустим, Azure. Подход AaC помогает автоматизировать создание диаграмм и поддерживать документацию в актуальном состоянии.
- Внутренние команды **Amazon Web Services** используют C4-модели для описания архитектуры своих сервисов, а инструменты AaC помогают интегрировать эти описания в CI/CD-процессы.

**Финансовые организации**

- Многие банки и финтех-компании используют C4-модели, чтобы документировать сложные распределенные системы. Например, **ING** и **Goldman Sachs** применяют AaC для автоматизации создания архитектурных диаграмм и проверки соответствия стандартам.

**Консалтинговые и IT-компании**

- Разработчик и поставщик программного обеспечения **ThoughtWorks** активно продвигает использование C4-модели и подхода Architecture as Code в своих проектах. Компания создает инструменты и практики для интеграции AaC в процессы разработки.
- Производитель программного обеспечения **Red Hat** использует C4-модели для документирования архитектуры своих решений, таких как OpenShift, и применяет AaC для автоматизации создания диаграмм.
- Также активно использует и применяет C4-модели **X5 Tech** — основной цифровой партнер торговых сетей и бизнесов X5 Group.

### Policy as Code

Этот подход позволяет описывать политики и управлять ими, например безопасностью или доступом. Policy as Code дает возможность автоматизировать проверку на всех этапах жизненного цикла ПО и обеспечить compliance — соответствие требованиям.

Подход Policy as Code стал популярным с появлением таких инструментов, как **Open Policy Agent (OPA)** и **Hashicorp Sentinel**. Они позволили описывать политики безопасности и compliance в виде кода, что стало особенно востребованным в облачных средах.

### GitOps

GitOps — подход, в котором Git становится единым источником истины для управления инфраструктурой и приложениями. Они описываются в коде — например, с помощью Kubernetes manifests — а все изменения автоматически применяются через CI/CD.

Концепцию GitOps в 2017 году формализовала компания Weaveworks, этот подход дает несколько преимуществ:

- **прозрачность** — все изменения видны в Git;
- **автоматизация** — процессы деплоя и обновления автоматизированы;
- **безопасность** — изменения проходят код-ревью и тестирование.

### GitSecOps

GitSecOps — расширение GitOps с акцентом на безопасность, которое стало развиваться в 2020-х годах. С помощью этого инструмента можно интегрировать безопасность в процесс разработки и эксплуатации через код, он позволяет внедрить в CI/CD инструменты статического анализа кода (SAST) и анализа зависимостей (SCA).

Преимущества этого подхода:

- **раннее выявление уязвимостей**;
- **автоматизация проверок безопасности**;
- **соответствие стандартам** — например, GDPR или HIPAA.

## Будущее с As Code

Мы постепенно внедряем лучшие практики и шаг за шагом приближаемся к моменту, когда актуальность инженерной культуры будет соответствовать состоянию мастер-системы, которая тем временем бежит вперед, — и я вижу в пространстве новые коммиты актуальной реальности.

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

---

**Сноски:**

- [Everything as Code Explained](https://hackernoon.com/everything-as-code-explained-0ibg32a3?ref=admin.kod.ru)
- [Write the Docs Guide: Docs as Code](https://www.writethedocs.org/guide/docs-as-code/?ref=admin.kod.ru)
- [Understanding Docs as Code](https://medium.com/@EjiroOnose/understanding-docs-as-code-01b8c7644e23?ref=admin.kod.ru)
- [The Origins of Infrastructure as Code](https://medium.com/@mike%5Ftyson%5Fcloud/the-origins-of-infrastructure-as-code-a-brief-history-of-devops-a883d8877f19?ref=admin.kod.ru)
- [Canary Deployment Strategies](https://cloud.google.com/deploy/docs/deployment-strategies/canary?ref=admin.kod.ru)
- [AWS Whitepaper: Blue-Green Deployments](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html?ref=admin.kod.ru)