CI/CD: Wat is Continuous Integration?

Continuous Integration is de eerste helft van het acroniem CI/CD, waarbij Continuous Delivery de tweede helft van het geheel is. In een driedelige serie van artikelen kijken we eerst naar de twee helften van CI/CD om ze te definiëren en beter te begrijpen, en in het derde deel praten we over hoe Uptrends past in uw CI/CD processen. Laten we bij het begin beginnen met Continuous Integration.

Dus, wat is Continuous Integration?

Continuous Integration (CI) is een proces dat door softwareontwikkelaars wordt gebruikt om snel en efficiënt software te ontwikkelen. De softwareontwikkelaars breken de benodigde functionaliteiten op in kleine logische stukjes in de planningsfase. Eenmaal uitgepland, wordt de code geschreven en getest op de computer van de ontwikkelaar tijdens de codeerfase. Als de ontwikkelaar tevreden is, controleert hij de code in een versiecontrolesysteem. Het invoeren van de code activeert een geautomatiseerd proces die de wijzigingen in een nieuwe build verwerkt en de software continu test. Eenmaal verwerkt, begint de cyclus opnieuw met de planningsfase van het proces.

The continuous integration cycle

Waarom gebruik maken van Continuous Integration?

De voornaamste reden om een Continuous Integration-proces te hanteren is dat CI de tijd tussen de planning en levering van nieuwe software verkort. Bij eerdere software-implementatieprocessen moesten de ontwikkelaars gedurende langere periodes geïsoleerd werken. De ontwikkelaars werkten vanuit gegeven ontwerpspecificaties en hun code werd vaak niet getest in combinatie met het werk van andere ontwikkelaars tot pas veel later in het proces. Na wat soms maanden of zelfs jaren werk was, begon de integratie van de code, gevolgd door soms een nog langere periode van bug fixes, code revisies en correcties aan de functionaliteit. Vervolgens moest al dat hergeschreven werk opnieuw regressietests ondergaan, terwijl de klant het product niet eens heeft gezien of goedgekeurd. Ziet u waar we naartoe gaan? Nergens – niet snel in ieder geval.

Dus, waarom zou u gebruikmaken van CI? CI resulteert namelijk in een verbeterde code dat snel naar eindgebruikers kan worden geleverd doordat de errors in het code ontwerp, problemen met de code en systeemintegratie of prestatieproblemen in een supersnelle feedback loop wordt aangegeven.

Hoe versnelt Continuous Integration het ontwikkelingsproces?

Zoals hierboven beschreven, is het lastig om nieuwe code in de root van een applicatie te integreren zonder aanzienlijke problemen wanneer ontwikkelaars voor langere tijd in isolatie coderen. Het vinden van bugs in de code neemt veel tijd in beslag en leidt vaak tot meer codeconflicten en bugs in onverwachte gebieden van bepaalde functionaliteiten. Het integratieproces neemt vaak meer tijd in beslag dan de tijd vereist om de functie te coderen, waardoor het dus een kostbaar proces wordt en de levering van het product hierdoor aanzienlijk wordt vertraagd.

Met CI werken veel ontwikkelaars of teams van ontwikkelaars vanuit usecases of User Stories. Een usecase of User Story beschrijft een eenheid van functionaliteit, zoals het toevoegen van een product aan de winkelwagen. Als de ontwikkelaars eenmaal de code hebben ontwikkeld en de nieuwe functionaliteit op een lokale kopie van de ontwikkelingsomgeving kan worden getest, kan de code in een versiecontrolesysteem zoals Git worden gecontroleerd. Het invoeren van de code activeert een geautomatiseerd proces dat de code in de applicatie integreert. Een geautomatiseerd proces test de functionaliteit verder terwijl de ontwikkelaar verder kan met een nieuwe usecase en anderen kunnen verder bouwen op de nieuwe code.

Met CI heeft u meer tijd voor het ontwikkelingen van functionaliteiten en verliest u minder tijd aan het corrigeren van uw code. De korte ontwikkelingsiteraties resulteert in snellere aanleveringstijden en een robuuster product.

Een voorbeeld van Continuous Integration

Om het CI-proces te illustreren, laten we eens kijken naar een kalender applicatie die gebruikt wordt voor het inplannen van afspraken. Op dit moment kan een gebruiker in deze hypothetische applicatie een afspraak op een dag en tijd reserveren, maar hij kan de afspraak niet annuleren of opnieuw inplannen met de applicatie. Dus het doel is nu om deze functionaliteit in de applicatie toe te voegen. Uw lead developer besloot dat u de annuleringsfunctie schrijft, terwijl een collega het opnieuw plannen van de afspraak op zich neemt. Het proces is als volgt:

  1. U kopieert de huidige applicatie van het versiebeheerplatform naar uw computer.
  2. U schrijft de code. Deze kleine hoeveelheid functionaliteit bevat een nieuwe knop of link in de applicatie die de gebruiker aanklikt om de afspraak te annuleren. Zodra de gebruiker zijn beslissing om de afspraak te annuleren bevestigt, stuurt een eenvoudige functie die u hebt geschreven een verzoek naar de database om de afspraak uit de agenda te verwijderen.
  3. U test de code in uw kopie van de applicatie grondig.
  4. U commit uw wijzigingen naar de versiebeheersoftware. De wijzigingen activeren een geautomatiseerd build- en testproces.
  5. U checkt de buildresultaten voor problemen. Als er niks aan de hand is gaat u over naar de volgende stap, anders moet de code worden herzien. U hebt bijvoorbeeld code ingevoerd voor het annuleren van de afspraak, maar terwijl u werkte aan aan uw lokale kopie van de applicatie, controleerde uw collega haar gebruikersinterface. U hebt beide een knop toegevoegd op dezelfde plaats op de pagina. De build mislukt als gevolg van dit conflict, u moet uw knop verplaatsen en de code weer doorvoeren.
  6. U gaat door met een andere use case of verder met het uitbouwen van dezelfde use case.

U heeft nu wat broodnodige functionaliteit aan het product toegevoegd, voor lunchtijd! De nieuwe code is nu onderdeel van het product – in de ontwikkelingsomgeving van de huidige versie van de code in ieder geval.

Uw lead developer heeft Mia, uw collega, de taak voor de andere functionaliteit toegewezen. Zij moet de huidige afspraak annuleren en de database updaten met de nieuwe datum en tijd. Mia heeft wijzigingen aangebracht in de gebruikersinterface die het herplannen mogelijk maken, maar achter de schermen gebruikt de nieuwe functionaliteit van Mia uw functie om een afspraak te annuleren en hergebruikt de oude functionaliteit van de agenda om een nieuwe afspraak te maken.

Uw nieuwe code was in recordtijd klaar om door Mia te worden hergebruikt. Jullie hebben beide, in één ochtend, iets van toegevoegde waarde voor de applicatie ontwikkeld.

Automatisering is belangrijk

De Agile ontwikkelingsomgeving is dynamisch. Veranderingen gebeuren snel, en Continuous Integration is een belangrijk onderdeel van het ontwikkelingsproces. De automatisering van het ontwikkelen en testen van software staat centraal van het CI proces. In het geval van websites, web applicaties en API’s moet worden gecontroleerd op functionaliteit, prestatie en beschikbaarheid.

U kunt Uptrends achter uw firewall plaatsen om uw ontwikkelingsomgeving te monitoren. Omdat Uptrends’ Persoonlijke Controlestations op uw servers achter uw firewall staan, kan uw Private Checkpoint de ontwikkelingsomgeving op dezelfde manier monitoren net zoals reguliere checkpoints van Uptrends uw webgerichte infrastructuur kunnen monitoren. U kunt uw API controleregels en Web Applicatie Monitoring scripts naast uw applicatie code voortdurend ontwikkelen. Wanneer u klaar bent voor de implementatie naar uw ontwikkelingsomgeving kunt u de porting van uw nieuwe of aangepaste controleregels direct naar uw acceptatie- of productieomgeving automatiseren (later meer daarover).

Straks: Continuous Delivery (wordt binnenkort verwacht)