Comments 27
… и никаких релизов в пятницу!
Именно, кто ж релизит\чекинит вечером пятницы.
стандартная ios-практика. В пятницу «релизим» (заливаем билд на апрув в аппстор), в понедельник продолжаем тестировать и убеждаемся, что все ок (если не ок, то перезаливаем), в среду берут на ревью, в четверг апрувят и выпускаем юзерам.
Так было раньше. Последний месяц ревью занимает день-два: статистика appreviewtimes
Так было раньше. Последний месяц ревью занимает день-два: статистика appreviewtimes
странная практика, в идеале тогда релизить нужно в среду, 2 дня на тест и перезаливку без потери 2 дополнительных дней (выходные)
сами релизим в пятницу :) вот только не пытаемся это логически обосновать — логики нет
кстати, в прошедшую пятницу релиз был на ревью 9 часов (девять, ДЕВЯТЬ часов. неужели мы наконец-то приехали туда, куда давно стремились)
сами релизим в пятницу :) вот только не пытаемся это логически обосновать — логики нет
кстати, в прошедшую пятницу релиз был на ревью 9 часов (девять, ДЕВЯТЬ часов. неужели мы наконец-то приехали туда, куда давно стремились)
«и хочет, чтобы аппа ушла сегодня в стор на апрув, дабы выйграть лишние пару дней»
Для получения хотя бы РВП _не_ гражданину РФ надо сдать экзамен по русика изык очин трудни.
ФМС не туда смотрит, IMHO.
Для получения хотя бы РВП _не_ гражданину РФ надо сдать экзамен по русика изык очин трудни.
ФМС не туда смотрит, IMHO.
Один аккаунт разрешено использовать для нескольких разработчиков? И в чем смысл этого?
Боб жмет на show more, где его встречает ошибка
Простите, но зачем на сборочном сервере собирать продакшн-релиз и подписывать его сертификатом Developer'а?
Что мешает сделать сертификат для подписи продакшн-релизов, положить его только на сборочный сервер, изменить одну строчку в .xcconfig и забыть про эту ошибку хотя бы на год?
Допустим в конторе несколько десятков аккаунтов. Разработчик всегда разрабатывает под своим одним аккаунтом. А уже под которым аккаунтом выложить приложение в стор решает бизнес, который заходит в админку приложения и из селекта выбирает на кого собрать и выложить данное приложение. Develop ipa собирается вместе с production, чтобы быть уверенным, что они собраны из одной кодовой базы.
Т.е. проблема в подписи develop ipa, собираемым на сервере?
Не) Проблема в том, что куча сертификатов, кто-то их отзывает случайно (revoke), у некоторых истекает срок действия и забывают обновить. Это всё не так просто отследить, как я уже говорил выше, в разработке используются одни аккаунты, а в app store приложения уходят под другими. В данном примере у Боба develop ipa собралась, а production нет, потому что второй сертификат был кем-то отозван (revoked), а новый забыли поставить на машину, хотя mobileprovision был создан на новый сертификат.
причем, сначала xcode компилирует зависимости (cocoapods) и уже только после проверяет валидность подписи, то есть только когда собирает основное приложение. Поэтому ошибка проявляется примерно во второй половине процесса сборки, из-за чего первые 6-7 минут потрачены в пустую, от чего Боб расстроен еще больше.
Боб был бы меньше расстроен, если бы предсобранные зависимости статически линковались (динамические — подкладывались) вместо их полной сборки. Собранные ранее бинарники зависимостей — артефакты сборки проектов зависимостей, собираются только при изменении в репозитории.
Предлагаете все зависимости собирать в отдельные бинарники и затем их подключать руками к проекту вместе с кучей хедер файлов? Возможно, это кому-то удобно, я даже знаю ребят кто так делает, но мне удобнее когда всё динамически само разруливается. Дело вкуса)
Предлагаете все зависимости собирать в отдельные бинарники и затем их подключать руками к проекту вместе с кучей хедер файлов?
Предлагаю собирать зависимости отдельно от проекта и хранить артефакты сборки для использования во время сборки проекта. Всё это автоматически без всяких рук умеет собирать TeamCity.
вместе с кучей хедер файлов?
Тому же TeamCity не важно сколько этих заголовочных файлов он распакует из артефакта-архива для сборки проекта.
Не желаете заголовочные файлы отдельно хранить — делайте статичный или динамический фреймворк и подключайте его — сложного мало.
Возможно, это кому-то удобно, я даже знаю ребят кто так делает, но мне удобнее когда всё динамически само разруливается.
Дело не только в удобстве, этот подход точно уменьшает время сборки и ваш Боб ждал бы не 6-7 минут — когда же соберутся сначала все зависимости, а меньше минуты, пока они скачаются и распакуются.
Но, конечно же, можно кататься на стульях, размахивая палками, пока компилируется — дело вкуса )
Предлагаете, например, ReactiveCocoa или AFNetworking собирать руками (или через carthage) в бинарник и его руками подключать в проект? А если я хочу исходники глянуть как там что работает? А такое бывает)
Ещё раз вам повторяю — собирать руками не надо, настройте сборку библиотек на сборочном агенте, помечайте тэгом коммит из которого собрались артефакты, подтягивайте артефакты из этой сборки в сборку самого проекта — сборочный агент умеет это делать автоматически без ваших рук.
Все ваши требования удовлетворены, плюс — счастливый Боб, не ожидающий у корыта по 7 минут сборки зависимостей.
Все ваши требования удовлетворены, плюс — счастливый Боб, не ожидающий у корыта по 7 минут сборки зависимостей.
просит админов дать доступ до сервера, коннектится туда по ssh и начинает выяснять, в чем же, именно, проблема и как её можно решить.
Боб, похоже, ответственный и образованный программист, раз ему админы легко дают доступ на сборочный сервер по ssh.
Да и админы не успели убежать пораньше в пятницу-то — тоже ответственные товарищи, хорошо знающие Боба и доверяющие ему.
Всё верно) Боб работает не первый год в этой организации и у него сложились доверительные отношения с админами. Я так и не понял тут вашего сарказма(
Тут не в сарказме дело, ваш сценарий крайне оптимистичен, особенно, для вечера пятницы )
Посыл был в том, что не каждый программист — Боб, не все конторы разрешают лазить каким-то разработчикам по сборочным серверам и что-то там настраивать.
Посыл был в том, что не каждый программист — Боб, не все конторы разрешают лазить каким-то разработчикам по сборочным серверам и что-то там настраивать.
С этим Бобу повезло) Машинка, на которой собираются ios проекты, это просто отдельная физическая локальная тачка с xcode, cocoapods, и сертификатами. Куда затем с отдельного CI сервера прокидываются команды для сборки проектов и потом просто обратно выкачиваются результаты этого процесса. На сам же CI таким личностям как Боб доступ не положен)
А вообще, могу порекомендовать уже готовых руби-скриптов для автоматизации сборок.
Раз у вас есть доверительная близость с админами, а сам агент полностью ваш — Fastlane вам в помощь.
Раз у вас есть доверительная близость с админами, а сам агент полностью ваш — Fastlane вам в помощь.
Боб ценит время своих коллег, а потому не пишет UI в коде. Пусть гаденыши общий storyboard мерджат! Уахаха!
https://www.natashatherobot.com/i-heart-storyboards-nibs/, попробуйте такой подход )
Sign up to leave a comment.
Apple, боль и сертификаты