Есть мнение, что слово «fun» нельзя просто так взять и перевести на русский как «весело».
Честно положа руку на орган — такой перевод — признак пофигизма.
Постарайтесь понять смысл и передать его вместо дословного, но идиотического «весело».
Прямо бесит уже.
fastlane не смотрели?
Попробуйте carthage вместо подов, если iOS 8+ — не поганит проект, добавляется одна фаза сборки, остальное из терминала примерно так же.
А вообще, могу порекомендовать уже готовых руби-скриптов для автоматизации сборок.
Раз у вас есть доверительная близость с админами, а сам агент полностью ваш — Fastlane вам в помощь.
Ещё раз вам повторяю — собирать руками не надо, настройте сборку библиотек на сборочном агенте, помечайте тэгом коммит из которого собрались артефакты, подтягивайте артефакты из этой сборки в сборку самого проекта — сборочный агент умеет это делать автоматически без ваших рук.
Все ваши требования удовлетворены, плюс — счастливый Боб, не ожидающий у корыта по 7 минут сборки зависимостей.
Я и предлагаю решение — сертификат для продавлена всего один, подписывать релизные сборки на сборочном сервере надо им, а не каким-то пашей или машей, так больше порядка, имхо.
Тут не в сарказме дело, ваш сценарий крайне оптимистичен, особенно, для вечера пятницы )
Посыл был в том, что не каждый программист — Боб, не все конторы разрешают лазить каким-то разработчикам по сборочным серверам и что-то там настраивать.
Предлагаете все зависимости собирать в отдельные бинарники и затем их подключать руками к проекту вместе с кучей хедер файлов?
Предлагаю собирать зависимости отдельно от проекта и хранить артефакты сборки для использования во время сборки проекта. Всё это автоматически без всяких рук умеет собирать TeamCity.
вместе с кучей хедер файлов?
Тому же TeamCity не важно сколько этих заголовочных файлов он распакует из артефакта-архива для сборки проекта.
Не желаете заголовочные файлы отдельно хранить — делайте статичный или динамический фреймворк и подключайте его — сложного мало.
Возможно, это кому-то удобно, я даже знаю ребят кто так делает, но мне удобнее когда всё динамически само разруливается.
Дело не только в удобстве, этот подход точно уменьшает время сборки и ваш Боб ждал бы не 6-7 минут — когда же соберутся сначала все зависимости, а меньше минуты, пока они скачаются и распакуются.
Но, конечно же, можно кататься на стульях, размахивая палками, пока компилируется — дело вкуса )
просит админов дать доступ до сервера, коннектится туда по ssh и начинает выяснять, в чем же, именно, проблема и как её можно решить.
Боб, похоже, ответственный и образованный программист, раз ему админы легко дают доступ на сборочный сервер по ssh.
Да и админы не успели убежать пораньше в пятницу-то — тоже ответственные товарищи, хорошо знающие Боба и доверяющие ему.
причем, сначала xcode компилирует зависимости (cocoapods) и уже только после проверяет валидность подписи, то есть только когда собирает основное приложение. Поэтому ошибка проявляется примерно во второй половине процесса сборки, из-за чего первые 6-7 минут потрачены в пустую, от чего Боб расстроен еще больше.
Боб был бы меньше расстроен, если бы предсобранные зависимости статически линковались (динамические — подкладывались) вместо их полной сборки. Собранные ранее бинарники зависимостей — артефакты сборки проектов зависимостей, собираются только при изменении в репозитории.
Простите, но зачем на сборочном сервере собирать продакшн-релиз и подписывать его сертификатом Developer'а?
Что мешает сделать сертификат для подписи продакшн-релизов, положить его только на сборочный сервер, изменить одну строчку в .xcconfig и забыть про эту ошибку хотя бы на год?
Проблемы начинаются, когда предприятие перерастает определённую планку развития, после которой «любой администратор» не способен самостоятельно контролировать жизнедеятельность всего подсобного хозяйства, после чего всё это хозяйство пускается в задорный, но обычно короткий пляс, финал которого — что-то постоянно не работает, админ весь рабочий день ходит чинит «заплаточным ремонтом» отвалившийся кусок, при этом что-то другое тут же отваливается или само или в результате «умелых» действий «любого админа».
Если же предприятие в этот момент активно растёт само и соответственно наращивает компьютерные мощности — наступает белый пушной зверёк и «любой админ для винды» уже не поможет — нужны специалисты по компьютерной интеграции в гомогенные, или хуже того — в гетерогенные структуры на базе каталогов типа той же Active Diectory, планирование развёртывания, планирование развития, планирование безопасности и надёжности и это только про серверную часть хозяйства. Обновление софта, обеспечение безопасности рабочих станций, VPN-доступ, корпоративная почта и доступ в интернет, сервера приложений, терминальной доступ, телефония и прочее и прочее.
Не говоря уже о том, что даже в платных продуктах майкрософт нередки такие недетские проблемы при администрировании той же AD, знания решения которых оцениваются крайне недёшево.
Покажите мне «любых виндовых админов», которые играючи справятся с такими задачами за копейки.
Эффективно «мусорить» в реестр получается не только у плохих разработчиков.
Хорошо, если вы — разработчик простенького mp3-плеера с «тремя галками» в окне настроек.
Тогда действительно снести свою ветку из HKLU/Software/MyBestMp3pleer — не кажется большой проблемой.
Проблема вырастает из результатов активностей всех тех, кто постоянно что-то пишет в реестр. Можете подумать кто пишет в реестр чаще и больше всех.
Проблема эта — фрагментация самого файла(ов) реестра, из-за которой работа с ним на легаси HDD, через пару месяцев активного использования винды, превращается в веселящий стрёкот скачущих головок винчестера. С приходом SSD эта беда практически обнуляется, и из-за этого в том числе, винда так живо начинает запускаться сама и запускать приложения вообще, будучи перенесённой на твёрдый-некрутящийся-диск.
С другой стороны наш всеобщелюбимый Ленард м.е. Поттеринг, внёс, О УЖАС!, предложение — создать единый реестр настроек для всей операционной системы Linux и приложений! И зная его плодовитость, настойчивость и наблюдая захватывающие результаты его кипучей жизнедеятельности, линукс близок к похожему решению, которое майкрософт использует, почему-то, уже не один десяток лет.
Извините, хотелось бы поинтересоваться — что вы знаете о менеджменте оперативной памяти операционной системой? Должна ли ОС аллоцировать всю доступную RAM заранее и выдавать её нуждающимся приложениям определённым способом?
Или же ОС должна «съесть» 100МБ лично для своих нужд и каждый раз по просьбе приложения метаться в поисках свободных «кусков»?
А замеряли вы «съеденное» как? Таскменеджер открыли и на колонку «память» смотрели?
Есть мнение, что слово «fun» нельзя просто так взять и перевести на русский как «весело».
Честно положа руку на орган — такой перевод — признак пофигизма.
Постарайтесь понять смысл и передать его вместо дословного, но идиотического «весело».
Прямо бесит уже.
Нет, не все.
Попробуйте carthage вместо подов, если iOS 8+ — не поганит проект, добавляется одна фаза сборки, остальное из терминала примерно так же.
Раз у вас есть доверительная близость с админами, а сам агент полностью ваш — Fastlane вам в помощь.
Все ваши требования удовлетворены, плюс — счастливый Боб, не ожидающий у корыта по 7 минут сборки зависимостей.
Посыл был в том, что не каждый программист — Боб, не все конторы разрешают лазить каким-то разработчикам по сборочным серверам и что-то там настраивать.
Предлагаю собирать зависимости отдельно от проекта и хранить артефакты сборки для использования во время сборки проекта. Всё это автоматически без всяких рук умеет собирать TeamCity.
Тому же TeamCity не важно сколько этих заголовочных файлов он распакует из артефакта-архива для сборки проекта.
Не желаете заголовочные файлы отдельно хранить — делайте статичный или динамический фреймворк и подключайте его — сложного мало.
Дело не только в удобстве, этот подход точно уменьшает время сборки и ваш Боб ждал бы не 6-7 минут — когда же соберутся сначала все зависимости, а меньше минуты, пока они скачаются и распакуются.
Но, конечно же, можно кататься на стульях, размахивая палками, пока компилируется — дело вкуса )
Боб, похоже, ответственный и образованный программист, раз ему админы легко дают доступ на сборочный сервер по ssh.
Да и админы не успели убежать пораньше в пятницу-то — тоже ответственные товарищи, хорошо знающие Боба и доверяющие ему.
Боб был бы меньше расстроен, если бы предсобранные зависимости статически линковались (динамические — подкладывались) вместо их полной сборки. Собранные ранее бинарники зависимостей — артефакты сборки проектов зависимостей, собираются только при изменении в репозитории.
Простите, но зачем на сборочном сервере собирать продакшн-релиз и подписывать его сертификатом Developer'а?
Что мешает сделать сертификат для подписи продакшн-релизов, положить его только на сборочный сервер, изменить одну строчку в .xcconfig и забыть про эту ошибку хотя бы на год?
Это откуда такие сведения?
Если же предприятие в этот момент активно растёт само и соответственно наращивает компьютерные мощности — наступает белый пушной зверёк и «любой админ для винды» уже не поможет — нужны специалисты по компьютерной интеграции в гомогенные, или хуже того — в гетерогенные структуры на базе каталогов типа той же Active Diectory, планирование развёртывания, планирование развития, планирование безопасности и надёжности и это только про серверную часть хозяйства. Обновление софта, обеспечение безопасности рабочих станций, VPN-доступ, корпоративная почта и доступ в интернет, сервера приложений, терминальной доступ, телефония и прочее и прочее.
Не говоря уже о том, что даже в платных продуктах майкрософт нередки такие недетские проблемы при администрировании той же AD, знания решения которых оцениваются крайне недёшево.
Покажите мне «любых виндовых админов», которые играючи справятся с такими задачами за копейки.
Хорошо, если вы — разработчик простенького mp3-плеера с «тремя галками» в окне настроек.
Тогда действительно снести свою ветку из HKLU/Software/MyBestMp3pleer — не кажется большой проблемой.
Проблема вырастает из результатов активностей всех тех, кто постоянно что-то пишет в реестр. Можете подумать кто пишет в реестр чаще и больше всех.
Проблема эта — фрагментация самого файла(ов) реестра, из-за которой работа с ним на легаси HDD, через пару месяцев активного использования винды, превращается в веселящий стрёкот скачущих головок винчестера. С приходом SSD эта беда практически обнуляется, и из-за этого в том числе, винда так живо начинает запускаться сама и запускать приложения вообще, будучи перенесённой на твёрдый-некрутящийся-диск.
С другой стороны наш всеобщелюбимый Ленард м.е. Поттеринг, внёс, О УЖАС!, предложение — создать единый реестр настроек для всей операционной системы Linux и приложений! И зная его плодовитость, настойчивость и наблюдая захватывающие результаты его кипучей жизнедеятельности, линукс близок к похожему решению, которое майкрософт использует, почему-то, уже не один десяток лет.
Или же ОС должна «съесть» 100МБ лично для своих нужд и каждый раз по просьбе приложения метаться в поисках свободных «кусков»?
А замеряли вы «съеденное» как? Таскменеджер открыли и на колонку «память» смотрели?
Глючный либроофис нельзя использовать даже для рефератов школьников, не говоря уже о бизнесе.
Я всё.