Одним из первых вопросов на которые нужно будет ответить – это где выполнять тестовые сценарии. Конечно, вы можете согласиться на том, что каждый разработчик будет запускать тесты на своей локальной машине, перед тем как создать запрос на слияние с основной веткой.
Такая система будет работать на доверии, а это значит, что вероятность ситуации, когда разработчик "забудет" прогнать тесты перед созданием запроса будет возрастать с каждым новым тестом. Да и как уследить за тем, прогнаны ди все тесты, был ли результат выполнения положительным?
Отсюда, мы приходим к мысли, что такие проверки должны выполняться централизовано и для всех запросов на слияние с основной веткой. Таким образом, мы сможем точно понять был ли вариант выполнения успешным и были ли выполнены все необходимые тестовые сценарии.
Таким централизованным местом выполнения могут стать, опять же, локальные машины разработчиков. При наличии некоторого координатора, вы сможете подключить все ваши машины в единую сеть агентов, которые будут выполнять задачи пришедшие от координатора.
Примером такого координатора может служить GitLab Runner (docs.gitlab.com/runner/install/), в случае использования GitLab. Для GitHub вы можете использовать Jenkins или TeamСity, которые предоставят вам возможность регистрации раннеров jetbrains.com/help/teamcity/…
Кстати, вы можете настроить GitLab пайплайны и использовать их в GitHub 🤯
docs.gitlab.com/ee/ci/ci_cd_fo…
Проблем с решением использовать локальные машины давольно много.
Во-первых, к вам на машине может пожаловать запрос на прогон тестов от координатора, что съест давольно большое количество ресурсов и, скорее всего, отправит вас на перерыв со все тем же кофе и пончиком.
Во-вторых, количество активных машин в пулле будет меняться. Разработчики будут включать/выключать машины, а особо пронырливые – вовсе отменять регистрацию своей машины в пулле.
Похоже, вашей компании придется потратить еще какое-то количество денег на покупку новых машин. Но вопрос в том, как потратить эти деньги с умом?
Тут есть, как минимум, 2 варианта: купить физические машины, арендовать машины в облаке.
Покупка физических машин позволит иметь прямой доступ к этим самым машинам, диагностировать возможные проблемы и устранять неполадки, проводить эксперименты и иметь возможно делать выводы по этим экспериментам давольно быстро.
Однако, с покупкой физических машин есть ряд сложностей. Во-первых, их нужно где-то хранить, администрировать, проводить ремонт, замену и докупку машин при увеличении флота. Всем этим нужно кому-то заниматься, а это дополнительные расходы на людей.
Аренда машин в облаке затруднит работу с ними напрямую, так как доступ будет осуществляться через компанию арендодателя, при этом, у вас пропадет ряд вопросов и забот, в том числе с хранением и поддержкой этих самых машин.
Предположим, вы не хотите иметь дело с закупкой и содержанием собственной собственного флота и предпочитаете арендовать уже готовое решение. У вас будет несколько вариантов таких компаний.
При выборе арендодателя, нужно помнить, что Apple разрешает осуществлять сборку, запуск тестов и аналитику под iOS, только на официальном “яблочном” железе.
Такое требование заметно сужает выбор, но варианты все еще остаются. Самыми популярными провайдерами будут MacStadium и AWS.
MacStadium позволит вам запустить hypervisor c несколькими виртуальными машинами на хосте типа MacPro или Mac Mini, это увеличит фактическое количество доступных агентов для запуска тестов и сборки проекта.
Amazon, не так давно, анонсировал запуск macOS образов в своем сервисе AWS.
aws.amazon.com/about-aws/what…
Такое решение позволит создавать герметичное окружение для ваших сборок и тестов, что откроет возможность осуществлять кеширование операций и ускорении времени сборки и теста.
Представим, что вы выбрали один из облачных провайдеров. Давайте перейдем к логике прогона тестовых сценариев на новых машинах.
Продолжение:
twitter.com/mobileunderhoo…