Een modern ontwikkeltraject

Gepubliceerd op 25-07-2018

Software bouwen kan op 1001 manieren, en misschien nog wel meer. We doen graag een boekje open over hoe wij denken dat het ideale ontwikkeltraject er uit zou moeten zien. Niet dat het per sé de beste manier is (maar wij vinden van wel 😉). Dit artikel beschrijft het technische en communicatieve gedeelte van een ontwikkeltraject.

Versiebeheer & CI/CD*

Versiebeheer is eigenlijk een must voor softwareontwikkeling. Laten we het hier even hebben over Git, een bepaalde vorm van versiebeheer. Met Git is het mogelijk om met meerdere ontwikkelaars aan een project te werken, achteraf in te zien wie welke regel code heeft geschreven en om code reviews mogelijk te maken.

We hebben het bij Freave zo ingericht dat wanneer we aan een project voor een klant werken de code altijd in een “repository” (emmer met code) zit. Wanneer een ontwikkelaar aan een specifieke functie gaat werken maakt hij hiervoor een “branch” aan, een vertakking van de code die er al staat. Als de ontwikkelaar klaar is met bouwen doet hij een “merge request”, een verzoek om de geschreven code in het origineel te voegen. Onze Continuous Integration (CI) tool gaat de code vervolgens op een aantal codestandaarden controleren, zoals PSR.

Het “merge request” wordt vervolgens door een andere ontwikkelaar bekeken en akkoord bevonden - of niet. Iedereen kan natuurlijk wel eens iets over het hoofd zien. Als de code vervolgens wordt “gemerged” pakt onze Continuous Deployment (CD) tool het verder op. Die zorgt er voor dat de code direct naar de staging-omgeving van de klant gaat, die er meteen mee kan testen.

Communicatie & planning

Communicatie is bij softwareontwikkeling ontzettend belangrijk. Het is van belang vanaf het eerste gesprek de wensen van de klant zo goed mogelijk te begrijpen en te implementeren. Soms komt het echter voor dat iets toch nét ietsje wordt gebouwd dan de klant had voorzien. Goede communicatie is dan van belang om het snel op te lossen.

Bij Freave werken we met SCRUM, een Agile ontwikkelmethode. Ons werk delen we op in zogenaamde “sprints”, perioden waarin we aan bepaalde taken werken. Die sprints duren meestal 2 weken. Elke ochtend begint met een standup. Dan bespreken we wat we sinds de vorige standup hebben gedaan, wat we die dag gaan doen en welke risico’s er zijn.

Alle taken in zo’n sprint zetten we in JIRA - een online tool om o.a. SCRUM-borden in te maken. Onze klant kan ook op dit bord kijken om precies te zien waar aan wordt gewerkt en wat al af is. Alles wat af is komt automatisch op de staging omgeving, de klant kan er dan meteen mee gaan testen. Eventuele problemen kunnen we dan in de kiem smoren.

Dus,

Niet

  • Maanden bouwen en dan opleveren
  • Handmatig bestanden uploaden naar een webserver
  • Weinig communiceren over de voortgang van het project
  • Na afloop de code "over de schutting gooien"
  • Tab vs. spaces discussies voeren

Wel

  • Meerdere tussenopleveringen
  • Continuous Deployment inzetten voor automatische deployments
  • Klant realtime inzicht geven in voortgang (met bijv. JIRA)
  • Heldere documentatie meeleveren om gemakkelijke overdracht te bevorderen
  • Gebruikmaken van codestandaarden

Het is natuurlijk lang niet alles wat een ontwikkeltraject succesvol maakt, maar het helpt je wellicht wel een stukje op weg. En wil je het zelf ervaren? Neem dan eens contact met ons op om eens over je softwareproject te praten.

Terminologie

Continuous Integration
(Onder ander) het automatisch testen & bouwen van code. Bijvoorbeeld om te testen of deze voldoet aan de PSR-codestandaard.

Continuous Deployment
Het automatisch deployen van code naar een omgeving. Continuous Deployment verschilt van Continuous Delivery in dat het eerstgenoemde automatisch deployed op het moment dat code getest & gemerged is, waar het laatstgenoemde menselijke interactie vereist (of een schema).