Po tym, jak pull request zostanie scalony i kod trafi do develop, mo\u017cna wybra\u0107 odpowiedni czas: na przyk\u0142ad w nocy, kiedy wszystkie serwery s\u0105 wolne, i uruchomi\u0107 kontrole na maxa.<\/li>\n<\/ul>\n\nUruchamianie kontroli na swoim laptopie nikomu si\u0119 nie podoba\u0142o. Kiedy programista sko\u0144czy\u0142 funkcj\u0119, chcia\u0142 jak najszybciej j\u0105 wypchn\u0105\u0107 i otworzy\u0107 pull request. Je\u015bli w tym momencie uruchamiane s\u0105 d\u0142ugie kontrole, to nie tylko jest to ma\u0142o przyjemne, ale tak\u017ce spowalnia rozw\u00f3j: dop\u00f3ki laptop co\u015b sprawdza, nie mo\u017cna na nim normalnie pracowa\u0107.<\/p>\n
Bardzo spodoba\u0142o nam si\u0119 uruchamianie kontroli w nocy, poniewa\u017c jest du\u017co czasu i serwer\u00f3w, mo\u017cna sobie poszale\u0107. Niestety, gdy kod funkcji trafi\u0142 do develop, programista mia\u0142 znacznie mniej motywacji, aby naprawi\u0107 b\u0142\u0119dy, kt\u00f3re znalaz\u0142o CI. Czasami \u0142apa\u0142em si\u0119 na tym, \u017ce patrz\u0105c na poranny raport o wszystkich znalezionych b\u0142\u0119dach my\u015bla\u0142em, \u017ce naprawi\u0119 je kiedy\u015b p\u00f3\u017aniej, poniewa\u017c teraz w Jira czeka niesamowite nowe zadanie, kt\u00f3re chcia\u0142bym jak najszybciej zacz\u0105\u0107 realizowa\u0107.<\/p>\n
Je\u015bli kontrole blokuj\u0105 pull request, to motywacja jest wystarczaj\u0105ca, bo dop\u00f3ki kompilacje nie b\u0119d\u0105 zielone, kod nie trafi do develop, a to oznacza, \u017ce zadanie nie b\u0119dzie zako\u0144czone.<\/p>\n
Ostatecznie wybrali\u015bmy tak\u0105 strategi\u0119: w nocy uruchamiamy mo\u017cliwie najwi\u0119kszy zestaw test\u00f3w, a najwa\u017cniejsze i przede wszystkim najszybsze uruchamiamy przy \u017c\u0105daniu pull request. Ale na tym nie przestajemy \u2014 r\u00f3wnolegle optymalizujemy czas przechodzenia test\u00f3w, aby przenie\u015b\u0107 je z trybu nocnego do test\u00f3w przy \u017c\u0105daniu pull request.<\/p>\n
W tamtym czasie wszystkie nasze kompilacje odbywa\u0142y si\u0119 wystarczaj\u0105co szybko, dlatego po prostu w\u0142\u0105czyli\u015bmy blokad\u0119 dla \u017c\u0105dania pull request dla kompilacji ARC, test\u00f3w Junit i oblicze\u0144 pokrycia kodu. W\u0142\u0105czyli\u015bmy, pomy\u015bleli\u015bmy \u2014 i zrezygnowali\u015bmy z pokrycia kodu, poniewa\u017c uznali\u015bmy, \u017ce jest nam niepotrzebne.<\/p>\n
Ca\u0142a konfiguracja podstawowego CI zaj\u0119\u0142a nam dwa dni (tutaj i dalej oszacowanie czasowe jest przybli\u017cone, potrzebne dla kontekstu). <\/em><\/strong><\/p>\nPo tym zacz\u0119li\u015bmy si\u0119 zastanawia\u0107 \u2014 czy w\u0142a\u015bciwie w og\u00f3le testujemy? Czy w\u0142a\u015bciwie uruchamiamy budowy przy \u017c\u0105daniu pull request?<\/p>\n
Uruchamiali\u015bmy kompilacj\u0119 na ostatnim commicie ga\u0142\u0119zi, na kt\u00f3rej otwarto pull request. Ale testy tego commita mog\u0105 pokaza\u0107 tylko, \u017ce kod napisany przez programist\u0119 dzia\u0142a. Nie dowodz\u0105 one, \u017ce nic nie zepsu\u0142. W rzeczywisto\u015bci trzeba sprawdzi\u0107 stan ga\u0142\u0119zi develop po tym, jak funkcjonalno\u015b\u0107 zostanie w ni\u0105 w\u0142\u0105czona.<\/p>\n
![\"Ewolucja](\"\/wp-content\/uploads\/2019\/04\/c1a179b68b02c04031177f9bf51a81ed.jpg\")
\n
\nW tym celu napisali\u015bmy prosty skrypt bash premerge.sh:<\/strong><\/p>\n#!\/usr\/bin\/env bash\n\nset -e\n\ngit fetch origin develop\n\ngit merge origin\/develop<\/code><\/pre>\n\nTutaj pobierane s\u0105 wszystkie najnowsze zmiany z develop i w\u0142\u0105czane do bie\u017c\u0105cej ga\u0142\u0119zi. Dodali\u015bmy skrypt premerge.sh jako pierwszy krok wszystkich kompilacji i zacz\u0119li\u015bmy sprawdza\u0107 dok\u0142adnie to, co chcemy, czyli integracj\u0119<\/strong>.<\/p>\nNa lokalizacj\u0119 problemu, znalezienie rozwi\u0105zania i napisanie tego skryptu zaj\u0119\u0142o nam trzy dni.<\/em><\/strong><\/p>\nAplikacja rozwija\u0142a si\u0119, pojawia\u0142o si\u0119 coraz wi\u0119cej zada\u0144, zesp\u00f3\u0142 si\u0119 powi\u0119ksza\u0142, a premerge.sh czasami zaczyna\u0142 nas zawodzi\u0107. W develop przenika\u0142y konflikty zmian, kt\u00f3re \u0142ama\u0142y kompilacj\u0119.<\/p>\n
Przyk\u0142ad tego, jak to si\u0119 dzieje:<\/p>\n
![\"Ewolucja](\"\/wp-content\/uploads\/2019\/04\/6762d9ce4e431549455c49f2317a8f20.jpg\")
\n
\nDwaj programi\u015bci jednocze\u015bnie zaczynaj\u0105 pracowa\u0107 nad funkcjami A i B. Programista funkcji A odkrywa w projekcie nieu\u017cywan\u0105 funkcj\u0119 answer()<\/code> i, jak dobry skaut, j\u0105 usuwa. W tym samym czasie programista funkcji B w swojej ga\u0142\u0119zi dodaje nowe wywo\u0142anie tej funkcji.<\/p>\nProgrami\u015bci ko\u0144cz\u0105 prac\u0119 i w tym samym czasie otwieraj\u0105 pull request. Uruchamiane s\u0105 kompilacje, premerge.sh sprawdza oba \u017c\u0105dania pull request w odniesieniu do \u015bwie\u017cego stanu develop \u2014 wszystkie testy s\u0105 zielone. Po tym \u0142\u0105czony jest pull request funkcji A, a nast\u0119pnie pull request funkcji B\u2026 Bum! Develop si\u0119 \u0142amie, poniewa\u017c w kodzie develop jest wywo\u0142anie nieistniej\u0105cej funkcji.<\/p>\n
![\"Ewolucja](\"\/wp-content\/uploads\/2019\/04\/0261dcc9f7f2e5e018ab136081b4679b.jpg\")
\n
\nKiedy develop si\u0119 nie kompiluje, to lokalna katastrofa<\/strong>. Ca\u0142y zesp\u00f3\u0142 nie mo\u017ce nic zebra\u0107 i odda\u0107 do test\u00f3w.<\/p>\nZdarzy\u0142o si\u0119, \u017ce zajmowa\u0142em si\u0119 g\u0142\u00f3wnie zadaniami infrastrukturalnymi: analityka, sie\u0107, bazy danych. To znaczy, \u017ce to ja pisa\u0142em funkcje i klasy, kt\u00f3re wykorzystuj\u0105 inni programi\u015bci. Z tego powodu cz\u0119sto stawa\u0142em w podobnych sytuacjach. Mia\u0142em nawet jaki\u015b czas tak\u0105 grafik\u0119.<\/p>\n
![\"Ewolucja](\"\/wp-content\/uploads\/2019\/04\/0eb1aadd05b33ce995027ab52d5c1e53.jpg\")
\n
\nPoniewa\u017c to nam nie odpowiada\u0142o, zacz\u0119li\u015bmy opracowywa\u0107 opcje, jak to zapobiec.<\/p>\n
Jak nie \u0142ama\u0107 develop<\/h2>\n
\nPierwsza opcja: przebudowa\u0107 wszystkie pull requesty przy aktualizacji develop. <\/strong>Je\u015bli w naszym przyk\u0142adzie pull request z funkcjonalno\u015bci\u0105 A jako pierwszy trafi do develop, pull request funkcjonalno\u015bci B zostanie przebudowany i odpowiednio, kontrole nie przejd\u0105 z powodu b\u0142\u0119du kompilacji.<\/p>\nAby zrozumie\u0107, ile czasu to zajmie, rozwa\u017cmy przyk\u0142ad z dwoma PR. Otwieramy dwa PR: dwa buildy, dwa uruchomienia kontrolek. Po tym, jak pierwszy PR zostanie scalony z develop, drugi musi zosta\u0107 przebudowany. W sumie, na dwa PR potrzeba trzech uruchomie\u0144 kontrolek: 2 + 1 = 3.<\/p>\n
W zasadzie to w porz\u0105dku. Ale przyjrzeli\u015bmy si\u0119 statystykom, a typow\u0105 sytuacj\u0105 w naszym zespole by\u0142o 10 otwartych PR, a wtedy liczba kontrolek to suma post\u0119puj\u0105cej: 10 + 9 +\u2026 + 1 = 55. To znaczy, \u017ceby zaakceptowa\u0107 10 PR, trzeba przebudowa\u0107 55 razy. I to w idealnej sytuacji, gdy wszystkie kontrole przechodz\u0105 za pierwszym razem, kiedy nikt nie otwiera dodatkowego pull requestu, podczas gdy ten dziesi\u0105tek jest przetwarzany.<\/p>\n
Pomy\u015bl sobie, \u017ce jeste\u015b programist\u0105, kt\u00f3ry musi zd\u0105\u017cy\u0107 nacisn\u0105\u0107 przycisk \u201emerge\u201d jako pierwszy, poniewa\u017c je\u015bli to zrobi s\u0105siad, to trzeba b\u0119dzie czeka\u0107, a\u017c wszystkie buildy przejd\u0105 od nowa... Nie, tak nie mo\u017ce by\u0107, to powa\u017cnie spowolni rozw\u00f3j.<\/p>\n
Drugi mo\u017cliwy spos\u00f3b: zbiera\u0107 pull request po code review. <\/strong>To znaczy, otwierasz pull request, zbierasz potrzebn\u0105 liczb\u0119 akceptacji od koleg\u00f3w, poprawiasz to, co trzeba, a nast\u0119pnie uruchamiasz buildy. Je\u015bli s\u0105 udane, pull request scalany jest z develop. W tym przypadku nie ma dodatkowych ponownych uruchomie\u0144, ale znacznie zwalnia to informacj\u0119 zwrotn\u0105. Jako programista, otwieraj\u0105c pull request, od razu chc\u0119 widzie\u0107, czy on si\u0119 skompiluje. Na przyk\u0142ad, je\u015bli jaki\u015b test nie przeszed\u0142, musz\u0119 go szybko naprawi\u0107. W przypadku op\u00f3\u017anionego builda zwalnia to informacj\u0119 zwrotn\u0105, a tym samym ca\u0142o\u015bciowy rozw\u00f3j. To tak\u017ce nam nie odpowiada\u0142o.<\/p>\nW rezultacie zosta\u0142a tylko trzecia opcja \u2014 wymys\u0142a\u0107<\/strong>. Wszystkie nasze kody, wszystkie nasze \u017ar\u00f3d\u0142a s\u0105 przechowywane w repozytorium na serwerze Bitbucket. W zwi\u0105zku z tym musieli\u015bmy opracowa\u0107 wtyczk\u0119 do Bitbucket.<\/p>\n![\"Ewolucja](\"\/wp-content\/uploads\/2019\/04\/5e4b1f770ea1a3449b616c3101640294.jpg\")
\n
\nTen wtyczka redefiniuje mechanizm \u0142\u0105czenia pull request\u00f3w. Rozpocz\u0119cie przebiega standardowo: otwierany jest PR, uruchamiane s\u0105 wszystkie kompilacje, przeprowadzana jest recenzja kodu. Jednak po pomy\u015blnym przej\u015bciu recenzji kodu, gdy deweloper zdecyduje si\u0119 nacisn\u0105\u0107 \u201emerge\u201d, wtyczka sprawdza, w odniesieniu do jakiego stanu develop uruchamiano kontrole. Je\u015bli po kompilacjach develop zd\u0105\u017cy\u0142 si\u0119 zaktualizowa\u0107, wtyczka nie pozwoli na po\u0142\u0105czenie takiego pull requestu z g\u0142\u00f3wn\u0105 ga\u0142\u0119zi\u0105. Po prostu ponownie uruchomi kompilacje w odniesieniu do \u015bwie\u017cego develop.<\/p>\n
![\"Ewolucja](\"\/wp-content\/uploads\/2019\/04\/0edee880e1f2d286a0c64033103ac136.jpg\")
\n
\nW naszym przyk\u0142adzie z konfliktuj\u0105cymi zmianami takie kompilacje nie przejd\u0105 z powodu b\u0142\u0119du kompilacji. W zwi\u0105zku z tym deweloper funkcji B b\u0119dzie musia\u0142 poprawi\u0107 kod, uruchomi\u0107 testy, a wtedy wtyczka automatycznie zastosuje pull request.<\/p>\n
Przed wdro\u017ceniem tej wtyczki mieli\u015bmy \u015brednio 2,7 uruchomienia testu na jeden pull request. Z wtyczk\u0105 jest ich 3,6. To by\u0142o dla nas satysfakcjonuj\u0105ce.<\/p>\n
Warto zauwa\u017cy\u0107, \u017ce ta wtyczka ma wad\u0119: uruchamia kompilacj\u0119 tylko jeden raz. Oznacza to, \u017ce wci\u0105\u017c pozostaje ma\u0142e okno, przez kt\u00f3re do develop mog\u0105 trafi\u0107 konfliktuj\u0105ce zmiany. Ale prawdopodobie\u0144stwo tego jest niskie, i zdecydowali\u015bmy si\u0119 na ten kompromis mi\u0119dzy liczb\u0105 uruchomie\u0144 a prawdopodobie\u0144stwem awarii. Przez dwa lata zdarzy\u0142o si\u0119 to tylko raz, wi\u0119c pewnie nie bez powodu.<\/p>\n
Na napisanie pierwszej wersji wtyczki do Bitbucket zaj\u0119\u0142o nam dwa tygodnie. <\/em><\/strong><\/p>\nNowe testy<\/h3>\n
\nW mi\u0119dzyczasie nasz zesp\u00f3\u0142 nadal rasta\u0142. Pojawia\u0142y si\u0119 nowe testy.<\/p>\n
Pomy\u015bleli\u015bmy: po co naprawia\u0107 b\u0142\u0119dy, skoro mo\u017cna je zapobiega\u0107? Dlatego wdro\u017cyli\u015bmy statyczn\u0105 analiz\u0119 kodu<\/strong>. Zacz\u0119li\u015bmy od linta, kt\u00f3ry wchodzi w sk\u0142ad Android SDK. Ale w tym czasie w og\u00f3le nie potrafi\u0142 pracowa\u0107 z kodem Kotlin, a ju\u017c 75% aplikacji by\u0142o napisane w Kotlin. Dlatego do linta dodano wbudowane kontrole Android Studio.<\/strong><\/p>\nDo tego musieli\u015bmy si\u0119 nieco wysili\u0107: wzi\u0105\u0107 Android Studio, zapakowa\u0107 j\u0105 w Dockerze i uruchomi\u0107 w CI z wirtualnym monitorem, aby my\u015bla\u0142a, \u017ce jest uruchomiona na prawdziwym laptopie. Ale to dzia\u0142a\u0142o.<\/p>\n
R\u00f3wnie\u017c w tym czasie zacz\u0119li\u015bmy pisa\u0107 wiele test\u00f3w instrumentalnych<\/strong> i wdro\u017cyli\u015bmy testowanie zrzut\u00f3w ekranu<\/strong>To jest sytuacja, w kt\u00f3rej generowany jest wzorcowy zrzut ekranu dla okre\u015blonego ma\u0142ego widoku, a test polega na robieniu zrzutu ekranu z tego widoku i bezpo\u015brednim por\u00f3wnywaniu go z wzorcem pixel po pixelu. Je\u015bli wyst\u0119puje r\u00f3\u017cnica, oznacza to, \u017ce gdzie\u015b nast\u0105pi\u0142 b\u0142\u0105d w uk\u0142adzie lub co\u015b jest nie tak w stylach.<\/p>\nJednak testy instrumentacyjne i testy zrzut\u00f3w ekranu musz\u0105 by\u0107 uruchamiane na urz\u0105dzeniach: na emulatorach lub na rzeczywistych urz\u0105dzeniach. Bior\u0105c pod uwag\u0119, \u017ce test\u00f3w jest du\u017co i s\u0105 cz\u0119sto wykonywane, potrzebna jest ca\u0142a farm\u0119. Ustawianie w\u0142asnej farmy jest zbyt pracoch\u0142onne, dlatego znale\u017ali\u015bmy gotowe rozwi\u0105zanie \u2014 Firebase Test Lab.<\/p>\n
Firebase Test Lab<\/h3>\n
\nZosta\u0142 wybrany, poniewa\u017c Firebase to produkt Google, co znaczy, \u017ce powinien by\u0107 niezawodny i ma\u0142o prawdopodobne, \u017ce kiedykolwiek zniknie. Ceny s\u0105 przyst\u0119pne: 5 USD za godzin\u0119 pracy rzeczywistego urz\u0105dzenia, 1 USD za godzin\u0119 pracy emulatora.<\/p>\n
Wdro\u017cenie Firebase Test Lab w naszym CI zaj\u0119\u0142o nam oko\u0142o trzech tygodni.<\/em><\/strong><\/p>\nJednak zesp\u00f3\u0142 nadal r\u00f3s\u0142, a Firebase, niestety, zaczyna\u0142 nas zawodzi\u0107. W tym czasie nie mia\u0142 \u017cadnego SLA. Czasami Firebase zmusza\u0142 do czekania, a\u017c uwolni si\u0119 potrzebna ilo\u015b\u0107 urz\u0105dze\u0144 do test\u00f3w, a nie zaczyna\u0142 ich wykonywa\u0107 od razu, jak tego chcieli\u015bmy. Czekanie w kolejce zajmowa\u0142o do p\u00f3\u0142 godziny, co jest bardzo d\u0142ugo. Testy instrumentacyjne by\u0142y uruchamiane przy ka\u017cdym PR, a op\u00f3\u017anienia znacznie spowalnia\u0142y rozw\u00f3j, a potem przychodzi\u0142 jeszcze rachunek za miesi\u0105c z okr\u0105g\u0142\u0105 sum\u0105. Ostatecznie postanowili\u015bmy zrezygnowa\u0107 z Firebase i stworzy\u0107 w\u0142asne rozwi\u0105zanie, skoro zesp\u00f3\u0142 wystarczaj\u0105co ur\u00f3s\u0142.<\/p>\n
Docker + Python + bash<\/h3>\n
\nWzi\u0119li\u015bmy dockera, umie\u015bcili\u015bmy w nim emulatory, napisali\u015bmy prosty program w Pythonie, kt\u00f3ry w odpowiednim momencie uruchamia potrzebn\u0105 ilo\u015b\u0107 emulator\u00f3w w odpowiedniej wersji, a gdy trzeba, je zatrzymuje. I oczywi\u015bcie kilka skrypt\u00f3w bash \u2014 gdzie\u017cby bez nich?<\/p>\n
Na stworzenie w\u0142asnego \u015brodowiska testowego potrzebowali\u015bmy pi\u0119ciu tygodni.<\/em><\/strong><\/p>\nW rezultacie na ka\u017cdy pull request przypada\u0142 obszerny, blokuj\u0105cy po\u0142\u0105czenie, lista kontroli:<\/p>\n
\n- Budowanie APK;<\/li>\n
- Testy Junit;<\/li>\n
- Lint;<\/li>\n
- Kontrole Android Studio;<\/li>\n
- Testy instrumentacyjne;<\/li>\n
- Testy zrzut\u00f3w ekranu.<\/li>\n<\/ul>\n
\nTo zapobiega\u0142o wielu mo\u017cliwym awariom. Technicznie wszystko dzia\u0142a\u0142o, ale programi\u015bci narzekali, \u017ce czekanie na wyniki trwa zbyt d\u0142ugo.<\/p>\n
Zbyt d\u0142ugo \u2014 to ile? Wyeksportowali\u015bmy dane z Bitbucket i TeamCity do systemu analizy i odkryli\u015bmy, \u017ce \u015bredni czas oczekiwania wynosi 45 minut<\/strong>. To znaczy, \u017ce programista, otwieraj\u0105c pull request, \u015brednio czeka na wyniki budowy 45 minut. Moim zdaniem to bardzo du\u017co i tak pracowa\u0107 nie mo\u017cna.<\/p>\nOczywi\u015bcie, postanowili\u015bmy przyspieszy\u0107 wszystkie nasze budowy.<\/p>\n
Przyspieszamy<\/h2>\n
\nZauwa\u017caj\u0105c, \u017ce cz\u0119sto budowy czekaj\u0105 w kolejce, najpierw dokupili\u015bmy sprz\u0119tu<\/strong> \u2014 intensywne rozwijanie to najprostsza opcja. Budowy przesta\u0142y czeka\u0107 w kolejce, ale czas oczekiwania zmniejszy\u0142 si\u0119 tylko nieznacznie, poniewa\u017c niekt\u00f3re kontrole same w sobie trwaj\u0105 bardzo d\u0142ugo.<\/p>\nUsuwamy zbyt d\u0142ugie sprawdzenia<\/h3>\n
\nNasz Continuous Integration m\u00f3g\u0142 wychwyci\u0107 takie typy b\u0142\u0119d\u00f3w i problem\u00f3w.<\/p>\n
\n- Nie kompiluje si\u0119<\/strong>. CI mo\u017ce wychwyci\u0107 b\u0142\u0105d kompilacji, gdy z powodu konfliktuj\u0105cych zmian co\u015b si\u0119 nie kompiluje. Jak ju\u017c wspomnia\u0142em, wtedy nikt nie mo\u017ce nic skompilowa\u0107, rozw\u00f3j staje w miejscu, a wszyscy si\u0119 denerwuj\u0105.<\/li>\n
- B\u0142\u0105d w zachowaniu<\/strong>. Na przyk\u0142ad, gdy aplikacja si\u0119 kompiluje, ale podczas klikni\u0119cia przycisku si\u0119 zawiesza, lub przycisk w og\u00f3le nie reaguje. To \u017ale, poniewa\u017c taki b\u0142\u0105d mo\u017ce dotrze\u0107 do u\u017cytkownika.<\/li>\n
- B\u0142\u0105d w uk\u0142adzie<\/strong>. Na przyk\u0142ad, przycisk dzia\u0142a, ale przesun\u0105\u0142 si\u0119 o 10 pikseli w lewo.<\/li>\n
- Wzrost d\u0142ugu technicznego<\/strong>.<\/li>\n<\/ul>\n
\nZerkaj\u0105c na t\u0119 list\u0119, zrozumieli\u015bmy, \u017ce krytyczne s\u0105 tylko dwa pierwsze punkty. Takie problemy chcemy wychwytywa\u0107 w pierwszej kolejno\u015bci. B\u0142\u0119dy w uk\u0142adzie s\u0105 wykrywane na etapie przegl\u0105du projekt\u00f3w i w\u00f3wczas \u0142atwo je naprawi\u0107. Praca z d\u0142ugiem technicznym wymaga osobnego procesu i planowania, dlatego postanowili\u015bmy nie sprawdza\u0107 go w pull requestach.<\/p>\n
Na podstawie tej klasyfikacji przetrz\u0105sn\u0119li\u015bmy ca\u0142\u0105 list\u0119 sprawdze\u0144. Skre\u015blili\u015bmy Lint<\/strong> i przenie\u015bli\u015bmy jego uruchamianie na noc: po prostu, aby dostarcza\u0142 raport o liczbie problem\u00f3w w projekcie. Z d\u0142ugiem technicznym postanowili\u015bmy pracowa\u0107 osobno, a zrezygnowali\u015bmy ca\u0142kowicie z kontroli Android Studio<\/strong>. Android Studio w Dockerze do uruchamiania inspekcji brzmi interesuj\u0105co, ale sprawia wiele problem\u00f3w w utrzymaniu. Ka\u017cda aktualizacja wersji Android Studio to walka z niejasnymi b\u0142\u0119dami. R\u00f3wnie\u017c trudno by\u0142o utrzyma\u0107 testy zrzut\u00f3w ekranu, poniewa\u017c biblioteka nie dzia\u0142a\u0142a zbyt stabilnie i zdarza\u0142y si\u0119 fa\u0142szywe alarmy. Testy zrzut\u00f3w ekranu usuni\u0119to z listy sprawdze\u0144<\/strong>.<\/p>\nW rezultacie zosta\u0142y nam:<\/p>\n
![\"Ewolucja](\"\/wp-content\/uploads\/2019\/04\/b283cfd7772d8f479be0754ebbe51b19.jpg\")