Прочитать на английском

Поделиться через


Общие сведения о непрерывной интеграции с Xamarin

Непрерывная интеграция — это практика разработки программного обеспечения, в которой автоматическая сборка компилируется и при необходимости тестирует приложение при добавлении или изменении кода разработчиками в репозитории управления версиями проекта. В этой статье рассматриваются общие понятия непрерывной интеграции и некоторые варианты, доступные для непрерывной интеграции с проектами Xamarin.

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

Непрерывная интеграция (CI) избежать таких сложностей путем объединения изменений каждого разработчика в общую базу кода на постоянной основе, как правило, когда любые разработчики проверка изменения в общем репозитории кода проекта. Каждый проверка активирует автоматическую сборку и запускает автоматические тесты, чтобы убедиться, что новый код не нарушает существующий код. Таким образом, CI немедленно отображает ошибки и проблемы и гарантирует, что все члены команды остаются в курсе работы друг друга. Это приводит к согласованности и стабильной базе кода.

Система непрерывной интеграции состоит из двух основных частей:

  • Управление версиями — управление версиями (VC), также называемое управлением версиями или управлением исходным кодом, объединяет весь код проекта в один общий репозиторий и сохраняет полную историю каждого изменения в каждом файле. Этот репозиторий, который часто называется основной ветвью, содержит исходный код, который в конечном итоге будет использоваться для сборки рабочей или выпуска версии приложения. Существует множество открытый код и коммерческих продуктов для этой задачи, которые обычно позволяют командам или отдельным лицам создавать копию кода в вторичных ветвях, где они могут вносить обширные изменения или проводить эксперименты без риска для основной ветви. После проверки изменений в вторичной ветви они затем могут быть объединены в основную ветвь.
  • Сервер непрерывной интеграции — сервер непрерывной интеграции отвечает за сбор всех артефактов проекта (исходный код, изображения, видео, базы данных, автоматизированные тесты и т. д.), компиляцию приложения и выполнение автоматических тестов. Опять же, существует множество открытый код и коммерческих средств сервера CI.

Разработчики обычно имеют рабочую копию одной или нескольких ветвей на рабочих станциях, где изначально выполняется работа. После завершения соответствующего набора работ изменения будут "проверка в" или "зафиксированы" в соответствующей ветви, которая распространяет их на рабочие копии других разработчиков. Это то, как команда гарантирует, что все они работают над одинаковым кодом.

Опять же, при непрерывной интеграции процесс фиксации изменений приводит к тому, что сервер CI создает проект и выполняет автоматические тесты, чтобы проверить правильность исходного кода. Если возникают ошибки сборки или сбои тестирования, сервер CI уведомляет ответственного разработчика (через электронную почту, мгновенные сообщения, Twitter, Растут и т. д.), чтобы он или она могли исправить проблему. (Серверы CI могут даже отказаться от фиксации, если возникают сбои, которые называются "закрытыми проверка".)

На следующей схеме показан этот процесс:

This diagram illustrates this process

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

Тест Центра приложений решает эту конкретную проблему путем тестирования приложений непосредственно на сотни физических устройств. Разработчики пишут автоматизированные тесты принятия, которые позволяют эффективно тестировать пользовательский интерфейс. После отправки этих тестов в Центр приложений сервер CI может автоматически запускать их в рамках процесса CI, как показано на следующей схеме:

Once these tests are uploaded to App Center, the CI server can run them automatically as part of a CI process as shown in this diagram

Компоненты непрерывной интеграции

Существует обширная экосистема коммерческих и открытых средств с открытым исходным кодом, предназначенных для поддержки CI. В этом разделе объясняется несколько наиболее распространенных.

Управление версиями

Azure DevOps и Team Foundation Server

Azure DevOps и Team Foundation Server (TFS) — это средства совместной работы Майкрософт для служб непрерывной сборки интеграции, отслеживания задач, гибкого планирования и создания отчетов и управления версиями. С помощью управления версиями Azure DevOps и TFS могут работать с собственной системой (система управления версиями Team Foundation или TFVC) или с проектами, размещенными на GitHub.

  • Azure DevOps предоставляет службы через облако. Его основное преимущество заключается в том, что он не требует выделенного оборудования или инфраструктуры и может быть доступен из любого места через веб-браузеры и с помощью популярных средств разработки, таких как Visual Studio, что делает его привлекательным для команд, которые географически распределены. Это бесплатно для команд пяти разработчиков или меньше, после чего дополнительные лицензии можно приобрести для размещения растущей команды.
  • TFS предназначен для локальных серверов Windows и осуществляется через локальную сеть или VPN-подключение к этой сети. Его основное преимущество заключается в том, что вы полностью управляете конфигурацией серверов сборки и можете установить любое дополнительное программное обеспечение или службы. TFS имеет бесплатный выпуск Express на уровне входа для небольших команд.

TFS и Azure DevOps тесно интегрированы с Visual Studio и позволяют разработчикам выполнять множество задач управления версиями и CI из одного интегрированного интерфейса разработки. Также доступен подключаемый модуль Team Обозреватель Во всем мире для Eclipse (см. ниже). Visual Studio для Mac доступна предварительная версия TFVC.

Azure DevOps Pipelines имеет прямую поддержку проектов Xamarin, в которых создается определение сборки для каждой платформы, которую вы хотите нацелить (Android, iOS и Windows). Для каждого определения сборки требуется соответствующая лицензия Xamarin. Вы также можете подключить локальный сервер сборки TFS с поддержкой Xamarin к Azure DevOps. С помощью этой установки сборки, которые помещаются в очередь в Azure DevOps, будут делегированы локальному серверу. Дополнительные сведения см. в разделе "Агенты сборки и выпуска". Кроме того, можно использовать другое средство сборки, например Jenkins или Team City.

Полный обзор всех функций управления жизненным циклом приложений (ALM) Visual Studio, Azure DevOps и Team Foundation Server см. в статье DevOps с Xamarin Apps.

Team Explorer Everywhere

Команда Обозреватель Везде обеспечивает возможности Team Foundation Server и Azure DevOps для команд, разрабатываемых за пределами Visual Studio. Это позволяет разработчикам подключаться к командным проектам в локальной среде или в облаке из Eclipse или кроссплатформенного клиента командной строки для ОС X и Linux. Команда Обозреватель Везде предоставляет полный доступ к управлению версиями (включая Git), рабочие элементы и возможности сборки для платформ, отличных от Windows.

Git

Git — это популярное решение управления версиями открытый код, которое изначально было разработано для управления исходным кодом ядра Linux. Это очень быстрая гибкая система, которая популярна в проектах программного обеспечения всех размеров. Он легко масштабируется от отдельных разработчиков с плохим доступом к Интернету к большим командам, охватывающим весь мир. Git также упрощает ветвление, что, в свою очередь, может поощрять параллельные потоки разработки с минимальным риском.

Git может работать полностью через веб-браузеры или клиенты ГРАФИЧЕСКОго интерфейса, работающие в Linux, Mac OSX и Windows. Он является бесплатным для общедоступных репозиториев; для частных репозиториев требуется платный план.

Текущие версии Visual Studio для Windows и Mac обеспечивают встроенную поддержку Git. Корпорация Майкрософт предоставляет скачиваемое расширение для Git для более ранних версий Visual Studio. Как отмечалось выше, Azure DevOps и TFS могут использовать Git для управления версиями вместо TFVC.

Subversion

Subversion (SVN) — это популярная система управления версиями открытый код, которая используется с 2000 года. SVN работает во всех современных версиях OS X, Windows, FreeBSD, Linux и Unix. Visual Studio для Mac имеет встроенную поддержку SVN. Существуют сторонние расширения, которые поддерживают SVN в Visual Studio.

Среды непрерывной интеграции

Настройка среды непрерывной интеграции означает объединение системы управления версиями со службой сборки. Для последнего наиболее распространенные из них:

  • Azure Pipelines — это система сборки Azure DevOps и TFS. Она тесно интегрирована с Visual Studio, что позволяет разработчикам запускать сборки, автоматически выполнять тесты и просматривать результаты.
  • Jenkins — это сервер CI с открытым исходным кодом с богатой экосистемой подключаемых модулей для поддержки всех видов разработки программного обеспечения. Он работает в Windows и Mac OS X. Jenkins не интегрирован с какой-либо конкретной интегрированной интегрированной среды разработки. Вместо этого он настраивается и управляется через веб-интерфейс. Jenkins CI также легко установить и настроить, что делает его привлекательным для небольших команд.

Вы можете использовать TFS/Azure DevOps самостоятельно или использовать Jenkins в сочетании с TFS/Azure DevOps или Git, как описано в следующих разделах.

Azure DevOps и Team Foundation Server

Как описано, Azure DevOps и Team Foundation Server предоставляют службы управления версиями и сборки. Для каждой целевой платформы всегда требуется лицензия Xamarin Business или Enterprise.

С помощью Azure DevOps создается отдельное определение сборки для каждой целевой платформы и введите соответствующую лицензию. После настройки Azure DevOps будет запускать сборки и тесты в облаке. Дополнительные сведения см. в Azure Pipelines .

При использовании Team Foundation Server вы настроите компьютер сборки следующим образом для конкретных целевых платформ:

  • Android и Windows: установите Visual Studio и средства Xamarin (для Android и Windows) и настройте с помощью лицензий Xamarin. Кроме того, необходимо переместить пакет SDK Android в общее расположение на сервере, где агент сборки TFS может найти его. Дополнительные сведения см. в разделе "Настройка TFVC".
  • iOS и Xamarin: установите Visual Studio и средства Xamarin на сервере Windows с соответствующей лицензией. Затем установите Visual Studio для Mac на компьютере Mac OS X с поддержкой сети, который будет служить узлом сборки и создайте окончательный пакет приложения (IPA для iOS, APP для OS X).

На следующей схеме показана эта топология:

This diagram illustrates this topography

Также можно связать локальный сервер TFS с проектом Azure DevOps, чтобы сборки Azure DevOps делегированы на локальный сервер. Дополнительные сведения см. в разделе "Сборка и выпуск агентов".

Azure DevOps и Jenkins

Если вы используете Jenkins для создания приложений, вы можете хранить код в Azure DevOps или Team Foundation Server и продолжать использовать Jenkins для сборок CI. Сборку Jenkins можно активировать при отправке кода в репозиторий Git проекта группы или при проверка кода в TFVC. Дополнительные сведения см. в статье Jenkins с Azure DevOps.

If you use Jenkins to build your apps, you can store your code in Azure DevOps or Team Foundation Server and continue to use Jenkins for your CI builds

Git And Jenkins

Другая распространенная среда CI может быть полностью основана на ОС X. Этот сценарий включает использование Git для управления исходным кодом и Jenkins для сервера сборки. Оба из них выполняются на одном компьютере Mac OS X с установленным Visual Studio для Mac. Это очень похоже на среду Azure DevOps + Jenkins, описанную в предыдущем разделе:

This is very similar to the Azure DevOps + Jenkins environment discussed in the previous section

Важно!

Jenkins не поддерживается корпорацией Майкрософт.