Start-up graffiti

De manier waarop start-ups omgaan met technologie is de rode draad in hun definitie. Ze gebruiken technologie om een bepaald aspect van het leven anders aan te pakken dan voorheen. Ze denken out of the box. Dat betekent dat hun developers vaak ook op die manier werken en denken.

Misschien is het daarom dat start-ups vaak minder aandacht hebben voor de organisatie van development. Een aspect dat in een later stadium, als men niet oplet, voor grote uitdagingen kan zorgen en soms zelfs de mislukking van een schitterend idee met zich meebrengt. Net daarom gaat deze blogpost niet over development zelf, maar over het in goede banen leiden van development.

Ontwikkeling: Agile/Scrum

Start-ups hebben, meer nog dan andere bedrijven, bij ontwikkeling de verplichting/nood om snel iets te kunnen tonen dat functioneert. Het klassieke watervalontwikkelingsmodel is dan ook zelden bruikbaar, omdat er pas een ‘product’ is op het einde van de rit.

Agile development is beter geschikt. Er zijn heel wat andere methodologieën, maar uit ervaring weten wij dat agile en scrum het best werken voor start-ups. Bij de scrum-methodologie zie je immers quasi dagelijks vooruitgang. Heel handig om potentiële investeerders te overtuigen!

Bij een scrum ga je telkens opnieuw korte sprints doen,bijvoorbeeld op weekbasis. In het begin van de week definieer je wat er op het einde van de week klaar moet zijn om te evalueren. Dit gebeurt meestal in projectgroepen onder leiding van een scrum master en in nauwe betrokkenheid met de projectverantwoordelijke.

Een van de grote voordelen van scrum is dat er kort op de bal kan gespeeld worden. Als je een idee hebt, groeit dat vaak terwijl je er mee bezig bent. Scrum zorgt er ook voor dat je kan werken met voortschrijdend inzicht en dat je vlot kan aanpassen waar nodig. Niks dan voordelen dus? Neen, er is ook een behoorlijke uitdaging: de noodzaak aan constante uitwisseling en integratie van de ontwikkelde code bijvoorbeeld. Het antwoord op die uitdaging heet Continuous Integration (CI).

Integratie: Continuous Integration (CI)

Zoals de term zelf aangeeft, gaat het hier om het correct integreren van de code ontwikkeld door een team of zelfs meerdere teams van ontwikkelaars. Alles begint daarbij met de code repository. Dit is de centrale plaats waar alle code verzameld wordt. Die code repository wordt best beheerd door een Version Control System (VCS). In elk VCS kopieer je het stuk code waaraan je werkt (de branch of trunk) uit de centrale repository en plaats je het terug als je klaar bent.

Welke VCS je kiest, heeft natuurlijk te maken met de manier waarop je wil werken en in welke taal. VCS valt grotendeels uiteen in twee groepen: het client-server model en het distributed data model. In beide groepen heb je open source en proprietary (dus te betalen) systemen. Start-ups kiezen daarbij vaak voor open source systemen, deels omdat ze gratis zijn, maar ook omdat het community-driven aspect van open source goed aansluit bij hun manier van werken.

De uitdaging zit ‘em in de integratie. Want de code die ontwikkelaar A schrijft, interageert natuurlijk met code die ontwikkelaar B schrijft of geschreven heeft. Je code werkt misschien wel met de code zoals jij die hebt gedownload, maar misschien is intussen andere code aangepast of zijn er andere wijzigingen. Op het moment dat ontwikkelaar A zijn code terug in de repository zet, moet dit stuk opnieuw geïntegreerd worden. Het is een wetmatigheid dat hoe meer tijd er verloopt tussen het downloaden en terug uploaden van code, hoe groter de kans is op conflicten oftewel integration hell.

CI is een (geautomiseerde) methode om deze integratie te begeleiden en uit te voeren. Een belangrijk onderdeel van CI zijn unit tests. Unit tests zijn bedoeld om na te gaan of bij input A het correcte resultaat B wel uit de machine komt. Op deze manier kan het systeem op geautomatiseerde manier nagaan of alles nog werkt na de integratie van nieuwe code. CI zal de problemen niet voorkomen, maar wel detecteren.

Als de integratie vlot verloopt, komt het volgende vraagstuk: deployment.

Uitrol: Continuous Deployment (CD)

Ook voor de uitrol van software bestaan geautomatiseerde systemen. Je kan zelfs kiezen voor continuous deployment (CD). CD biedt het voordeel dat de stappen van ontwikkelomgeving naar testing en later naar productie geautomatiseerd worden, zodat nieuwe code heel snel in productie komt.

Of je nu met geautomatiseerd deployment werkt of niet, je moet zeker aandacht besteden aan de verschillende omgevingen. Tal van deployments mislukken doordat er verschillen zijn tussen de ontwikkelomgeving en de andere omgevingen (testing, productie, enz.). Hier werk je best met systemen die alle omgevingsvariabelen gelijk stellen, zoals Puppet.

Het sleutelwoord: DevOps

DevOps is een beweging waarbij twee IT-werelden die traditioneel mijlenver uit elkaar liggen, developers en systeembeheerders, toch samenwerken. Dat is ook heel logisch, want het opzetten en onderhouden van systemen zoals VCS, CI enz. is meestal een taak voor systeembeheerders, terwijl ze worden gebruikt door de ontwikkelaars.

Maar DevOps gaat een stapje verder. DevOps komt al bij de tekenfase van een applicatie om het hoekje kijken. Er is immers een wereld van verschil tussen een applicatie schrijven die op je PC en met enkele gebruikers werkt en het ontwikkelen van een applicatie die moet draaien voor tienduizenden of honderdduizenden gebruikers tegelijk.

Op zich is het voor ervaren systeembeheerders kinderspel om bij een overbelaste databaseserver een tweede server te zetten en een cluster te bouwen. Maar als de applicatie niet afgestemd is om plots met twee databaseservers te praten, heeft dat weinig nut natuurlijk. Schaalbaarheid en performantie zijn dikwijls KPI’s voor systeembeheerders, terwijl zij de schuld van eventueel falen al snel bij de ‘triestige’ code van de ontwikkelaars zullen leggen.

Door samen technologische keuzes te maken, kunnen systeembeheerders, ontwikkelaars en projectverantwoordelijken heel wat problemen voorkomen. Door feedback te geven aan mekaar, kunnen applicatie en infrastructuur op mekaar afgestemd worden. Alles wat met CI te maken heeft, valt dan eigenlijk onder Quality Assurance (QA). Iedereen moet meewerken om de kwaliteit te verzekeren. Volgend diagram vat het kernachtig samen:

DevOps

DevOps is een een methodologie die constant door het ganse team gedragen moet worden. Het is een eindeloos verhaal van constante feedback en bijsturing.

Endless DevOps

Als je start-up succesvol wil zijn, moet dit alles een belangrijke rol innemen. Een snelle ontwikkeling (agile) met een constante kwaliteitsbewaking (CI) en voortdurende samenwerking en feedback (DevOps) zijn een recept voor later succes.

We hebben er zelf een mooi voorbeeld van.

###

Deze blogpost maakt deel uit van een reeks blogposts over IT voor start-ups. Bekijk al onze andere blogposts:

Deze blogposts worden verzameld in “het ultieme IT-handboek voor start-ups” dat je hier gratis te downloaden is.

 

 

Gerelateerde berichten
waarom zou je kiezen voor cloud hosting

Waarom zou je voor cloud hosting kiezen?

Steeds meer organisaties migreren hun hardware en software geheel of gedeeltelijk naar de cloud. Waarom maken steeds meer bedrijven die keuze?

Lees meer

Problemen oplossen in Varnish

Problemen oplossen in Varnish

In onze laatste ChalkTalk video uit de reeks bekijken we “ Problemen oplossen in Varnish ”. Hoe weet je of een pagina juist gecached wordt of niet? Wat zijn de meest voorkomende problemen na een implementatie van Varnish? En hoe los je die problemen op?

Lees meer

Netneutraliteit

Waarom onze overheid netneutraliteit moet garanderen

Een recent artikel van freelance journalist Jan Jacobs over netneutraliteit op Doorbraak.be deed ons steigeren. Zo erg zelfs dat we ons bijna afvragen op hij betaald werd door Proximus of Telenet om zo’n stuk neer te poten.

Lees meer