PHP8 + XDebug

[MiksIr]

Тут скорее вопрос - а вы что, без системы сборки живете? А если с ней, то с чего вопрос, наверняка там кеш в ранерах как-то парой команд включается. Хотя понятно, что у всех разные вводные, у меня лишняя минута на сборке релиза - это прям радость. Там минута, там минута - глядишь, еще один релиз в рабочий день впихнуть удалось

 

[флоппик]

Тут скорее вопрос - а вы что, без системы сборки живете? А если с ней, то с чего вопрос, наверняка там кеш в ранерах как-то парой команд включается. Хотя понятно, что у всех разные вводные, у меня лишняя минута на сборке релиза - это прям радость. Там минута, там минута - глядишь, еще один релиз в рабочий день впихнуть удалось

Ну вот и я об этом.

 

[grigori]

скажем так, запуск докера - несколько минут,
mysql стартует тоже несколько минут, просто стартует сервис,
запуск PHPStorm с индексацией проекта - несколько минут,
в прошлом проекте у меня symfony DI-контейнер компилировался несколько минут на каждой сборке,
и говорить про лишний релиз на экономии одной минуты при билде - да кому вы сказки рассказываете

С PHP CI нужен только чтобы прогнать тесты перед выкладкой, а вот прогнать тесты занимает уже не пару минут, когда их хотя бы пару тысяч.
Если лишняя минута на сборке влияет на релиз - значит, у вас тестов немного. Если тестов мало, ваша сборка - чисто для фана.
А если у вас все очень красиво, маленькие сервисы, большая команда, и очередь сборок разных сервисов - добавьте сервер, распараллельте.

 

[MiksIr]

Минута не решает, конечно, но в разных местах экономией копеек можно 10-15 минут экономить, а это уже +1 деплой.
И тесты, которые ранятся более 3-х мину - триггер команде думать, как их распараллеливать.

 

[grigori]

так-то да

 

[Крот]

Минута не решает, конечно, но в разных местах экономией копеек можно 10-15 минут экономить, а это уже +1 деплой.
И тесты, которые ранятся более 3-х мину - триггер команде думать, как их распараллеливать.

О, про распараллеливание интересная тема. Кто-нибудь гоняет в докерах интеграционные тесты (с загрузкой фикстур в БД, с созданием фейковых http серверов для апишек, которые бы отвечали то, что им скажут и т.д.)? Кто-нибудь пытался это ускорить и к чему пришли?

 

[MiksIr]

О, про распараллеливание интересная тема. Кто-нибудь гоняет в докерах интеграционные тесты (с загрузкой фикстур в БД, с созданием фейковых http серверов для апишек, которые бы отвечали то, что им скажут и т.д.)? Кто-нибудь пытался это ускорить и к чему пришли?

Слишком абстрактно. Концептуально проблем нет, а на практике - да, там могут быть проблемы из-за ошибок написания параллельных тестов, но как бы это решается и кучей способов. У нас параллельные функциональные просто идут в разных джобах на разных базах.

 

[grigori]

если уже попробовали разные способы распараллеливать, никак не получилось, и пришли сюда спросить совета, можно еще почитать документацию https://codeception.com/docs/12-ParallelExecution

 

[fixxxer]

Распараллеливание это технически несложно, тут скорее нужна аккуратность и внимательность.

Куда большая проблема - это автоматически поднять и протестировать сервисы в нужной комбинации. Например, пилится фича, затрагивающая несколько сервисов, и надо протестить все комбинации - и с кодом новой фичи, и обратную совместимость, если придется откатить один из сервисов. То есть прогнать интеграционные тесты на все комбинации "master" + "feature/foo".

 

[grigori]

@fixxxer это вопрос SDLC, а не тестов. В какой ситуации тебе понадобилось автоматизировать приемочные тесты на несколько версий по нескольким сервисам? У тебя необычный CI без CD.

Если у тебя CD, или даже ручной релиз, но раз в неделю или чаще - спокойно релизишь новые версии сервисов по одному за раз. Вылезла регрессия - откатываешь конкретный сервис, исправляешь, и продолжаешь.
И тут уже второй вопрос - что за регрессия может вылезти в проде, которую не отловили на stage? Обычно только архитектурные проблемы, когда система ложится под нагрузкой, упершись в железо. Тут никакие комбинации не спасут.

Если у тебя release cycle раз в пол-года - у тебя есть команда тестировщиков и ops-ы с blue-green deployment, версия постепенно раскатывается по pod-ам, и если что-то серьезно поломано, то дальше релиз просто не накатывается. Бери лог и разбирайся.

Ситуация, когда тебе надо, как акробату на канате, жонглировать несколькими сервисами в нескольких версиях - это что-то новое.

 

[fixxxer]

Да банальная ситуация - пилится крупная фича с большим рефакторингом, есть две долгоживущие (2-3 недели) фичеветки в двух сервисах, которые взаимосвязаны и будут выкатываться вместе. Release cycle - роллинг, хоть каждый день. Даже если не говорить о тестах, банально переключать стейдж постоянно туда-сюда несколько напряжно, люди блокируют друг друга.

В итоге придумали мультистейджинг - выкатывается сколько угодно staging сред, триггерится этаким метарепозиторием, в котором имя ветки мапится на k8s namespace.