Signadot спонсировал этот пост.
Обещание микросервисов дразнит — независимые развертывания, автономия команды и быстрые релизы. Тем не менее, после работы с сотнями инженерных команд я наблюдал поразительный схему: многие растущие организации имеют микросервисные архитектуры, но монолитные процессы высвобождения.
Вот неудобная правда: если ваша команда не может самостоятельно подтолкнуть ни одного изменения микросервиса на производство, у вас на самом деле нет микросервисов. У вас есть распределенный монолит с дополнительной сложностью.
Проблема с партии, о которой никто не говорит
Партия запросов на притяжение, объединенные для постановки и протестирования. Этот процесс приводит к медленным тестам и поздним обратной связи.
Сценарий мучительно знаком. Инженеры разрабатывают код в изоляции, запускают некоторые локальные тесты против макетов, отправляют запрос на привлечение и одобряют его. PR объединен с основной ветвью, где он соединяет десятки других изменений, ожидающих развертывания.
Затем начинается игра ожидания.
Эти изменения накапливаются до тех пор, пока кто -то не вызовет развертывание в общей среде — обычно интеграция или постановка. Комплексные тестовые люксы работают, часто занимая часы. Неизбежно что -то ломается. Но какое изменение сломало его? Это был твой пиар с трех дней назад? Чужой? Взаимодействие между несколькими изменениями?
Эта тайна убийства потребляет часы или дни отладки. Инженеры переворачиваются в код, который они написали несколько дней назад, исправляют проблемы и перезапустите процесс. Этот цикл повторяется в нескольких условиях, пока в конечном итоге изменения не достигнут производства — часто через несколько недель после их написания.
Почему каждая команда заканчивается здесь? Два основных ограничения стимулируют это поведение пакетирования:
- Стоимость и время: Интеграционные тестовые люксы дороги и медленны. Проводя полные тесты для каждого PR на более чем 100 разработчиках могут стоить 500 000 долларов+ в месяц только в течение всего времени CI.
- Нехватка окружающей среды: Большинство команд имеют от двух до трех общих сред, обслуживающих десятки разработчиков. Просто не хватает среды для изолированного тестирования индивидуальных изменений.
Это как водить гоночную машину с парковочным тормозом. Вы инвестировали во всю эту силу и возможности, только чтобы его мешали, казалось бы, неизбежные ограничения.
Реальная стоимость пакетных выпусков
Этот пакетный подход к тестированию и высвобождению несет огромные скрытые затраты:
Хуже всего, этот подход создает порочный цикл. По мере снижения качества выпуска организации добавляют больше среды и больше этапов тестирования, что еще больше замедляет процесс.
Свободный отрывок: тестирование индивидуальных изменений
Очевидное решение для партийного тестирования просто: тестируйте каждое изменение кода индивидуально. Многие команды уже пытаются это использовать высмеиваемые зависимости для тестирования контракта и проверки интеграции.
Макеты хорошо работают для тестирования негативных случаев и условий края, но они создают две критические проблемы: постоянное обслуживание накладных расходов и обратная связь с низкой точки зрения. Каждое изменение услуг требует обновления десятков макетов по кодовым базам. Что еще более важно, издевались над проблемами времени, сбоями сети и тонкими поведенческими различиями, которые возникают в реальных взаимодействиях с обслуживанием.
Таким образом, возникает вопрос: возможно ли проверять каждое изменение кода индивидуально на реальных условиях без непомерных затрат?
Решение песочницы
Индивидуальные запросы на притяжение, протестируемые против живой промежуточной среды. Этот процесс дает быстрые тесты и раннюю обратную связь.
Среда песочницы преобразует это уравнение, обеспечивая легкую изоляцию, которая использует общую живую инфраструктуру. Вместо того, чтобы выбирать между дорогостоящим дублированием полной среды или нереалистичными макетами, песочницы предлагают третий путь.
Вот прорыв: когда вы модифицируете службу A, ваша песочница раскручивает обслуживание только в течение некоторого времени на маршрутизацию на текущие, живые версии услуг B, C и D. Это обеспечивает всестороннее тестирование против новейшей реальности вашей системы, а не несвежими машками или снимками.
Рабочий процесс преобразует:
Ключевое понимание: песочницы становятся платформой для тестирования левого смены. Вместо того, чтобы вмещать различные типы тестов на отдельные фазы, вы запускаете соответствующие тесты для каждого изменения кода против реальных зависимостей. Больше нет постановки узких мест. Больше нельзя отлаживать неудачи в десятках пакетных изменений.
Команда Fintech сократила свое время до производства с девяти дней до менее двух часов, используя этот подход. Время отладки сократилось до нуля, потому что каждый сбой проходит непосредственно к конкретному изолированному изменению кода.
Разрушение привычки
Технические барьеры для индивидуального тестирования изменений упали. Современные инструменты, такие как Signadot, предоставляют среда песочницы без необходимости дублировать инфраструктуру или создавать сложные системы изоляции на месте, экономя команды миллионов затрат на разработку и месяцы инженерных усилий.
Микросервисы пообещали нам независимость, но большинство команд остаются в касканках до партийных выпусков с помощью организационных привычек, а не технических ограничений. Команды, делающие эту смену, поставляются быстрее, с более высоким качеством и более счастливыми инженерами.
Путь вперед ясен. Будет ли ваша команда продолжать делать микросервисы неправильно — или начнет делать их правильно?
Signadot-это платформа для тестирования Kubernetes для микросервисов. Используя Signadot, инженерные команды «сдвигаются налево», чтобы выяснить проблемы раньше и повысить доверие. Узнайте больше новейших из Signadot Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Арджун Айер, генеральный директор Signadot, является опытным экспертом в облачной местной области с глубокой страстью к улучшению опыта разработчика. У Арджуна хвастается более чем 25-летним опытом работы в отрасли, есть богатая история разработки программного обеспечения для интернет-масштаба и … Подробнее от Arjun Iyer
