Комментарии 3
Локальный стенд в Docker. Давайте поднимем у себя на машине тестовый стенд из десятка контейнеров. Какие минусы? Это всё тот же локальный стенд. Да, есть единый инструмент, не надо устанавливать разные серверы БД. Но каждому новому члену команды придется настраивать и администрировать его у себя. Не может стартануть твой докер демон — сиди, разбирайся.
Разве не может в большой уважающей себя компании быть выделенной команды, которая бы занималась поддержанием корпоративного докер-репозитория с уже готовыми образами, которые новоприбывшему надо только установить и радоваться?
Привет! Спасибо за комментарий. Ответ - может. Например, у нас есть корпоративный докер-репозиторий и замечательные люди, которые его поддерживают.
Цитированный фрагмент немного про другое. Описан подход, когда каждый разработчик или агент CI генерирует стенды для автотестов на своей собственной машине, и у этого есть свои минусы.
Одно из преимуществ системы, которую мы сделали в Fiji - как раз то, что новоприбывшему человеку для прогона тестов дополнительно нужно поставить только клиент K8s. Пусть немного, но облегчает онбординг ?
Понятно. Наверное, я просто зацепился глазом за формулировки. В контексте становится яснее, к чему вы клоните.
Возможно, мои проблемы ещё не доросли до масштаба ваших, но я всё не могу взять в толк, оправдывает ли себя добавление единицы в стэк, т.е. кубернетеса или иной системы оркестрации. В моей текущей компании мы (на данный момент) используем docker-compose. Коллега также разрабатывает ему на замену докер-образ со всеми службами запущенными внутри, который будет раздаваться через докер-репозиторий.
И сколько я ни кручу в уме эту схему, никак не могу понять, какую существенную пользу мог бы нанести ей кубернетес — ценой усложнения технологического стэка.
Создаём инфраструктуру для интеграционных тестов