Почему As Code — это не просто тренд, а новая реальность разработки

В статье Максим Морев расскажет, что такое подход As Code, как он развивался и почему он нужен компаниям.

058 открытий118 показов

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

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

Максим Морев

Начальник департамента инженерной экспертизы и инструментов разработки

С чего все началось

На одном митапе по стандарту разработки нам с Head of Profession задали вопросы, которые зависли в воздухе, как нерешенный баг в коде: «А что за потребность все делать с помощью As Code? Какая от этого польза? Зачем число коммитящих в код?»

Мы, как архитекторы инженерной культуры, внедряем лучшие практики и подходы: Infrastructure as Code, API First, unit-тесты, компонентное тестирование, TBD (Trunk Based Development), GitOps, Doc As Cod. Мы дорабатываем пайплайны, как инженеры, собирающие сеть в подвале старого дата-центра. Мы создаем условия для Continuous Deployment с продуктовыми платформами, где blue-green deployment и canary deployment становятся порталами для перехода прода из одного состояния в другое.

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

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

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

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

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

1. Автоматизация и стандартизация. В 1990-х годах с развитием DevOps и agile-методологий возникла потребность в автоматизации процессов разработки и управления инфраструктурой. Новые задачи стали основой для появления подходов, где все описывается в виде кода.
2. Распространение систем контроля версий. В 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 де-факто стал стандартом для контроля версий, который используют разработчики по всему миру.

Основные подходы 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-модель помогает разработчикам и архитекторам лучше понимать сложные системы.

Хотя конкретные компании редко публично афишируют использование 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

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

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

Footnotes:

• Everything as Code Explained

• Write the Docs Guide: Docs as Code

• Understanding Docs as Code

• The Origins of Infrastructure as Code

• Canary Deployment Strategies

• AWS Whitepaper: Blue-Green Deployments