DevOps Continuous Integration is een veel gehoord modewoord in de IT industrie de laatste tijd. Het gaat hier om een belangrijk onderdeel van DevOps. We weten allemaal wat DevOps te bieden heeft en de meeste organisaties zoeken op zijn minst een deel van de belofte van DevOps. Vaak een Continuous Delivery flow en “Operations bij de ontwikkelaars” zetten. Maar kunnen we dat wel doen als we de opdracht om ‘agile’ te worden nog steeds niet hebben afgerond?
Laten we verkennen wat we tegenwoordig met agile bedoelen. In het begin draaide de agile discussie vaak om het zo snel mogelijk te kunnen bouwen van functies door ze op te splitsen in kleinere “hapklare” brokken. Die brokken werden opgeleverd en vervolgens werd bepaald hoe ze aangepast moesten worden op basis van feedback. Agile heeft ons coole dingen gebracht, zoals user stories, en mechanismen zoals korte iteraties (Sprints) en dagelijkse stand-ups. Deze snelle, resultaatgerichte filosofie gaf een nieuwe richting aan softwareontwikkeling. En zonder enige twijfel bleek dat deze werkwijze een betere manier van ontwikkelen is. Een belangrijk deel van deze methode bestond uit een reeks technische procedures waarmee de teams software konden schrijven op een manier die door een agile omgeving wordt ondersteund.
Inmiddels hebben we ontdekt dat het ontwikkelen van kleine brokken moeilijk is. Daarbij werkt Agile tegen onze intuïtie in. We willen de functies namelijk graag in het grote plaatje zien werken. Vroeger was de vraag die je het meest hoorde: “Hoe kan ik een applicatie portfolio op deze manier beheren?” Die vraag is nu veranderd in “Hoe kan ik die functies schalen?” Het antwoord op beide vragen is hetzelfde: Niet doen. De reden dat we naar de kleinere brokken en user stories zijn verhuisd, is omdat de “grote plaatje” -aanpak niet werkt. Daarom is het zoeken naar manieren om agile methoden met een schoenlepel in “Geschaald” of “Big Up Front Agile” te persen is een verspilling van tijd en energie. Laten we ons liever focussen op hoe we de agile methoden beter kunnen gebruiken en de bekende voordelen er van kunnen plukken.
Een van de dingen die telkens werd uitgesteld was het zo wendbaar mogelijk maken van de bestaande praktijken. Op zijn best werd bij Test Driven Development (TDD) verondersteld dat het op een magische wijze zou goed komen. Maar vaak werd het wendbaar maken uitgesteld omdat we al onze releasetreinen en architecturale start- en landingsbanen nog niet hadden aangelegd. Met andere woorden, het zou nooit gebeuren. Een metafoor is: “Ik ga beginnen met de training als ik goed genoeg ben”. Je moet echter eerst de technische trainingen doen om goed genoeg te worden, anders is het gewoon tijdverspilling. En dit is waar DevOps in het spel komt.
DevOps wordt het meest geassocieerd met het Continuous Delivery concept. Het idee dat we op elk moment de resultaten van onze ontwikkelingsinspanningen kunnen bouwen en inzetten, geeft ons enorm veel flexibiliteit bij het beslissen welke software onderdelen moeten worden geleverd en wanneer. De DevOps tools die ons helpen hebben een volwassenheidsniveau bereikt dat ons in staat stelt om enorme vooruitgang te boeken. Als het gaat om het visualiseren en orkestreren van het bouwen, testen en leveren van software brokken, of om de tools die deze onderdelen automatiseren, de prestaties zijn enorm omhoog gegaan. De vraag is echter nog steeds: Heeft ontwikkelteam hetzelfde niveau van volwassenheid om met deze tools om te gaan?
Continuous Integration is het concept dat meerdere programmeurs tegelijk een functie onderhanden hebben. Daarbij worden de broncode geverifieerd, gecompileerd, getest en met hoge frequentie gecombineerd en uitgerold. Binnen DevOps Continuous Integration wordt de broncode van programmeurs samen te voegen tot een gedeelde hoofdlijn. DevOps Continuous Integration kent implementaties waarbij software meerdere keren per dag wordt geïntegreerd. Het doel van DevOps Continuous Integration is het voorkomen van integratieproblemen waarbij het ene deel van de software niet goed samenwerkt met het andere deel.
Dit proces vraagt veel van de programmeurs en de tools. Met name als er fouten in de test worden gevonden waardoor bepaalde functies weer terug worden getrokken.
Als je volgens agile – scrum werkt zal het ontwikkelteam “portfolio-items” onderscheiden. Die items worden onderverdeeld in user stories en die worden vervolgens ingepland in sprints. Probeer dan NIET rechtstreeks naar DevOps over te stappen. Leer eerst hoe je TDD echt omarmt, zowel op het niveau Unit Test als op het niveau Acceptance Test. Zodra je je daar prettig bij voelt, kan je overstappen naar Continuous Integration en vervolgens Continuous Delivery.
In plaats van je agile praktijken halverwege te stoppen en over te stappen op DevOps, kan je beter je Agile processen verder omzetten. Daarbij kan je DevOps tools implementeren. Zodra je vertrouwd bent met de geautomatiseerde toolset en de iteraties die je oplevert, stap je over op Continuous Integration en Continuous Delivery. De overgang naar DevOps is dan nog een formaliteit.
Discussieer mee op LinkedIn.
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.