Успішно перевірено, що рішення i40west працює на ручному запуску симулятора, але здається нерозумним, що в цей день і вік для iOS-симулятора потрібні різні версії Xcode І різні типи пристроїв при запуску паралельних тестів з командного рядка (дещо інший випадок використання, але пов'язаний з оригінальним запитанням вгорі ).
Тут див. Статтю Apple, яка є найбільш актуальною для збірки та тестів командного рядка:
https://developer.apple.com/library/ios/technotes/tn2339/_index.html
Кілька паралельних тестів спрацювало для нас, якщо передати правильні --args - на "iOS simulator.app", перш ніж запустити команду "xcodebuild test" з правильним запуском симулятора "-destination", що відповідає значенню UUID, з виведенням xcrun список simctl 'та встановлення змінної середовища DEVELOPER_DIR для вибору різних бінарних файлів версії XCode (тобто базовий шлях до Xcode 6.1 та 6.4)
Причина необхідності паралельних тестів на тій же фізичній машині та на тому ж пристрої тренажера iOS, як iPad чи iPhone, та ж версія Xcode - це насамперед для підтримки CI (безперервної інтеграції) будь-якого проекту iOS, за допомогою якого одна і та ж система збирання може запускати більше ніж 1 збірку декількох додатки (у нашої компанії є 30 додатків або більше) одночасно після реєстрації в галузях функцій автоматично скануються та створюються агентом Bamboo, не потрібно чекати завершення інших запущених збірок - Bamboo підтримує цей тип автоматичної побудови на автоматичному- виявлені гілки функцій, якщо вони включені.
Що стосується того, що відбувається під час виконання декількох одночасних тестів, ми виконуємо кілька команд 'xcodebuild test' двічі поспіль у різних вікнах Terminal.app, в результаті з’являється лише одне вікно тренажера, і тести провалюються у найпростішому тесті.
Коли ми ускладнюємо критерії вступу для нашого тестового запуску, різних версій Xcode для кожного sim та тестового запуску, при використанні DEVELOPER_DIR відповідно до сторінок man (тест xcodebuild) ми визначаємо інший пристрій, який відкриється у двох окремих вікнах, але результат полягає в тому, що будь-які запущені тести в першому вікні перериваються другим вікном симулятора iOS.
Здається, є загальний спільний ресурс під кришкою, який стає на шляху, не впевнений, що він призначений, або просто нова функція, яка вимагає більше декількох днів серйозної роздуми про те, як краще реалізувати паралельні тестові запуски без несприятливих наслідків.
Ми не хочемо використовувати VM для обходу сим-обмежень, оскільки наш досвід та інші в цілому полягають у тому, що iOS збирає продуктивність на VM з великою кількістю невеликих файлів повільніше, ніж на фізичному обладнанні. Зазвичай VM уповільнить нарощування на багато через проблеми вводу / виводу у поєднанні програмного забезпечення VMware та апаратного забезпечення Apple та / або мікропрограмного забезпечення. Вибачте практично гетто, але для нас VM працюють не дуже добре - сайт virtualghetto надав нам інструкції щодо встановлення ESXi 5.5 на Mac Mini для нашої ферми побудови.
У нас виникла проблема продуктивності збірки, коли ESXi 5.5 на Mac Mini повільніше, ніж голий метал, навіть із SSD в 2 рази або більше (тобто, 10-хвилинне баретальне збирання займає 20 на VM). Про причину див. Статтю в розділі "Квадрат".
https://corner.squareup.com/2015/07/ios-build-infrastructure.html
Обмеження 1-сим-пристрою одночасно для тестів блоку xcodebuild сильно знижує продуктивність і експоненціально додає значних витрат Apple та екосистемі.
Витрати Apple, що не підтримують паралельність для виправдання більшої кількості придбання обладнання, повинні ретельно продумувати, зважуючи ризики втрати швидкості розробника в порівнянні з іншими конкурентами, які мають менші обмеження щодо sims та EULA.
Перевага паралельних тестів у тому ж вході користувачів (як працює більшість систем ci) полягає в тому, що якість додатків фірмового магазину Apple, що, в свою чергу, є частково тим, що змушує людей купувати пристрої iOS в першу чергу. Погана якість програмного забезпечення робить весь бренд трохи більш млявим, а підтримка одночасності в тренажерах iOS, безумовно, схоже на розумний спосіб підтримати екосистему. Трохи наслідком цієї проблеми є останні вдосконалення, такі як сервер Xcode Apple для CI, автоматизований інтерфейс Xcode тестує функціональність у Xcode 7.
Заохочення непотрібних накладних витрат, щоб змусити людей купувати масові кількості обладнання, налаштування, конфігурації, не кажучи вже про численних людей, необхідних для підтримки всіх машин, мереж та точок живлення тощо, потенційно зашкодить прибуткам Apple, зрештою, оскільки не всі схожі на Apple і можливість дозволити собі стелажі MacPro або Mac Mini просто для підтримки паралельних тестів на тренажерах. Вся суть імітатора полягає в тому, щоб не використовувати апаратне забезпечення, а також прискорити тести.
Крім того, обмеження EULA щодо віртуальних машин робить ситуацію з VM на Mac Pro досить слабкою. Цей апаратний тип був би привабливим, якщо можна було б запустити кілька сим-файлів, але оскільки паралельні тести модулів не підтримуються (за винятком двох вище умов - різної версії XCode та іншого пристрою тренажера), ми, швидше за все, будемо дотримуватися Mac Mini для побудови інфраструктури.
Ці обмеження SIM та EULA від Apple не тільки роблять конвеєр побудови повільніше, але й додають зайвих складностей та витрат. Можливо, це не так стосується невеликих додатків, але в міру того, як додатки зростають у розмірі та складності, збірка може зайняти більше години (я чув, що створення iOS у Facebook може зайняти так довго). Ніхто не хоче чекати годину, щоб знати, чи пройшла збірка.
Ми знаємо про такі рішення, як запуск ESXI VM на Mac Minis, які не дуже добре працюють з ОС X і xcodebuild для великих проектів із збірками, які займають більше 10 хвилин на сучасних Mac Book Pro або Mac Mini, або різних облікових записах для входу. на голій металевій машині в навколишнє середовище просто для того, щоб можна було виконувати паралельні тести на тій же версії Xcode і на тому ж пристрої симулятора.
ESXi офіційно не підтримується, хоча працює досить добре. Однією з причин того, що VMware може не підтримувати апаратне забезпечення Mac Mini, але це відсутність пам’яті ECC, хоча Mac Pro підтримується, оскільки він має пам’ять ECC, але, швидше за все, такі проблеми, як у Mac Mini в плані iOS, сповільнюється в порівнянні з голим металом тести на те саме апаратне та програмне забезпечення (лише зміна VM порівняно з голою металевою ОС X X). Наразі MacPro не перевірений нами. На наш досвід, VMware Fusion є досить повільним і в плані продуктивності.
Що ще важливіше, розробникам потрібно буде чекати довше, коли вищезгадані проблеми будуть складені разом, якщо тільки пул машин не є достатньо великим, щоб підтримувати перелік змін (одна збірка CI на кожні 2 диски, дуже високе відношення машин до розробника). Машини побудови CI повинні мати можливість виконувати більше одночасних збірок і більше паралельних тестів, ніж 1.
Одне з інших спостережень щодо симуляторів iOS - це те, що вони здаються незавершеною роботою та повністю незавершеною навіть після 7 основних версій. Підкоманда 'xcrun simctl' має опцію --set, яка може дозволити певну гнучкість, але не впевнена, яке можливе значення є дійсним, і те саме - --noxpc. Ніхто не повинен здогадуватися про відповідні значення, і, крім того, повинна бути довідна сторінка, яка охоплює цей параметр і, можливо, приклад. Які кілька випадків використання для цих 2 цікавих варіантів?
Ви можете сказати, що жоден додаток не повинен бути розроблений таким чином, щоб він мав великий слід, який вимагає запуску паралельного тесту та використання кращої архітектури на базі XPC, оскільки проблемою є монолітні програми. Це може бути правильним, воно не є настільки прагматичним рішенням, як ми могли би сподіватися, і проблема залишається, якщо у вас є 20+ додатків для створення однієї інфраструктури.
Щоб зробити конфігурацію машини та процеси максимально загальними та масштабованими для більшої пропускної здатності, знадобиться певна робота над тренажером (додаток + основні розробники). Це також вимагає високого рівня співпраці між усіма розробниками симуляторів Apple та власниками продуктів симулятора, щоб правильно замовити відставання продукту для цього питання, щоб отримати будь-яку увагу :-)
