Blog
Development

De luie programmeur, deel 1: continuous delivery van mobiele applicaties

-

Bij de aankondiging van elke tool die het leven van de ontwikkelaar makkelijker maakt, hoor je het zelfde cliché:

Developers should spend their time coding, not fighting their tools.

Vervolgens komt er dan een uitleg dat we ons moeten focussen op functionaliteit en dat de rest zo veel mogelijk geautomatiseerd moet worden. In de praktijk zie ik helaas nog te vaak dat we geen (efficiënt) gebruik maken van de middelen die we hebben. En dat is jammer, want een goede programmeur is lui, ongeduldig en trots.

In een serie blogposts wil ik hier wat dieper op ingaan. Te beginnen met: continuous delivery van mobiele applicaties.

Ja, maar…

De meest gebruikte argumenten die ik hoor wanneer ik vraag waarom er geen continuous integration (CI) of continuous delivery (CD) is ingericht zijn:

  • “Ja maar, het gaat handmatig ook prima.”

  • “Ja maar, het inrichten van een CD-omgeving loont niet bij een klein team want teveel overhead.”

..het gaat handmatig ook prima

Als voor een klant een app ontwikkeld wordt, begint dit vaak met een proof of concept. Tijdens deze fase is het vaak logisch dat er geen volledige CI/CD omgeving wordt ingericht. Echter, als het dan toch een serieus project dreigt te worden moet dit alsnog zo snel mogelijk gebeuren.

Omdat deze blog gaat over continuous delivery, laat ik de argumentatie voor Continuous integration  graag over aan Martin Fowler. Wat betreft CD zijn dit volgens mij de belangrijkste argumenten:

  • Er is bij handwerk altijd kans op menselijke fouten. Hoe zorgvuldig je ook te werk gaat, er is altijd kans dat je per ongeluk de verkeerde app hebt geüploadet. Of dat die ene app toch niet alfa naar bèta had mogen gaan.
  • Er is een veel snellere feedback loop. Zowel van de klant over de tussentijds opgeleverde functionaliteit als van de app store zelf (zo kan het bij Apple nog wel eens gebeuren dat er pas ná de het uploaden van de app nog feedback komt).
  • Het kost tijd om handmatig te uploaden. Uiteraard valt het wel mee om een keer een APK te uploaden in de Android-store. Maar als je dit elke week of elke twee weken doet, telt het stiekem aardig op.

En dat laatste item is een mooi bruggetje naar het volgende argument.

…het inrichten van een CD omgeving loont niet bij een klein team want te veel overhead

Dit is denk ik de meest hardnekkige mythe. Een manier om die onderuit te halen is om te laten zien hoe makkelijk het is om continuous delivery in te richten voor een Android-app. Dit ga ik doen met behulp van Fastlane.

Fastlane 🚀

Fastlane is een combinatie van verschillende open source tools waarmee een app gebouwd, getest en released kan worden. Fastlane biedt support voor zowel Android als iOS en heeft integraties met verschillende build servers als Jenkins, CircleCi, Bitrise, Microsoft Visual Studio Team Services (VSTS) en Travis CI.

De configuraties die nodig zijn voor het bouwen, testen en uitrollen van de applicatie komen te staan in een zogenaamde Fastfile. Hierin staan verschillende lanes gedefinieerd. Een lane beschrijft de stappen die uitgevoerd moeten worden in een bepaalde situatie.

Hier een voorbeeld van een Fastfile waarin een release-build van een Android-app wordt gedaan, geüploadet wordt naar de bèta-groep en vervolgens een bericht plaatst in een Slack-kanaal.

lane :beta do
  gradle(task: 'assemble', build_type: 'Release')
  upload_to_play_store(track: 'beta')
  slack(message: 'Successfully distributed a new beta build')
end

Om de app daadwerkelijk te kunnen deployen naar de app-store is er extra configuratie nodig. Deze geef je aan door (na het installeren van Fastlane) het volgende command uit te voeren in de root van je project:

Fastlane init

Tijdens het initiëren herkent fastlane dat het om een Android-app gaat en worden er om 2 dingen gevraagd:

  1. De package-naam van de app
  2. De ‘secret json file locatie’. Deze is te downloaden vanaf de playstore console.

Na het doorlopen van de initialisatie ben je klaar om uit te rollen! Om de bovenstaande beta-lane uit te voeren, moet je het volgende command invoeren:

Fastlane beta

Als je dit dan vervolgens integreert in je CI-systeem kan je precies aangeven in welke situatie welke lane uitgevoerd moet worden.

Plugins

Naast veel standaard functionaliteit, zoals we hierboven hebben gezien, zijn er ook nog honderden plugins beschikbaar die het CI-proces makkelijker maken. Zo is er bijvoorbeeld een plugin die de Android version code ophoogt. Ook is er met behulp van een plugin support voor Cordova.

En voor iOS?

Ook iOS-apps kunnen met Fastlane gebouwd en deployed worden naar iTunes connect. Om dit op te zetten moeten deze instructies gevolgd worden. Iets waar veel ontwikkelaars tegen aan lopen bij het bouwen van een iOS-app is de code signing. Fastlane weet dit, en geeft hier extra aandacht aan door verschillende strategieën aan te bieden voor code signing.

Tot slot

Zoals je ziet, is de investering klein en de winst groot. Dus ik zou zeggen: ga er mee aan de slag, kaart het aan bij je project manager of klant. En het hoeft niet met een big bang. Begin bijvoorbeeld met het automatisch deployen naar je testomgeving. Als je dan wat meer gevoel bij het proces krijgt kan je denken aan een volgende stap, zoals automatisch promoten naar bèta of productie.