Інфраструктура автотестів та її нюанси

GitHub і GitLab називають виконавців jobs runners, Jenkins — agents. Хмарні runners зручні, але в приватних організаціях хвилини виконання можуть тарифікуватися. Self-hosted runner працює всередині інфраструктури компанії, дає більше контролю над ресурсами й доступами та часто зменшує операційну вартість регулярних прогонів.

Один репозиторій запускається локально й у CI проти dev, preprod або інших середовищ. Сервіси можуть залежати від баз даних і зовнішніх third-party систем, інколи спільних для кількох середовищ. Локальний ноутбук часто отримує доступ до закритої мережі лише через VPN, тому той самий маршрут не можна автоматично перенести на hosted runner.

Відкривати приватне середовище для широкого діапазону IP хмарного CI дорого в підтримці й збільшує поверхню атаки. Практичніший варіант — runner усередині контрольованої мережі: GitHub або GitLab передає йому job, а сам runner уже має потрібний маршрут до тестової інфраструктури. Доступ усе одно обмежують мережевими правилами й мінімальними правами конкретного runner.

Runner клонує репозиторій, встановлює або використовує залежності та запускає тестовий процес. UI-тести додатково піднімають один чи кілька браузерів; навіть headless browser споживає відчутну кількість RAM. Розмір runner слід визначати за реальною паралельністю, наборами браузерів і піковим споживанням, а не за вимогами звичайного application build.

Публічніше середовище може бути захищене authentication gateway, rate limits і load balancer замість VPN. Gateway приймає зовнішній трафік і маршрутизує його до потрібного сервісу; load balancer розподіляє запити між копіями. Під час проєктування тестів треба знати, які середовища ділять third-party інстанс і де саме застосовуються мережеві та частотні обмеження.