Continuous integration pro tvorbu mobilních aplikací
V dnešním článku vám dáme nahlédnout pod pokličku naší infrastruktury. Proč? Protože jsme na ni pyšní a rádi se s ní pochlubíme světu. Zároveň nás potěší, když se tento článek stane inspirací pro ostatní, kteří třeba právě teď podobné problémy řeší.
CI v Ackee
Pojem Continuous Integration (CI) je dnes v IT již celkem zažitý. Jedná se o sadu nástrojů a postupů, které urychlují vývoj, testují software a zároveň provedou nasazení aplikace a to automaticky několikrát denně. Pokud se budeme bavit o vývoji mobilních aplikací, tak nejméně oblíbenou činností snad každého vývojáře je zasílání testovacích buildů a testování aplikací oproti všem dostupným prostředím. Vývojáři v Ackee jsou od tohoto odprošteni již několik měsíců a s výsledkem jsou spokojení nejen oni, ale také testeři, projektoví manažeři a především klienti. Příjemným benefitem je také finanční úspora v řádu desítek tisíc korun. Jak jsme toho dosáhli?
V první řadě je potřeba si uvědomit, že mnoho vývojářů při tvorbě mobilní aplikace používá notebook, který je sice výkonný, ale oproti nadupanému stolnímu počítači stále zaostává. Takže první co potřebujeme, je Continuous Integration server, který využíváme i pro tvorbu webů, o čemž jste si mohli přečíst v předchozím článku.
Jako náš CI server využíváme Jenkins, který bylo potřeba si nakonfigurovat a nainstalovat na něj například Android SDK plugin. Poté jsme museli vytvořit zcela nové šablony projektů jak pro iOS tak pro Android, aby byly projekty jednoduše kompilovatelné z příkazové řádky a výsledné binární a dSYM soubory byly jednoduše identifikovatelné. V další fázi jsme museli vymyslet odlišná schémata pro vývojářský build, testovací build a produkční build, aby Jenkins ve správnou chvíli vyprodukoval správný soubor.
Za vším hledej GIT
Na počátku všech úkonů je GIT, respektive příchozí commit do vybraného repozitáře. Jenkins podle větve rozhodne, o jakou verzi aplikace se jedná a dle toho zvolí vhodné parametry pro build.
GIT využíváme i k samotnému verzování buildů. Původně jsme chtěli pro identifikaci konkrétní verze využívat interní Jenkins Job Number, což by ale vnášelo velké množství nekonzistence mezi vývojářské, testovací a klientské verze, jelikož má každá tato verze vlastní Jenkins Job. K číslování verzí proto využíváme počet commitů v dané větvi. Tato technika přináší jednu nevýhodu, protože takto číslované verze se mezi sebou liší zpravidla o číslo větší než 1. Tento drobný nedostatek je pro nás ale naprosto zanedbatelný a navenek to navíc působí, že jsme mnohem pracovitější :)
Co má Jenkins na práci
V momentě, kdy Jenkins stáhne všechny zdrojové soubory, provede nejprve kontrolu a stáhne všechny závislosti, které se změnily. Poté provede automatické testy s výstupem ve formátu JUnit, které Jenkins umí prezentovat v přehledných grafech. Pokud testy selžou, práce skončí a „viník“ dostane vynadáno skrze náš interní chat. V opačném případě úkon pokračuje a spustí se build s danou konfigurací. Jenkins výsledné soubory poté nahraje na distribuční web našim testerům a projektovému manažerovi, který může následně odeslat danou verzi přímo klientovi.
Za tím vším se neskrývá žádná magie, pouze hodně drobností, které do sebe krásně zapadají a výsledkem je pracovní proces, který nezatěžuje vývojáře a navíc každou verzi otestuje, rozešle (klient má automaticky přístup k novým verzím každý den, aniž by si o něj musel psát) a hlavně šetří čas a peníze!
P.S. Také naše distribuční infrastruktura je velice úzce napojena na náš CI server a příští článek bude tedy věnován právě jí.
