🔥

Тред #10


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

Такая система будет работать на доверии, а это значит, что вероятность ситуации, когда разработчик "забудет" прогнать тесты перед созданием запроса будет возрастать с каждым новым тестом. Да и как уследить за тем, прогнаны ди все тесты, был ли результат выполнения положительным?

Отсюда, мы приходим к мысли, что такие проверки должны выполняться централизовано и для всех запросов на слияние с основной веткой. Таким образом, мы сможем точно понять был ли вариант выполнения успешным и были ли выполнены все необходимые тестовые сценарии.

Таким централизованным местом выполнения могут стать, опять же, локальные машины разработчиков. При наличии некоторого координатора, вы сможете подключить все ваши машины в единую сеть агентов, которые будут выполнять задачи пришедшие от координатора.

Примером такого координатора может служить 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…