Dev Easy Notes

Варианты, как ускорить пайплайны.

Ладно, продолжим по CI. Переходим к более практическим темам.

Для начала отвечаем на вопрос: какие пайплайны нужно ускорять? Когда мы говорим про оптимизацию пайплайнов, мы пытаемся сократить именно время разработчика, оно самое дорогое. Поэтому в первую очередь ускоряем пайплайны на MR, т.к только они блочат разрабов.

При этом первый вариант, который нужно рассмотреть для ускорения пайплайнов, — тупо купить лучшее железо для Runner и увеличить число самих Runner'ов. Это будет один из самых дешёвых вариантов. Если же вы уже упёрлись в железо, вот только тогда на сцену выходят они:

👉 Предпочитаем CLI вместо Gradle. Упоминал про это тут. Суть в том, что мы часто делаем через Gradle вещи, которые можно написать в 10 строк кода на Python и не тратить время на инициализацию. Поэтому золотое правило: если что-то можно делать без Gradle, лучше делать без Gradle.

👉 Параллелизация (динамические пайплайны). Упоминал этот вариант ещё в посте про тесты на CI. Мы можем ускориться, запуская тесты не в одной job, а, например, в трёх, которые будут выполняться параллельно. Да, потребляем больше runner’ов, но повышаем скорость пайплайна. Можно делать фиксированное количество job, а можно использовать динамические пайплайны, чтобы количество job зависело ещё и от количества тестов.

👉 Импакт-анализ. Работает только в больших проектах с множеством модулей. Зачем нам запускать линтер на весь код проекта, если мы изменили только один модуль? Запускаем линтеры и тесты только на изменённых модулях.

👉 Уносим дичь вне CI. Часто в пайплайны запихивают то, что там не должно быть. Писал про это у себя в посте про проебы. Всякие аналитики, оповещения об ошибках, сбор статистики — уносите во внешние системы. У всех CI есть вебхуки, завязывайтесь на них.

👉 Специфика GitLab CI. В GitLab CI есть два варианта, как задать зависимости между job: dependencies и needs. Работают они по-разному. dependencies ждёт не просто указанную job, а вообще весь предыдущий stage. Из-за чего вы могли уже запустить какой-нибудь linter, но ждёте весь stage с билдом. needs же игнорирует предыдущий stage и запускает job сразу, как только закончила выполняться зависимая job. Поэтому предпочитайте needs, а не dependencies в пайплайнах.

❤14👍4🔥2

www.tgoop.com/dev_easy_notes/452

2.12K viewsedited  Jun 11 at 09:06

Варианты, как ускорить пайплайны.

Ладно, продолжим по CI. Переходим к более практическим темам.

Для начала отвечаем на вопрос: какие пайплайны нужно ускорять? Когда мы говорим про оптимизацию пайплайнов, мы пытаемся сократить именно время разработчика, оно самое дорогое. Поэтому в первую очередь ускоряем пайплайны на MR, т.к только они блочат разрабов.

При этом первый вариант, который нужно рассмотреть для ускорения пайплайнов, — тупо купить лучшее железо для Runner и увеличить число самих Runner'ов. Это будет один из самых дешёвых вариантов. Если же вы уже упёрлись в железо, вот только тогда на сцену выходят они:

👉 Предпочитаем CLI вместо Gradle. Упоминал про это тут. Суть в том, что мы часто делаем через Gradle вещи, которые можно написать в 10 строк кода на Python и не тратить время на инициализацию. Поэтому золотое правило: если что-то можно делать без Gradle, лучше делать без Gradle.

👉 Параллелизация (динамические пайплайны). Упоминал этот вариант ещё в посте про тесты на CI. Мы можем ускориться, запуская тесты не в одной job, а, например, в трёх, которые будут выполняться параллельно. Да, потребляем больше runner’ов, но повышаем скорость пайплайна. Можно делать фиксированное количество job, а можно использовать динамические пайплайны, чтобы количество job зависело ещё и от количества тестов.

👉 Импакт-анализ. Работает только в больших проектах с множеством модулей. Зачем нам запускать линтер на весь код проекта, если мы изменили только один модуль? Запускаем линтеры и тесты только на изменённых модулях.

👉 Уносим дичь вне CI. Часто в пайплайны запихивают то, что там не должно быть. Писал про это у себя в посте про проебы. Всякие аналитики, оповещения об ошибках, сбор статистики — уносите во внешние системы. У всех CI есть вебхуки, завязывайтесь на них.

👉 Специфика GitLab CI. В GitLab CI есть два варианта, как задать зависимости между job: dependencies и needs. Работают они по-разному. dependencies ждёт не просто указанную job, а вообще весь предыдущий stage. Из-за чего вы могли уже запустить какой-нибудь linter, но ждёте весь stage с билдом. needs же игнорирует предыдущий stage и запускает job сразу, как только закончила выполняться зависимая job. Поэтому предпочитайте needs, а не dependencies в пайплайнах.

BY Dev Easy Notes