Жизненный цикл разработки: внутренний и внешний контур

Технические ограничения, создавшие разрыв между внутренним и внешним циклами, устраняются как раз вовремя, чтобы объединение этих циклов стало необходимостью для рабочих процессов агентов.

На протяжении всей истории разработки программного обеспечения у большинства из нас существовало четкое разделение жизненного цикла разработки: внутренний и внешний циклы.

Внутренний цикл — это то, чем разработчик занимается изо дня в день. Пишет код, запускает его локально, проверяет работоспособность, итерирует. Это быстро, эффективно и персонализировано. Внешний цикл — это всё, что происходит после отправки изменений. Конвейеры непрерывной интеграции, интеграционные тесты, развертывание на промежуточных серверах и проверка кода. Это всеобъемлющий, но медленный процесс, и на то есть веские причины. Запускать весь набор тестов по каждому нажатию клавиши было бы безумием. Поэтому мы оптимизировали: быстрая обратная связь локально, тщательная проверка позже.

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

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

Такой компромисс имел смысл только тогда, когда у нас не было альтернативы. Теперь модель развивается в единый цикл, где проверка происходит на каждом этапе жизненного цикла разработки программного обеспечения (SDLC).

Ограничение, создавшее два замкнутых цикла, нарушается.

Разделение внутреннего и внешнего циклов никогда не было связано с двумя принципиально разными видами работы. Речь шла об ограничении: невозможно было выполнить всестороннюю проверку достаточно быстро, чтобы она была частью цикла разработки.

Интеграционное тестирование подразумевало запуск сервисов, подготовку баз данных и ожидание загрузки сред. На это уходило от 15 минут до нескольких часов, а не секунд. Поэтому все это было включено в CI-систему.

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

Непрерывная доставка становится практичной для всех.

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

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

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

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

Для агентов быстрая проверка — это критически важное инфраструктурное изменение.

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

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

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

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

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

Что делают агенты в быстрых и комплексных средах?

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

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

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

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

Процесс проверки кода органично вписывается в рабочий процесс.

Вот ещё один элемент внешнего цикла, который схлопывается внутрь: проверка кода.

Проверка кода с помощью ИИ быстро становится стандартом. Но интересное изменение заключается не только в том, что ИИ может проверять код. Дело в том, что проверка становится частью собственного цикла разработки агента, а не отдельным этапом. Агент пишет код, проверяет его в песочнице, проверяет изменения, устраняет проблемы и повторно проверяет. Только после этого он создает запрос на слияние (PR).

К тому моменту, когда разработчик увидит запрос на слияние (PR), если он вообще в нём нуждается, механические проблемы качества уже решены. Запрос на слияние перестаёт быть просто способом проверки работы и становится скорее записью того, что было сделано, как это было проверено и доказательством того, что это работает.

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

Ограничения в области оснастки становятся ограничениями в области деятельности агентов.

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

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

Это меняет приоритеты в инвестировании в инфраструктуру. Вместо создания более сложных конвейеров CI после слияния, выигрышная ставка заключается в предоставлении всесторонней и реалистичной проверки до слияния. Она должна быть достаточно быстрой и дешевой, чтобы агенты могли использовать ее на каждой итерации, а не только при отправке запроса на слияние.

Заключение

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

Внутренний цикл сливается с внешним. Вопрос не в том, происходит ли этот сдвиг, а в том, готовы ли к нему ваши инструменты валидации.