При разработке кода часто необходимо протестировать его перед отправкой в среду разработки или продакшен. Однако ожидание развертывания с помощью GitHub Actions или развертывания стека CDK с помощью CDK отнимает много времени.
Такие трудоемкие задачи снижают скорость итерации, которая является критическим фактором для эффективной разработки кода. Это связано с необходимостью должным образом протестировать каждую реализацию, чтобы убедиться в ее работоспособности. Затем, после каждого изменения, необходимо протестировать ее снова.
С помощью новейших агентов для автоматизации программирования разработка полных скриптов локального тестирования происходит очень быстро, и я делаю это каждый день, когда пишу код как специалист по данным.
В этой статье расскажу, почему вам необходимо создать эффективную настройку локального тестирования, запустив образ Docker и отправив тестовые события. Я также покажу, как я это делаю сам и как это помогает мне стать более эффективным инженером.
В основном буду говорить о том, как работать с инфраструктурой как кодом (IaC — Infrastructure as Code), потому что в основном именно с этим я работаю ежедневно. Однако концепция эффективного запуска кода локально применима ко всему программированию.
Почему нужно запускать код локально
Прежде всего, хочу объяснить, почему нужно запускать код локально. Ответ прост: скорость итерации — один из важнейших аспектов для эффективного внедрения рабочего кода в продакшен.
Чем быстрее вы можете итеративно тестировать свой код, тем лучше. Когда вы разрабатываете новую функциональность (или исправляете старую), вам нужно быстро проверить, работает ли она, а затем итеративно исправлять код, пока он не будет работать так, как задумано.
Если приходится ждать 5–15 минут, пока код развернется, прежде чем тестировать его, у вас серьезная проблема. Если не решить ее, придется всякий раз тратить по 5–15 минут только на ожидание развертывания.
Вместо этого, следует запускать код локально. Например, если вы работаете с IaC, таким как AWS CDK, можете создавать и запускать образы Docker локально, по сути, воспроизводя продакшен, но на своем собственном компьютере. Таким образом, цикл итераций упрощается, а время, необходимое для создания образа Docker и запуска кода, сокращается.
Создание образа Docker обычно происходит очень быстро, учитывая, что Docker кэширует предыдущие сборки. Таким образом, большую часть времени вы, вероятно, тратите на запуск кода с тестовыми входными данными и проверку того, что вывод соответствует ожидаемому.
Если вы работаете над веб-приложением, вам следует (и, вероятно, вы уже это делаете) запускать приложение локально, прежде чем развертывать код. При работе с IaC не должно быть никакой разницы.
Как вести разработку локально, как в продакшен-среде
Важным аспектом при локальной разработке является возможность точно воспроизвести продакшен-среду. При работе с IaC, когда вы собираете Docker-образы и запускаете их на локальной машине, достигается следующий результат.
Вы тестируете точно такой же код, используя те же пути входных данных. Если файл .env на локальной машине зеркалирует продакшен-версию, то все переменные среды также полностью совпадают. Таким образом, локальный запуск Docker-образов является предпочтительным методом, если у вас есть такая возможность.
Создание локальных скриптов с помощью агентов автоматического программирования
До появления таких агентов автопрограммирования, как Cursor и Claude Code, настройка локального запуска кода часто была трудоемкой задачей. Необходимо было корректно собрать Docker-образ, настроить его запуск с файлом .env и выполнить другие конфигурационные шаги. Аналогичные сложности возникали при желании запустить код локально, например, в виде сервера FastAPI.
Однако эта проблема больше не актуальна. Для начала локальной разработки я обычно даю Cursor следующую инструкцию:
Create a shell script for me to run this code locally. The shell script
should run the docker image, and have an optional --build flag, which builds
the docker image before running it. The docker image should load environment
variables from the .env file.
(Создай для меня shell-скрипт для локального запуска этого кода. Скрипт должен запускать Docker-образ и иметь опциональный флаг --build, который собирает Docker-образ перед его запуском. Docker-образ должен загружать переменные среды из файла .env.)Такая инструкция позволит создать эффективный shell-скрипт для использования. Мне нравится опциональный тег —build, поскольку сборка Docker-образа иногда занимает время, и не всегда требуется выполнять ее перед запуском.
Кроме того, следующие советы помогут вам легко запускать скрипт:
- Никогда не храните реальные секреты в файле .env — только ссылки на секреты, которые ваш код затем получит из AWS Secrets Manager. Это позволяет загружать файл .env в репозиторий без риска утечки конфиденциальных данных. Более того, это упрощает запуск скриптов другими разработчиками при клонировании кода с GitHub.
- Создавайте отдельный файл с тестовыми событиями, чтобы легко отправлять события в запущенный Docker-образ. Это позволяет быстро проверять входные и выходные данные.
- Загружайте тестовые скрипты в Git, чтобы они были доступны всем членам команды. Это включает и файл .env, поскольку он не содержит секретов.
Теперь у вас есть полная схема точной настройки, необходимая для локального запуска и тестирования кода. Каждый раз при внесении изменений вы пересобираете Docker-образ и отправляете тестовые события, убеждаясь, что все работает как задумано.
Рекомендую настраивать подобные локальные тестовые скрипты для всех репозиториев и загружать их в Git для общего доступа. Наличие этих скриптов значительно повысит эффективность работы всей команды разработчиков.
Дополнительные советы по локальному запуску
Хочу также поделиться двумя дополнительными рекомендациями для достижения еще большей эффективности с использованием этих локальных тестовых файлов:
- Запускайте и тестируйте Docker-образ с помощью pre-commit хуков.
- Предоставьте вашему агенту автопрограммирования доступ к этим скриптам.
Pre-commit хуки
Pre-commit хуки — это код, который выполняется перед каждым коммитом в Git.
Типичные pre-commit хуки включают:
- запуск black . для форматирования кода;
- запуск mypy для проверки типов;
- запуск тестов pytest для проверки их прохождения.
Наличие pre-commit хука гарантирует, что вы никогда не забудете выполнить эти команды перед отправкой кода. Это невероятно полезно и экономит время. Трудно сосчитать, сколько раз я забывал запустить форматирование через black перед коммитом, и тесты развертывания завершались неудачей через 5 минут, что стоило мне много времени.
Если сборка, запуск и тестирование Docker-образа не занимают слишком много времени, рекомендую добавить эти действия в pre-commit хуки. Это гарантирует перед отправкой любого кода проверку его работы в среде, аналогичной продакшен-среде, и получение ожидаемого результата для заданных входных данных. Реализация этой проверки в качестве pre-commit хука наверняка сэкономит вам значительное количество времени в будущем.
Предоставьте Cursor доступ к тестовым скриптам
Я рекомендую всегда предоставлять Cursor и Claude Code доступ к запуску тестовых скриптов, а затем дать команду Cursor запускать эти скрипты после внесения изменений и перед завершением текущей реализации.
Наличие возможности у вашего агента автопрограммирования запускать и тестировать Docker-образы значительно увеличит процент успешных реализаций с первой попытки.
Вы потратите больше времени, если агент будет реализовывать функцию, а вам затем придется вручную запускать и тестировать Docker-образ. Столкнувшись с ошибкой, вы будете предоставлять ее агенту до тех пор, пока код не заработает.
Это пустая трата времени, и такого следует активно избегать. Предоставление вашему агенту доступа к тестовым скриптам аналогично передаче ему инструмента, который значительно повышает производительность при выполнении инженерных задач. Не могу не подчеркнуть, насколько это экономит время.
Заключение
В этой статье я обсудил, как можно создавать реальные продакшен-среды локально путем написания скриптов для сборки, запуска и тестирования Docker-образов на локальном компьютере. Такой подход сокращает время итераций, что является критически важным компонентом эффективной работы программиста. Кроме того, я рассказал, как применяю это на практике: даю Cursor задание создать тестовые скрипты и примеры событий для запуска на Docker-образе. Затем предоставляю Cursor и Claude Code доступ к выполнению этих скриптов, что делает работу значительно эффективнее.
Убежден, что высокая скорость итераций крайне важна практически для всех задач в разработке программного обеспечения, и к этому следует стремиться. Создание локальных тестовых файлов и предоставление доступа к ним вашему агенту существенно ускоряет цикл разработки. Именно поэтому я считаю, что внедрение этого подхода значительно повысило мою личную продуктивность как программиста.
Читайте также:
- Как мы создавали автоматизированное тестирование с помощью Playwright
- Среда разработчика в монорепозитории Stripe
- 5 крайне непродуктивных моделей поведения владельцев продуктов
Читайте нас в Telegram, VK и Дзен
Перевод статьи Eivind Kjosbakken: How to Increase Coding Iteration Speed
