Codemagic.io i Flutter – połącz swój projekt z CI/CD – part 2
Kontynuujemy nasza przygodę z CI/CD. Poprzednią część znajdziesz tutaj.
W tym poście dowiesz się między innymi jak:
- ustawić automatyczne budowanie aplikacji podczas pushowania nowego kodu na branch’a
- podzielić workflow na debug i release
- dodać testy do procesu i ewentualne wstrzymać budowanie przy niepomyślnym wyniku
- udostępnianie aplikacji
Tak więc lecimy 🙂
Automatyczne budowanie aplikacji
Zwykle podpinając swój projekt do CI/CD chcemy, aby przy np. dodaniu nowej funkcjonalności czy wydaniu aplikacji do testowania towarzyszyło automatyczne budowanie aplikacji. Przydatna funkcjonalność, ze względu na to, że nie musimy za każdym razem wchodzić na platformę CI/CD i ręcznie odpalać całego procesu, albo co gorsza – robić tego przez IDE. Jak więc wygląda to na Codemagic?
- wchodzimy do ustawień klikając w koło zębate obok nazwy naszego projektu w dashboardzie
- otwieramy zakładkę Build triggers
Co my tu mamy?
- Miejsce na wpisanie wzoru lub nazwy branch’a np. develop, master lub *feature* (gdy chcemy, aby każdy branch, który ma w nazwie feature był budowane)
- Include/Exclude – To pole określa czy chcemy wyżej wymieniony wzór lub branch uwzględnić czy wykluczyć. Zwykle zostawiamy Include, ze względu na to, że zazwyczaj dodajemy zależności, w których chcemy, aby automatyczny build się wywołał.
- Source/Target – W tym przypadku ma to tylko zastosowanie przy Pull Request. Wybieramy tutaj czy „śledzonym” branch’em ma być branch źródłowy czy docelowy.
- Add pattern – do zapisania naszego wzorca (aby zapisać należy kliknąć ten przycisk przed naciśnięciem Save).
- Show pattern examples – pomocne przykłady jak chcemy pisać złożone wzory
- Automatic build triggering:
- Trigger on push – Budowanie odpala się za każdym push’em na dany pattern (przy commicie, merge itp).
- Trigger on pull request update – Budowanie odpala się przy otwarciu lub aktualizacji pull request’a. UWAGA! Ta opcja nie jest wspierana dla projektów z hostowanym repozytorium.
- Trigger on tag creation. – Budowanie odpala się za każdym razem, gdy ktoś utworzy tag, niezależnie od tego jakie wzory podaliśmy wcześniej.
Na potrzeby wpisu chciałbym utworzyć wzorzec dla branch’a master i wywoływać automatyczne budowanie w momencie jakiegokolwiek pushowania na ten branch.
Konfiguracja takiego procesu wygląda tak:
UWAGA! W momencie, gdy nie mamy praw administratora do projektu wymagane będzie dodania Webhook’a przez tegoż administratora. Opis jak to zrobić znajdziecie tutaj, w zakładce Webhooks.
Dzielenie workflow
Po co to w ogóle robić? W momencie, gdy mamy różne środowiska (dev,prod,stage) albo wersje debug i release aplikacji, chcemy, aby proces dla każdego budowania wyglądał inaczej.
Aktualnie nasz workflow nazywa się Default Workflow (można go zobaczyć w prawym górnym rogu w ustawieniach).
Zmieńmy tę nazwę klikając na niebieski tekst, wpisując Debug, zatwierdzając enterem. Super, aktualnie cała konfiguracja będzie dotyczyła wersji debug aplikacji. Przypuśćmy, że bazując na tym workflow chcemy utworzyć nowy workflow Release. Łatwo… wystarczy pod nazwą kliknąć Duplicate workflow i ustawić mu w taki sam sposób nazwę. Od teraz możemy w ustawieniach przypisywać zdarzenia wykonywane przy ścieżce Release. Analogicznie można je powielać dla środowisk dev, prod i stage.
Dodanie testów do procesu budowania
Jak widać na powyższym screenie, w danym workflow możemy ustawić testy. Zakładka intuicyjna i prosta jak każda. Domyślnie mamy zaznaczone, aby zatrzymać budowanie jeśli testy się nie powiodą. Jakie testy?
- Enable Flutter analyzer przeznaczony jest do testów kodu, czyli jeśli zapomnieliśmy średnika w linijce lub kod, który napisaliśmy spowodował wyciek pamięci to ten test nie zakończy się pomyślnie
- Enable Flutter test odpala testy jednostkowe i testy widgetów
- Enable Flutter Driver tests pozwala uruchomić testy integracyjne
Pod tymi checkbox’ami mamy domyślne komendy przypisane do danego testu. Dodatkowo przy Fluter Driver tests mamy opcję wyboru testu na urządzeniu. Wszystko łatwo i przyjemnie 🙂
Udostępnianie aplikacji
Nie od dzisiaj wiadomo, że ciężką pracą i napisaną przez nas aplikacją chcemy się pochwalić. W zakładce Publish znajdziemy kilka sposobów na udostępnianie aplikacji. Domyślną opcją jest powiadomienie na e-mail w momencie, gdy nasz build wykonał się (lub nie). Fajną opcją jest też integracja ze Slack’iem, która bardzo dobrze sprawdza się w zespole z testerami (i nie tylko). Ale czas na crème de la crème – publikowanie aplikacji na sklep Google Play i AppStore! Tak… można to robić z poziomu platformy Codemagic. Całość jednak wymaga najpierw podpisania aplikacji za równo Android, jak i iOS (które również jest wymagane podczas tworzenia aplikacji w wersji Release w zakładce Build). Jednak to jest temat na osobny wpis 🙂
Czy warto?
Warto – jeśli sam lub w małym teamie tworzysz aplikacje to jest to na pewno platforma godna polecenia. Są jednak oczywiście mankamenty w postaci opłacania usługi, ale 500min miesięcznie i 2 konta w darmowej wersji w zupełności wystarczają na początek. Wszystko co potrzebujesz znajduje się w Codemagic. Dla mnie zaletą było to, że w odróżnieniu od niektórych CI/CD, które nie posiadają wsparcia dla budowania aplikacji iOS, Codemagic pozwala na multiplatformową budowę i testy aplikacji. Zakładajcie konta i przetestujcie sami! Siema! 🙂
