Обновление сертификатов на билд сервере


    Во многих компаниях используют Continuous Integration.
    Например, в Git может быть три ветки: customer, master, test.
    Пуш в customer или test инициирует создание сборки, а также ее доставку на устройства заказчика или тестировщиков.

    Для распространения тестовых сборок на iOS, используются Ad Hoc профайлы. Суть в том, что сборка должна быть подписана профайлом, в котором указан UUID устройств на которых она может быть установлена.

    Процедура добавления/удаления устройства в Ad Hoc профайл требует его пересоздания. После того как профайл обновлен, он должен быть установлен на сборочный нод (компьютер на котором собирается сборка). Обычно процедура обновления профайла выполняется через Xcode, что требует доступ к сборочному ноду через VNC и непосредственного участия человека.

    К счастью, все можно автоматизировать, в том числе и процесс обновления профайлов при запуске сборки.


    Насколько мне известно, есть два способа автоматизировать обновление профайла с использованием Jenkins.

    Храним профайл в репозитории


    1. Скачиваем с Apple Dev Center нужный профайл и кладём в Git как «profiles/customer.mobileprovision».
    2. В настройках сборки в поле Embedded Profile пишем путь «profiles/customer.mobileprovision».
    3. В XCode для соответствующей конфигурации в Build Settings выбираем профайл — None и identity — automatic.


    Обновляем профайл перед сборкой


    Очень хороший человек по имени Matt Thompson (рекомендую его Блог) создал клиент для работы с Apple Dev Center из консоли. Клиент называется Cupertino, написан на Ruby и ставится одной строчкой:
    gem install cupertino
    

    Теперь можно не класть «profiles/customer.mobileprovision» в Git, а вместо этого прописать в bash скрипте что-то вроде:
    rm -rf profiles
    mkdir profiles
    update_cert "TestCert" profiles/customer.mobileprovision
    

    Аналогично предыдущему способу, надо в XCode для соответствующей конфигурации в Build Settings выбрать профайл — None и identity — automatic.

    Скрипт update_cert выглядит так:
    #!/bin/bash
    
    if [ ! $# == 2 ]; then
    	echo "Usage: $0 (certificate name) (file name)"
    	exit
    fi
     
    cert_name=$1
    new_file_name=$2
    
    res=`ios profiles:download "${cert_name}" --username some_user_name --password some_password --team some_team_name -type distribution`
     
    if [ $? -gt 0 ]; then
        echo "ERROR!"
        exit
    fi
    
    echo "$res"
    file_name=$(echo "$res" | cut -d"'" -f 2)
    
    mv "${file_name}" "${new_file_name}"
    

    Можно обойтись без update_cert, но в этом случае имя скаченного сертификата будет таким же как и в Apple Dev Center.

    Очевидно, что скрипты можно доработать под свои нужды. Например, в случае, если нельзя скачать сертификат (проблема с сетью), то использовать имеющийся и прочее.

    Заключение


    Автообновление профайлов — это просто и удобно.
    Используйте на здоровье.
    e-Legion
    123,00
    Лидер мобильной разработки в России
    Поделиться публикацией

    Похожие публикации

    Комментарии 6

      +1
      ооо! неужели это избавит нас от гемороя с провизионин профалайлом раз и навсегда. Пошел пробовать.
        0
        Для распространения (inhouse) тестовых сборок на iOS в компаниях используется enterprise distribution provision — приложения подписанные им ставятся на любые девайсы. Неужели заморочки с тестированием на девелоперском аккаунте которые вы описали выше, обошлись вам дешевле чем 299 в год? Не говоря уже о том, что 100 девайсов очень быстро (для большой компании моментально) кончаются.
          0
          Для компании, которая занимается разработкой ПО — 100 девайсов достаточно.
          Другое дело, это распространение корпоративных приложений внутри компании. В этом случае 100 девайсов мало, но для этого и был придуман inhouse.

          Использование Ad Hoc в отличие от Inhouse является предпочтительнее, так как есть точный список устройств, на которых может быть установлено приложение. Таким образом уменьшается вероятность нарушения NDA (нет риска, что приложение поставят неизвестные люди).
            0
            Ну достаточно или нет, это зависит от размеров компании — у некоторых разработчиков даже просто больше, не говоря уже о тестерах, менеджерах, маркетологов и прочего стафа.

            Плюс путаница в терминологии, и в том и в том случае используется Ad Hoc Provisioning Profiles сгенерированные с помощью distribution сертификата — разница только в типа аккаунта.

            Замечание про секьюрность верное — это каждый для себя выбирает.

              0
              Сомневаюсь, что существует много компаний с сотней iOS разработчиков. Может быть Google или Яндекс, но это уже другой уровень.

              Путаницы в терминологии нет.
              Ad Hoc это не более 100 устройств и в сертификате присуствует список UDID.

              Потвреждения:
              1. Beta Testing Your iOS App
              2. В интерфейсе xCode есть строчка «Save for Enterprise or Ad Hoc Deployment».
              3. На сайте Apple можно найти «Ad Hoc Distribution
              With Ad Hoc distribution, you can share your app with up to 100 iOS devices via email or your server.»

              Без сомнений, в обоих случае нужно создавать Provisioning Profile. От него в мире iOS никуда не деться.

              Понятия «distribution сертификат» которое вы использовали, нет.
                +1
                Ну так приложения ставят не только разработчики, клиенты просят добавить их юдиды, менеджеры, тестировщики и т.д. Если компания занимается аутсорсингом, и ведет 5-6 проектов одновременно, этой 100 может очень быстро не хватить.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое