fdtrck- Fase 4: Continuous Deployment

Het is geen geheim dat developers ervan houden om dingen te automatiseren. Waarom dingen handmatig doen als een computer ook het werk voor je kan doen? Dit klinkt misschien nogal lui en dat is in alle eerlijkheid wel een beetje waar (meer tijd om te spelen met de honden op kantoor, toch?). Maar we willen ook graag focussen op de andere voordelen van automatisering, waaronder security, stabiliteit en snelheid.

Van backlog naar productie

Hoe belandt een nieuwe feature in een productie app? Hiervoor volgen we altijd min of meer hetzelfde proces (er zijn hier en daar wat keuzes te maken afhankelijk van het specifieke project). Ten eerste is onze onze code version controlled. Dit betekent dat we meerdere verschillende versies van de code base (ook wel commits genoemd, gestructureerd in branches) kunnen creëren, vergelijken en samenvoegen. In het geval dat we een foutje maken, kunnen we een eerdere versie terugrollen. Eén van deze versies is de huidige productie versie. Alle versies worden bewaard in de repository.

Integratie

Stel, een developer pakt een ticket van de backlog (dit is dev-taal voor het oppakken van een taak op de todo lijst). De developer maakt een kopie van de code en gaat hiermee aan de slag. Welke aanpassing ze ook maken, de nieuwe code moet geïntegreerd worden met de bestaande code. Dit betekent dat we er zeker van moeten kunnen zijn dat de code nog steeds werkt wanneer we deze samenvoegen. Het doel van de integratie is om nieuwe versies van de code te leveren aan de repository. Soms hebben we een paar pogingen nodig om een nieuwe feature te perfectioneren. Als de code gebouwd is en alle testen geslaagd zijn, kunnen we de nieuwe aanpassingen samenvoegen. 

Deployment

We nemen één of meerdere geïntegreerde veranderingen en voegen deze samen tot de totaalversie die we willen publiceren. Daarbij zijn er ook belangrijke QA processen die we nu niet zullen bespreken. Eerst testen we of alles nog werkt zoals het in de final versie zou moeten werken. Dan moet de code klaargemaakt worden voor deployment. Voor fdtrck betekent dit dat we een production build moeten maken voor elk platform waarop we willen publiceren. Deze builds worden vervolgens naar de production environments gestuurd (de app stores en de web server). 

Er zijn verschillende deployment environments:

• Development: alleen voor internal testing. Deze environment werkt vaker niet dan wel. Soms hebben we meerdere van deze environments. 
• Staging: hier testen we of de stabiele versies ook daadwerkelijk stabiel zijn. Het is gebruikelijk dat hier de aanpassingen worden geaccepteerd door onze klanten of door een product owner. 
• Production: dit is de real deal. Hier kunnen de users inloggen, worden App Store reviews geschreven en wordt gevoelige data verwerkt. 

Van handmatig naar continu

Natuurlijk kunnen de integratie en deployments handmatig worden gedaan, en soms heeft dit handmatig ingrijpen nodig. Maar zou het niet cool zijn om te automatiseren? Ja, dat zou zeker cool zijn. Dit is niet iets wat we zelf hebben bedacht: automatische integratie en deploys worden veel gebruikt en zijn beter bekend onder Continuous Integration en Continuous Deployment (CI/CD). CI/CD probeert het handmatige werk rondom integratie en deploying tot een minimum te beperken. 

Hier een aantal voorbeelden waarom CI/CD zo cool is:

• Snelheid: Dit is een no-brainer. Een scripted deploy is simpelweg sneller dan een developer. Ook kun je vaker deployen, dus is het niet meer nodig om een hoop te saven voor een enkele deploy-day. 
• Stabiliteit: Computers winnen van mensen als het gaat om het herhaaldelijk en consistent uitvoeren van exact dezelfde taken. Mensen, vooral aan het einde van de werkdag, kunnen nog wel eens een stap te vergeten of iets door elkaar te halen. Ook starten computers iedere keer met een schone omgeving waardoor er geen problemen ontstaan met eerdere versies.
• Security: Als het meeste werk is geautomatiseerd, zorgt dit ervoor dat er minder devops engineers toegang hoeven te hebben tot de productie environment, wat weer zorgt voor extra beveiliging. Ook is het mogelijk om iedere deploy te checken op mogelijke beveiligingsrisico’s in de packages die we gebruiken.

CI/CD in fdtrck

Voor fdtrck hebben we gebruik gemaakt van belangrijke systemen voor de CI/CD pipelines. De eerste is Gitlab (een nieuwe Nederlandse unicorn), waarin we onze code managen en de QA doen. Voor de geautomatiseerde deploys, werken we met Bitrise. Voor andere projecten werken we ook met Gitlab voor de deploys, maar voor apps is er een Apple computer nodig om iOS versies te bouwen. Dit is iets wat Bitrise perfect voor ons oplost. 

Bitrise is ideaal om mee te werken wanneer je wat werk uit handen wil hebben. Een andere dienstverlener die de servers voor je up-to-date houdt. Bitrise maakt het makkelijk om mee te werken door middel van een stappenplan wat je zelf kan maken en wijzigen. Kopieer eerst de code, bouw deze op en upload deze naar de App Store en Playstore. Als je kennis over CI/CD beperkt is, zal Bitrise hoogstwaarschijnlijk een goede match zijn. Bitrise beheert je sleutels om te ondertekenen, zodat je ze niet apart hoeft op te slaan. Je kan ervoor zorgen dat ze worden gedownload van een beveiligde server en naar je map worden gekopieerd, en vervolgens doorgaan om Bitrise jou builds voor je te laten ondertekenen. Door teamrollen te verdelen resulteert dit uiteindelijk in een betere beveiliging, je kunt namelijk instellen wie toegang heeft tot verschillende apps. Door middel van workflows is het gemakkelijk om fouten te vinden en op te lossen voordat ze naar de App Store en Play Store worden gepusht. Bitrise neemt je werk uit handen, efficiënt en noob vriendelijk.

Samenvattend

Vooral wanneer we werken aan een code met meerdere developers, kan de integratie van een nieuwe code zorgen voor veel extra werk. Door te werken met geautomatiseerde integratie en deployment scripts, die een overdaad aan automatische tests bevatten, kunnen we snel leveren, zijn we betrouwbaar en veilig. CI/CD is zo goed, dat we het zelfs aandurven om te deployen op vrijdagen.