@house200829 мая 2016 в 17:12

Apple, боль и сертификаты

6 мин

39K

Xcode * iOS *

+24

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

@kozyabka 29 мая 2016 в 19:31

… и никаких релизов в пятницу!

@MonkAlex 29 мая 2016 в 19:51

Именно, кто ж релизит\чекинит вечером пятницы.

@apachik 29 мая 2016 в 21:50

стандартная ios-практика. В пятницу «релизим» (заливаем билд на апрув в аппстор), в понедельник продолжаем тестировать и убеждаемся, что все ок (если не ок, то перезаливаем), в среду берут на ревью, в четверг апрувят и выпускаем юзерам.

Так было раньше. Последний месяц ревью занимает день-два: статистика appreviewtimes

@taviscaron 30 мая 2016 в 05:50

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

кстати, в прошедшую пятницу релиз был на ревью 9 часов (девять, ДЕВЯТЬ часов. неужели мы наконец-то приехали туда, куда давно стремились)

@apachik 30 мая 2016 в 08:22

Правило одно — есть возможность — надо заливать как можно раньше, несмотря на день недели.
Как правило, перезаливка все же редкое явление, поэтому лучше залить в пятницу, чем не залить.
Просто на финальное тестирование уходит много времени (мы очень беспокоимся за качество).

@justhabrauser 29 мая 2016 в 20:09

«и хочет, чтобы аппа ушла сегодня в стор на апрув, дабы выйграть лишние пару дней»

Для получения хотя бы РВП _не_ гражданину РФ надо сдать экзамен по русика изык очин трудни.
ФМС не туда смотрит, IMHO.

@dimka11 30 мая 2016 в 06:31

Один аккаунт разрешено использовать для нескольких разработчиков? И в чем смысл этого?

@KIVagant 30 мая 2016 в 08:01

Экономика должна быть экономной.

@Adnako 30 мая 2016 в 09:09

Боб жмет на show more, где его встречает ошибка

Простите, но зачем на сборочном сервере собирать продакшн-релиз и подписывать его сертификатом Developer'а?
Что мешает сделать сертификат для подписи продакшн-релизов, положить его только на сборочный сервер, изменить одну строчку в .xcconfig и забыть про эту ошибку хотя бы на год?

@house2008 30 мая 2016 в 09:40

Допустим в конторе несколько десятков аккаунтов. Разработчик всегда разрабатывает под своим одним аккаунтом. А уже под которым аккаунтом выложить приложение в стор решает бизнес, который заходит в админку приложения и из селекта выбирает на кого собрать и выложить данное приложение. Develop ipa собирается вместе с production, чтобы быть уверенным, что они собраны из одной кодовой базы.

@Adnako 30 мая 2016 в 11:02

Т.е. проблема в подписи develop ipa, собираемым на сервере?

@house2008 30 мая 2016 в 12:17

Не) Проблема в том, что куча сертификатов, кто-то их отзывает случайно (revoke), у некоторых истекает срок действия и забывают обновить. Это всё не так просто отследить, как я уже говорил выше, в разработке используются одни аккаунты, а в app store приложения уходят под другими. В данном примере у Боба develop ipa собралась, а production нет, потому что второй сертификат был кем-то отозван (revoked), а новый забыли поставить на машину, хотя mobileprovision был создан на новый сертификат.

@Adnako 30 мая 2016 в 12:54

Я и предлагаю решение — сертификат для продавлена всего один, подписывать релизные сборки на сборочном сервере надо им, а не каким-то пашей или машей, так больше порядка, имхо.

@Adnako 30 мая 2016 в 09:13

причем, сначала xcode компилирует зависимости (cocoapods) и уже только после проверяет валидность подписи, то есть только когда собирает основное приложение. Поэтому ошибка проявляется примерно во второй половине процесса сборки, из-за чего первые 6-7 минут потрачены в пустую, от чего Боб расстроен еще больше.

Боб был бы меньше расстроен, если бы предсобранные зависимости статически линковались (динамические — подкладывались) вместо их полной сборки. Собранные ранее бинарники зависимостей — артефакты сборки проектов зависимостей, собираются только при изменении в репозитории.

@house2008 30 мая 2016 в 09:29

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

@Adnako 30 мая 2016 в 11:09

Предлагаете все зависимости собирать в отдельные бинарники и затем их подключать руками к проекту вместе с кучей хедер файлов?

Предлагаю собирать зависимости отдельно от проекта и хранить артефакты сборки для использования во время сборки проекта. Всё это автоматически без всяких рук умеет собирать TeamCity.

вместе с кучей хедер файлов?

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

Возможно, это кому-то удобно, я даже знаю ребят кто так делает, но мне удобнее когда всё динамически само разруливается.

Дело не только в удобстве, этот подход точно уменьшает время сборки и ваш Боб ждал бы не 6-7 минут — когда же соберутся сначала все зависимости, а меньше минуты, пока они скачаются и распакуются.
Но, конечно же, можно кататься на стульях, размахивая палками, пока компилируется — дело вкуса )

@house2008 30 мая 2016 в 14:15

Предлагаете, например, ReactiveCocoa или AFNetworking собирать руками (или через carthage) в бинарник и его руками подключать в проект? А если я хочу исходники глянуть как там что работает? А такое бывает)

@Adnako 31 мая 2016 в 05:50

Ещё раз вам повторяю — собирать руками не надо, настройте сборку библиотек на сборочном агенте, помечайте тэгом коммит из которого собрались артефакты, подтягивайте артефакты из этой сборки в сборку самого проекта — сборочный агент умеет это делать автоматически без ваших рук.
Все ваши требования удовлетворены, плюс — счастливый Боб, не ожидающий у корыта по 7 минут сборки зависимостей.

@Adnako 30 мая 2016 в 09:16

просит админов дать доступ до сервера, коннектится туда по ssh и начинает выяснять, в чем же, именно, проблема и как её можно решить.

Боб, похоже, ответственный и образованный программист, раз ему админы легко дают доступ на сборочный сервер по ssh.
Да и админы не успели убежать пораньше в пятницу-то — тоже ответственные товарищи, хорошо знающие Боба и доверяющие ему.

@house2008 30 мая 2016 в 09:44

Всё верно) Боб работает не первый год в этой организации и у него сложились доверительные отношения с админами. Я так и не понял тут вашего сарказма(

@Adnako 30 мая 2016 в 11:11

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

@house2008 30 мая 2016 в 12:05

С этим Бобу повезло) Машинка, на которой собираются ios проекты, это просто отдельная физическая локальная тачка с xcode, cocoapods, и сертификатами. Куда затем с отдельного CI сервера прокидываются команды для сборки проектов и потом просто обратно выкачиваются результаты этого процесса. На сам же CI таким личностям как Боб доступ не положен)

@Adnako 31 мая 2016 в 06:03

А вообще, могу порекомендовать уже готовых руби-скриптов для автоматизации сборок.
Раз у вас есть доверительная близость с админами, а сам агент полностью ваш — Fastlane вам в помощь.

@house2008 31 мая 2016 в 06:13

Боб знает про fastline) тула крутая конечно, но он огорчен, что sigh resign работает только для простых ipa, если в ipa есть widget или framework, или даже часы, то он с этим не работает, поэтому Бобу пришлось немного допилить под себя.

@kpower 6 июн 2016 в 07:21

Боб ценит время своих коллег, а потому не пишет UI в коде. Пусть гаденыши общий storyboard мерджат! Уахаха!

@house2008 8 июн 2016 в 18:57

https://www.natashatherobot.com/i-heart-storyboards-nibs/, попробуйте такой подход )

@kpower 19 июн 2016 в 18:37

Спасибо за совет, но если вы про Storyboard References, то они iOS 8+, а делать пачку nib'ов не всегда хороший вариант как по мне.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий