Статьи

Непрерывная интеграция: серия Введение

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

В двух словах, Continuous Integration (CI) позволяет ускорить процесс разработки и выпуска, постоянно проверяя хранилище кода на наличие проблем сборки, а также автоматизируя различные процедуры, которые в противном случае вам пришлось бы выполнять самостоятельно.

Прочитав это руководство, вы сможете с нуля настроить автоматический сервер, который обеспечит все перечисленные выше преимущества (плюс еще несколько). В частности, мы рассмотрим:

  1. Теория непрерывной интеграции.
  2. Установка веб-сервера Tomcat Apache. Это будет использоваться для запуска программного обеспечения CI.
  3. Установка Гудзона. Это программное обеспечение CI, которое будет контролировать хранилище и запускать
    строить.
  4. Написание сценария сборки bash. Мы пройдемся по основам Bash и тому, как скомпилировать наш проект Xcode из командной строки.
  5. Расширение сценария сборки различными способами, включая автоматическое развертывание.

Хотя мы подробно расскажем обо всех аспектах настройки вашего CI, предполагается, что вы не обладаете предварительными знаниями по администрированию сервера, сценариям bash или процедурам CI. При этом ожидается, что вы в общих чертах разбираетесь в Xcode и сборках архивирования, а также в том, что понимаете (и имеете доступ) сервер управления версиями.

Если вы еще не в той точке, где вы используете систему управления версиями, такую ​​как Git или SVN, для управления вашим кодом, это руководство будет немного за пределами вашей зоны комфорта. Чтобы узнать об управлении исходным кодом и о том, как оно может принести вам пользу, я настоятельно рекомендую зарегистрироваться в GitHub . Они предлагают бесплатные общедоступные репозитории и имеют большое руководство для новых пользователей о том, как настроить и использовать Git в качестве VCS.


  1. Непрерывная интеграция: серия Введение
  2. Непрерывная интеграция: установка Tomcat
  3. Непрерывная интеграция: установка Hudson
  4. Непрерывная интеграция: создание сценариев для Xcode
  5. Непрерывная интеграция: улучшения скриптов

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

Помимо работы с конфликтами, создание приложений вручную для тестирования или распространения на предприятии может занять значительное время. Кто-то должен нести ответственность за поддержание своего хранилища в актуальном состоянии, управление сертификатами разработчика и предоставлением профилей, архивирование кода и выгрузка файла IPA на сервер для распространения.

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

CI позволяет автоматически запускать сборки после каждой фиксации в хранилище. Это позволяет легко и быстро идентифицировать и разрешать ошибки в коде и конфликты. Хотя это полезно, безусловно, самая полезная функция, которую мы можем получить при настройке CI-сервера, — это автоматизация и распространение наших сборок. Представьте, что все, что вам нужно было сделать, это набрать svn commit -m "Fixed the customer ID bug" и через 30 секунд сборка находилась на веб-сайте, ожидая загрузки тестером. Настройка CI может сделать это!


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


Если сборка прошла успешно, команда получает уведомление об успешной сборке. Если сборка не удалась, команда получает уведомление о:

  • Кто в команде сломал сборку
  • Какие изменения привели к поломке сборки

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


  • Проблемы со сборкой выявляются рано.
  • Выявленные проблемы обычно представляют собой небольшие проблемы, которые легко решить.
  • Автоматизированное создание, подписание и распространение приложения экономит время.
  • Постоянный доступ к «последней» сборке для тестеров.
  • Модульные тесты можно запускать на каждой сборке, что позволяет разработчикам обнаруживать как функциональные проблемы, так и ошибки компиляции.

Модульное тестирование — это мир сам по себе, и, к сожалению, не будет рассмотрено в этом руководстве. Я рекомендую вам прочитать об использовании модульных тестов не только как часть вашего CI, но и как часть вашего процесса разработки.


CI, конечно, не для всех. Настройка сервера под ваши нужды может занять значительное время. Программное обеспечение CI-сервера лучше всего устанавливать и устанавливать на отдельном компьютере, который используется для разработки и требований к оборудованию. Это означает дополнительные расходы на оборудование.


В следующей статье мы запачкаем руки при настройке веб-сервера Tomcat. Мы рассмотрим системные требования, как установить и запустить / остановить сервер. Увидимся в следующий раз!