Pomyślnie przetestowano, że rozwiązanie i40west działa w celu ręcznego uruchamiania symulatora, ale wydaje się głupie, że w dzisiejszych czasach symulator iOS wymaga różnych wersji Xcode ORAZ różnych typów urządzeń podczas równoległych testów z wiersza poleceń (nieco inny przypadek użycia, ale związany z oryginalnym pytaniem u góry ).
Zapoznaj się z artykułem Apple, który jest najbardziej odpowiedni dla kompilacji i testów wiersza poleceń:
https://developer.apple.com/library/ios/technotes/tn2339/_index.html
Wiele równoległych testów zadziałało dobrze, jeśli przekazanie poprawnych --args - do „iOS simulator.app” przed uruchomieniem polecenia „xcodebuild test” z prawidłowym uruchomieniem symulatorów wartości „-destination” z wartością UUID z wyjścia „xcrun” simctl list 'i ustawienie zmiennej środowiskowej DEVELOPER_DIR, aby wybrać różne pliki binarne wersji XCode (tj. ścieżkę podstawową do Xcode 6.1 i 6.4)
Powodem konieczności jednoczesnych testów jednostkowych na tej samej maszynie fizycznej i tym samym urządzeniu symulującym iOS, takim jak iPad lub iPhone i tej samej wersji Xcode, jest przede wszystkim obsługa CI (ciągłej integracji) dowolnego projektu iOS, dzięki czemu ten sam system kompilacji może uruchomić więcej niż 1 kompilację z wielu aplikacje (nasza firma ma około 30 aplikacji) naraz podczas rejestracji gałęzi funkcji są automatycznie skanowane i budowane przez agenta Bamboo bez konieczności czekania na ukończenie innych uruchomionych kompilacji - Bamboo obsługuje ten typ automatycznego budowania wykryte gałęzie funkcji, jeśli są włączone.
Jeśli chodzi o to, co dzieje się podczas uruchamiania wielu równoległych testów, uruchamiamy wiele poleceń „xcodebuild test” dwa razy z rzędu w różnych oknach Terminal.app, w wyniku czego pojawia się tylko jedno okno symulatora i testy kończą się niepowodzeniem w najprostszym teście.
Kiedy komplikujemy kryteria wejścia dla naszego uruchomienia testowego, różne wersje Xcode dla każdej karty SIM i uruchomienia testowego, używając DEVELOPER_DIR zgodnie ze stronami podręcznika (test xcodebuild), określamy inne urządzenie, które otwiera się w dwóch oddzielnych oknach, ale w rezultacie wszelkie uruchomione testy w pierwszym oknie są przerywane przez drugie okno symulatora iOS.
Wydaje się, że pod maską znajduje się wspólny zasób, który przeszkadza, nie jest pewien, czy jest przeznaczony, lub po prostu nowa funkcja, która wymaga więcej niż kilku dni poważnych przemyśleń, jak lepiej wdrożyć równoczesne przebiegi testowe bez negatywnych skutków.
Nie chcemy używać maszyn wirtualnych do obejścia ograniczeń karty SIM, ponieważ z naszego doświadczenia i innych osób wynika, że wydajność kompilacji systemu iOS na maszynach wirtualnych z dużą liczbą małych plików jest wolniejsza niż na sprzęcie fizycznym. Maszyny wirtualne na ogół znacznie spowalniają proces kompilacji z powodu problemów we / wy w połączeniu oprogramowania VMware i sprzętu i / lub oprogramowania układowego Apple. Przepraszamy, virtualghetto, ale dla nas maszyny wirtualne nie działają dobrze - witryna virtuallyghetto dostarczyła nam instrukcje, jak zainstalować ESXi 5.5 na komputerach Mac Mini dla naszej farmy kompilacji.
Doświadczyliśmy problemu z wydajnością kompilacji, gdy ESXi 5.5 na Macu Mini jest wolniejszy niż czysty metal, nawet z dyskiem SSD o współczynnik 2 lub więcej (tj. 10-minutowa kompilacja baremetal zajmuje 20 na VM). Zapoznaj się z poniższym artykułem o rozwiązaniu, aby dowiedzieć się, dlaczego.
https://corner.squareup.com/2015/07/ios-build-infrastructure.html
Ograniczenie jednorazowo jednego urządzenia SIM do testów jednostkowych xcodebuild poważnie zmniejsza produktywność i wykładniczo zwiększa koszty Apple i ekosystemu.
Koszt dla Apple wynikający z braku obsługi współbieżności w celu uzasadnienia większej liczby zakupów sprzętu należy dokładnie przemyśleć, rozważając ryzyko utraty szybkości programisty względem innych konkurentów, którzy mają mniej ograniczeń w zakresie symulacji i licencji EULA.
Zaletą równoległych testów z tym samym loginem użytkownika (jak działa większość systemów CI) jest jakość aplikacji Apple App Store, która z kolei jest po części tym, co sprawia, że ludzie kupują urządzenia z iOS w pierwszej kolejności. Słaba jakość oprogramowania sprawia, że cała marka jest nieco bardziej powolna, a obsługa współbieżności w symulatorach iOS zdecydowanie wydaje się sprytnym sposobem na wspieranie ekosystemu. Nieco następstwem omawianego problemu są ostatnie ulepszenia, takie jak serwer Apple Xcode dla CI, automatyczne testy interfejsu użytkownika Xcode w Xcode 7.
Zachęcanie do niepotrzebnych kosztów, aby ludzie kupowali masowe ilości sprzętu, instalacji, konfiguracji, nie wspominając o wielu ludziach potrzebnych do obsługi wszystkich maszyn, sieci i punktów zasilania itp., Potencjalnie zaszkodzi zyskom Apple'a, ponieważ nie każdy jest taki jak Apple i stać na stojaki z komputerami MacPro lub Mac Mini tylko po to, aby obsługiwać równoległe testy na symulatorach. Celem symulatora jest unikanie używania sprzętu, a także przyspieszanie testów.
Ponadto ograniczenia EULA dotyczące maszyn wirtualnych sprawiają, że argumenty dotyczące maszyn wirtualnych na komputerach Mac Pro są dość słabe. Ten typ sprzętu byłby atrakcyjny, gdyby można było uruchomić wiele symulatorów, ale ponieważ równoczesne testy jednostkowe nie są obsługiwane (z wyjątkiem powyższych dwóch warunków - inna wersja XCode i inne urządzenie symulujące), prawdopodobnie będziemy trzymać się Mac Mini do budowy infrastruktury.
Te ograniczenia dotyczące karty SIM i umowy EULA firmy Apple nie tylko spowalniają proces kompilacji, ale także zwiększają niepotrzebną złożoność i koszty. Może to nie być takie niepokojące w przypadku małych aplikacji, ale gdy aplikacje rosną i są coraz bardziej złożone, kompilacja może zająć nawet godzinę (słyszałem, że kompilacje Facebooka na iOS mogą trwać tak długo). Nikt nie chce czekać godziny, aby dowiedzieć się, czy kompilacja minęła.
Znamy rozwiązania hakerskie, takie jak uruchamianie maszyn wirtualnych ESXI na komputerach Mac Minis, które nie działają dobrze pod względem wydajności z systemem OS X i xcodebuild w dużych projektach z kompilacjami, które zajmują więcej niż 10 minut na nowoczesnym MacBooku Pro lub Mac Mini, lub na różnych kontach logowania na czystej maszynie do środowiska tylko po to, aby móc uruchomić równoległe testy na tej samej wersji Xcode i tym samym urządzeniu symulującym.
ESXi nie jest oficjalnie obsługiwany, chociaż działa całkiem dobrze. Jednym z powodów, dla których VMware może nie obsługiwać sprzętu Mac Mini, jest brak pamięci ECC, chociaż Mac Pro jest obsługiwany, ponieważ ma pamięć ECC, prawdopodobnie ma takie same problemy jak Mac Mini pod względem spowolnienia kompilacji iOS w porównaniu do gołego metalu testy na tym samym sprzęcie i konfiguracji oprogramowania (tylko zmiana dotyczy maszyny wirtualnej w porównaniu z fizycznym systemem operacyjnym OS X). W tej chwili MacPro nie został przez nas przetestowany. Z naszego doświadczenia wynika, że VMware Fusion jest również dość powolny pod względem wydajności.
Co ważniejsze, programiści będą musieli poczekać dłużej, gdy wyżej wymienione problemy zostaną złożone, chyba że pula maszyn jest wystarczająco duża, aby obsłużyć zestaw zmian (jedna kompilacja CI na 2 programistów, bardzo wysoki stosunek maszyn do programistów). Maszyny kompilujące CI powinny być w stanie uruchomić więcej współbieżnych kompilacji i więcej współbieżnych testów niż 1.
Jedną z innych obserwacji dotyczących symulatorów iOS jest to, że wydają się one być w toku i całkowicie niedokończone nawet po 7 głównych wersjach. Podkomenda 'xcrun simctl' ma opcję --set, która może pozwolić na pewną elastyczność, ale nie jest pewna, jaka możliwa wartość jest prawidłowa, i to samo z --noxpc. Nikt nie powinien zgadywać odpowiednich wartości, a ponadto powinna istnieć strona podręcznika, która omawia tę opcję i być może przykład. Jakie są przypadki użycia tych 2 interesujących opcji?
Można powiedzieć, że żadna aplikacja nie powinna być zaprojektowana tak, aby zajmowała dużo miejsca, co gwarantuje uruchomienie testów równoległych i korzystanie z lepszej architektury opartej na XPC, ponieważ problemem są aplikacje monolityczne. Może to być prawdą, ale nie jest to tak pragmatyczne rozwiązanie, na jakie moglibyśmy mieć nadzieję, a problem pozostaje, jeśli masz ponad 20 aplikacji do zbudowania na tej samej infrastrukturze.
Stworzenie konfiguracji maszyny i procesów tak ogólnych i skalowalnych, jak to tylko możliwe, dla większej przepustowości będzie wymagało trochę pracy na symulatorze (programista + core). Wymaga to również wysokiego poziomu współpracy między wszystkimi programistami symulatorów Apple a właścicielami produktów symulatorów, aby poprawnie zamówić zaległości produktowe dla tego problemu, aby zwrócić uwagę :-)
