Кто знает, как организован процесс разработки в Яндексе? Интересно следующее, как именно разработчик поднимает проект у себя на локальной машине, чтобы начать работать с кодом? Поднимает ли вообще?
Допустим пришел новый разработчик на проект Яндекс.фотки. По идее он должен вытянуть только код этого проекта из репозитория, чтобы начать с ним работать. Но Яндекс.фотки может зависеть от других сервисов, например от Яндекс.паспорт, чтобы хотя бы залогиниться на Яндекс.фотках. Вот как разработчик это решает? Вытягивает чтоли весь репозиторий яндекса со всеми его сервисами и всё это настраивает?
Или он вытягивает только яндекс.фотки, пишет свой какой-то код и юнит-тесты на него, делает push и все, континиус интегрейшен? Разве не смотрит локально результат своей работы в браузере?
Как вы думаете? Или как бы вы это делали? Если у вас 20 разных сервисов, они как-то друг между другом связаны. Как бы вы поднимали локальную копию проекта? У всех 20 сервисов настраивали бы коннект к бд и еще тонну всяких конфигов, чтобы это всё хотя бы локально заработало?
Как? Поделитесь мыслями. Тоже самое касается любой другой крупной ИТ компании.
Если зависимости представлены интерфейсами, то нет никакой необходимости подтягивать другие проекты - достаточно заглушек. К тому же не всегда возможно привести проект-зависимость в необходимое для тестирования вашего проекта состояние, тогда как заглушка полностью подконтрольна вам. Взаимодействие разных проектов проводится нам этапе интеграционного тестирования. Это совсем отдельная работа.
Дмитрий Макаров: Я знаком с этим всем. Это подходит только для юнит-тестирования. Я же спрашивал, как локально проверить результат в браузере и писать функциональные тесты. Ни что из выше вами перечисленного, в этом вообще никак не поможет.
Я с программированием для веба знаком больше теоретически, но мне понятно, что картинку, которая рендерится в браузере не стоит смешивать с бизнес-кодом сервиса (MVC и все такое). При тестировании интерфейс подменяется роботом, который будет дергать контроллер. А верстальщик пусть проверяет картинку на разных браузер/разных разрешениях на неких тестовых данных, которые для него (верстальщика) абстрактны и не зависят от кода.
И я не понимаю почему TDD, mock, stub и DI не будут работать при тестировании более крупных блоков кода и целых сервисов. Возможно некие конкретные реализации/фреймворки тестирования ограничены в своих возможностях, но не может же такие абстрактные вещи как TDD и DI не работать. Либо я уже начинаю сомневаться в своей компетентности.
Дмитрий Макаров: Да я уже узнал. В яндексе пишут код, загружают его на тестовый сервер и там уже проверяют как это работает в браузере и прогоняют функциональные тесты. Так сделано из-за того что, нужно много всего настраивать, чтобы поднять проект локально.
Если есть какие-то общие сервисы которые используются разными командами, можно развернуть тестовые сервера с тестовыми данными. Остальные команды могут взаимодействовать с тестовыми серверами. Вытягивать код, это врядли, во-первых врядли всем командам будут давать доступы ко всем сервисам, во вторых, поднять чужой сервис на неизвестных тебе технологиях и, с неизвестной архитектурой может быть непростой задачей.
Так я думаю, что в этой сервисной архитектуре, можно же сделать какую-то систему сборки. Есть у нас сервис яндекс.фотки, с зависимостью от яндекс.паспорт, мы вытягиваем репозиторий с проектом яндекс.фотки и собираем сервис, в результате чего, нам доставляются необходимые зависимости для этого сервиса.
Тестовые сервера, для разработки это всё не работает. Там что-то вечно будет падать/не работать/ломаться и работа встанет. Пусть тестовые сервера используются для того, для чего они предназначены.
xfg: то что вы описали не будет работать из-за политик безопасности. Никто не даст вам код от яндекс паспорта, если только вы не разработчких этого сервиса.
Средний
