Signadot спонсировал этот пост.
Если вы разработчик платформ или руководитель разработки, посмотрите на свой текущий конвейер разработки. Ко всему ли относятся одинаково?
Мне кажется, что существует явное несоответствие в том, как мы относимся к различным частям стека.
Когда фронтенд-разработчик отправляет код в ветку функций, такие инструменты, как Vercel или Netlify, немедленно запускают предварительный просмотр развертывания. Это уникальный URL-адрес, изолированный от рабочей среды, по которому можно мгновенно переходить и проверять изменения.
Когда инженеру базы данных необходимо протестировать миграцию схемы, современные платформы, такие как Neon или PlanetScale, позволяют ему разветвлять базу данных. Они получают изолированный клон производственных данных с функцией копирования при записи, который можно разрушить и восстановить, не затрагивая ни одного реального пользователя.
Но что происходит, когда бэкенд-инженер вносит изменения в один микросервис из 50-ти?
Ничего.
В середине нашего облачного стека зияющая дыра. В то время как уровни внешнего интерфейса и данных развивались, охватывая разработку на основе филиалов, уровень внутренних служб застрял в каменном веке общих сред.
Это не просто раздражение. Это основное препятствие, мешающее командам по-настоящему сдвинуться влево.
Слияние для проверки анти-шаблона
В большинстве распределенных архитектур разработчик, работающий над серверной службой, не может реально запустить всю платформу на своем ноутбуке. Это слишком тяжело.
Поэтому они полагаются на модульные тесты и макеты. Но мы все знаем, что насмешки — лжецы. Они не улавливают дрейф контрактов между службами или проблемы с задержкой, которые возникают только в сети.
Чтобы получить реальную проверку, разработчик должен объединить свою ветку с основной магистралью, чтобы ее можно было развернуть в общей промежуточной среде.
Здесь скорость умирает.
- Очередь: Разработчики ждут очереди, чтобы развернуть их на промежуточной стадии.
- Блок: Если один разработчик нарушит промежуточный этап, все будут заблокированы.
- Шум: Тестирование не удалось, но это ваш код, или кто-то еще пять минут назад развернул неверный конфиг в сервисе аутентификации?
Мы нормализовали эту дисфункцию. Мы относимся к постановке как к хрупкому, священному монолиту. Но в эпоху, когда мы хотим выполнять развертывание несколько раз в день, слияние с магистралью только для того, чтобы проверить, работает ли ваш код, является обратным решением. Это похоже на заливку бетона до того, как вы проверили чертежи.
Решение: разветвление служб
Нам нужно перенести опыт Vercel и Neon на серверную часть Kubernetes. Нам нужно разветвление сервисов.
Цель проста. Каждая ветка git должна создавать тестируемую изолированную среду.
Однако физика микросервисов усложняет эту задачу. Вы не можете дублировать кластер со 100+ сервисами для каждого отдельного запроса на включение. Стоимость и время раскрутки будут непомерно высокими.
Решение не в дублировании. Это изоляция.
Представьте себе базовую среду — существующий промежуточный кластер, в котором работают стабильные версии всех ваших сервисов. Когда разработчик вносит изменения в конкретную службу, платформа не должна клонировать кластер. Он должен просто запустить облегченную песочницу, содержащую только измененный сервис.
Умная маршрутизация сделает все остальное:
- Стандартный трафик проходит через стабильную базовую линию.
- Тестовый трафик перехватывается и перенаправляется только в изолированную службу.
- Если изолированной службе необходимо вызвать другие службы, она направляется обратно в стабильную базовую версию. Это дает разработчику возможность использовать полноценную специализированную среду с минимальной нагрузкой на инфраструктуру.
Новая ментальная модель: Git = окружающая среда
Чтобы это работало в больших масштабах, инженерам платформ необходимо предоставить чистую мысленную модель, которая сопоставляет исходный код непосредственно с инфраструктурой.
Вот как выглядит новый стандарт:
- Магистральная (основная) соответствует базовой среде (промежуточной). Это источник истины. Он представляет собой стабильное состояние мира, в котором все службы взаимодействуют должным образом.
- Ветка функций (feat-xyz) соответствует среде песочницы. Это эфемерно. Живет только до тех пор, пока открыт ПР. Он содержит только дельту услуг, которые были изменены в этой конкретной ветке.
Когда разработчик открывает PR, ему не нужно думать о кластерах или пространствах имен. У них просто есть специальная игровая площадка, которая идеально повторяет их филиал.
Святой Грааль: полный виртуальный стек
Когда вы объединяете этот подход ветвления служб с существующими инструментами для внешнего интерфейса и ветвления баз данных, вы открываете нечто мощное: полный виртуальный стек для каждой ветки.
Представьте себе рабочий процесс, в котором разработчик создает ветку, и волшебным образом материализуется полная изолированная среда. У разработчика создается впечатление, что у него есть собственная копия всей инфраструктуры компании.
Сюда входят интерфейсные, серверные службы и схемы баз данных. Все они соответствуют конкретным изменениям кода.
Они могут запустить сквозные интеграционные тесты в своей ветке перед слиянием. Они могут передать URL-адрес менеджеру по продукту для демонстрации этой функции. Они могут безопасно проверять сложные миграции. Это выделенная для их особенности реальность, созданная мгновенно и так же быстро уничтоженная.
Почему это важно: скорость и качество в масштабе
Эта модель меняет парадигму от последовательной блокировки к массовому параллелизму.
- Устраните узкое место: Крупным инженерным группам больше не придется стоять в очереди на этапе подготовки. Вы можете одновременно тестировать 10, 50 или 100 разработчиков и агентов, не наступая друг другу на ногу.
- Истинный сдвиг влево: Интеграционное тестирование происходит во время разработки, а не после слияния. Вы обнаруживаете ошибку, когда ее пишете, а не через три дня, когда промежуточная сборка не удалась.
- Больше качества, быстрее: Когда тестирование легкое и изолированное, люди делают его больше. Мы перестаем бояться развертываний и начинаем относиться к ним как к обыденности.
В результате конвейер доставки программного обеспечения становится значительно быстрее и стабильнее.
Устранение разрыва
Технология, позволяющая это сделать, существует. Схемы доказаны. Пришло время командам платформы прекратить управлять статическими средами и начать управлять динамическими, эфемерными рабочими процессами.
Если вы хотите реализовать этот уровень ветвления сервисов для завершения своей стратегии тестирования, Signadot создан именно для этого. Signadot предоставляет уровень оркестрации, который обеспечивает изоляцию на основе запросов в Kubernetes.
Прекратите слияние для тестирования. Начните ветвление для проверки.
Signadot — это собственная платформа Kubernetes для тестирования микросервисов. Используя Signadot, команды разработчиков «смещают влево» тестирование, чтобы выявить проблемы раньше и повысить уверенность в выпуске. Узнайте больше Последние новости от Signadot ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Арджун Айер, генеральный директор Signadot, — опытный эксперт в области облачных технологий, страстно желающий улучшить опыт разработчиков. Обладая более чем 25-летним опытом работы в отрасли, Арджун имеет богатую историю разработки программного обеспечения для Интернет-масштабов и… Подробнее от Арджуна Айера
