Ga naar hoofdinhoud

Build Process

De opdracht voor 'Build Process' is een GitHub Actions pipeline in te richten voor Continuous Integration (CI) zoals in het CNP project. Als het goed is, is dit is geen simpele copy-paste voor Spring Boot en React die je daar gebruikte, maar een pipeline voor build+test van een nieuwe technologie zoals Python, .NET, Kotlin, Laravel of een andere doelarchitectuur waarin je werkt in opdracht van de opdrachtgever/projectbegeleider of een nieuwe back-end en/of front-end technologie (taal of framework) die goed bij jullie domeinprobleem past.

Nu ook CD naast CI?​

Als je — in overleg — toch in Spring Boot/React werkt dan is het goed om voor uitdaging voor Build Process de CI stappen in je pipeline nu ook uit te breiden met een CD stap: Continuous Deployment. Dit is typisch de laatste stap in een pipeline, als de linting, build, unit test en integratie tests allemaal slagen.

Je kan de CD stap OOK toevoegen als extra uitdaging, omdat je nog een spike onderzoek nodig hebt of het veel meerwaarde heeft voor je opdrachtgever (of natuurlijk als je begeleider gewoon aangeeft dat je dit moet doen).

Hoewel dit even tijd kost, kan het op de lange termijn veel 'goedkoper' zijn doordat je stabiele demo/oplever omgeving hebt en grotere ontwikkel 'velocity' hebt door een kortere iteratie tijd (zie figuur 3). Daarnaast is een demo op iets andere omgeving dan localhost ook een plus bij je eindpresentatie.

Wheel, no time

Figuur 3: No time for it, or waste time not doing it? (Redo by ChatGPT; originele plaatje: Everlöf 2022)

Wel heb je voor Deploy natuurlijk ook een productie omgeving nodig. Dit kan een cloud omgeving zijn, zoals AWS, Azure of Google Cloud. Maar vanuit de HAN stellen we ook een VPS beschikbaar...

VPS met Coolify of andere PaaS​

Je kunt een Virtual Private Server (VPS) van de HAN aanvragen bij docent Bart van der Wal. Deze is dus gratis. Met deze VPS kun je via secure shell (ssh) een connectie maken. Deze server draait Ubuntu distributie van Linux. Hierop kun je met apt en/of docker de benodigde middelware/infrastructuur installeren om je applicatie deployen en draaien. Bijvoorbeeld een webserver, database. Eventueel zou je een (web) front-end op een technologie als Nginx voor performance, load balancing en uitbreidbaarheid voor bijvoorbeeld DDOS beveiliging.

Een tip/alternatief is ook een moderne tool/Platform as a Service (PaaS) op deze VPS te zoeken te onderzoeken zoals bijvoorbeeld Coolify. Je onderzoekt deze in een spike. Coolify vergelijkt men wel met Cloud diensten als Heroku of Vercel. Deze laatste zijn wel betaalde diensten, of in ieder geval freemium, dus met snel meerkosten of credit card eis.

Build process en Walking Skeleton​

Je Build Proces is een pipeline voor je Walking Skeleton. Hoewel deze twee eindproducten heel veel met elkaar te maken hebben, zijn ze niet hetzelfde. De 'Walking Skeleton' is een werkend prototype van je eindproduct. Het 'Build Process' is een geautomatiseerde pipeline, zodat je snel kunt itereren en nieuwe funtionaliteiten kunt opleveren.

Zo zorg je voor feitelijk voor een kortere 'Time to Market' hebt (TTM), wat soms een kritieke factor is voor een web/digitaal product. Zie de 'Customer Value Chain' in Figuur 1.

The customer Value Chain

Figuur 1: Time to Market is belangrijk voor veel innovatieve producten, zoals Software Producten (bron: Sketchplanations.com/Hey 2017)

De naieve kijk op Time to Market is dat je product heel snel, zeg in een paar weken of maanden op de markt krijgt. In moderne software praktijk zijn beta releases echter heel gangbaar, en kun je ook een 'Time to Market' hebben van 1 jaar, in ieder geval voor je 'Minimally Lovable Product', maar dat je wel eerder een 'Minimally Marketable' of 'Minimum Viable' Product kunt afleveren en daarop 10x kunt itereren. Zodat je dus in die tijd ook 10x meer feedback kunt krijgen van je gebruikers. Dit is ook een goede reden zijn om na je Elaboratie fase al een 'Walking Skeleton' te hebben, waarop je tijdens Construction veel sneller kunt itereren.

Van Integration naar Deployment​

Deze opdracht is deels een vervolg op de 'Integration' workshop uit het Semester 1 Project (CNP).

Die workshop ging alleen over CI gedeelte uit CI/CD pipelines; Continuous Integration. Het ligt in de lijn om na 'Continuous Integration' de lijn door te trekken naar 'Continuous Deployment'. Maar in ENE richt je je op elaboratie fase, waar in de klassieke 'software lifecycle' het nog lang is voor oplevering/naar productie gaan.

In DevOps, wat een voortzetting is van de Agile werkwijze verlaat je deze waterval visie. En het is sowieso voor je Walking Skeleton nodig enige integratie te bereiken. En een goede deployability (het naar een productie omgeving zetten) is ook een mogelijke risico/onzekerheid als je werkt met nieuwere technologieen. Afhankelijk van je project doel is het goed om ook in de elaboratie fase al aandacht te hebben voor 'Continuous Deployment'.

Dit sluit aan bij het concept van 'Shift left' uit DevOps. Het vroegtijdig (dus meer naar links in een grafiek met tijd op de x-as) kijken naar issues als deployability, security, performance, etc. Dit is ook een van de redenen dat je in de constructiefase een build proces op moet zetten.

Build Process

Figuur 2: Build proces en shift left in ENE. Kortom een mooie uitdaging: deploy je walking skeleton! (plaatje ChatGPT)

In de Elaboratie richt je je op het uitsluiten van risico's. Een risico dat er bij ICT projecten is dat het eindproduct niet bruikbaar is, als je alleen focust op de waardevolste functionaliteiten, maar niet de lijm functionaliteiten hebt uitgewerkt. Dit is ook een van de redenen dat je een User Story map maak met een backbone waarin wel deze lijm functionaliteiten (activitities) voor een (minimum) viable product (MVP).

Echter in een elaboratie fase hoef je nog niet tot een MVP te komen. Als je deze lijm functionaliteiten maar in kaart hebt voor latere constructie fase.

"Effectiveness is doing the right thing. Efficiency is doing the thing right." - Peter Drucker

Bronnen​