Een pipeline voor continue integratie (CI) moet antwoord geven op een concrete vraag: kan deze wijziging worden opgenomen in de gedeelde codebase zonder bekende defecten te introduceren of afgesproken vereisten te breken? Daarvoor is het raadzaam herhaalbare controles te definiëren, de volgorde ervan te bepalen en ervoor te zorgen dat elke fout nuttige informatie oplevert.
CI betekent niet dat elke wijziging automatisch wordt gedeployed. Het is de praktijk van wijzigingen frequent integreren en ze geautomatiseerd valideren. Continuous delivery bereidt voortdurend een deploybare versie voor; continuous deployment voegt daar automatische publicatie naar productie aan toe zodra aan de vastgestelde voorwaarden is voldaan. Een applicatie kan CI gebruiken zonder de delivery te automatiseren, of die automatiseren tot en met een testomgeving en vóór productie een goedkeuring vereisen.
Definieer het contract van de pipeline
Leg voordat je tools kiest vast wat de uitvoering als input krijgt, wat deze moet opleveren en onder welke voorwaarden ze faalt. Een bruikbare configuratie documenteert ten minste het volgende:
- Input: de wijziging die wordt gevalideerd, de relevante configuratie en de door het project gedeclareerde dependencies.
- Omgeving: systeem- en runtimevereisten, PHP-configuratie en services die nodig zijn voor de tests. De omgeving moet tussen uitvoeringen voldoende vergelijkbaar zijn om resultaten met elkaar te kunnen vergelijken.
- Resultaat: de eindstatus, test- en analyserapporten en, waar van toepassing, een identificeerbaar artefact dat later kan worden gevalideerd.
- Faalvoorwaarden: welke fouten de integratie blokkeren, welke waarschuwingen opleveren en wie een tijdelijke uitzondering mag goedkeuren.
De installatie moet uitgaan van de dependencyconfiguratie die onder versiebeheer staat en het lockbestand respecteren, in plaats van bij elke uitvoering stilzwijgend nieuwe versies op te lossen. Zo wordt een bron van verschillen tussen ontwikkelaars en CI beperkt. Declareer ook de platformvereisten en extensies die de applicatie verwacht, en controleer of de runtimeomgeving daaraan voldoet.
Voorkom dat de pipeline afhankelijk is van lokale bestanden, persoonlijke services of niet-gedocumenteerde handmatige stappen. Als een controle een database, cache of andere service nodig heeft, definieer dan hoe deze wordt gestart, welke gegevens nodig zijn en hoe deze wordt opgeschoond. Het contract hoeft productie niet volledig na te bootsen, maar moet verschillen die het resultaat kunnen beïnvloeden wel expliciet maken.
Rangschik controles op kosten en detectievermogen
Een praktische volgorde begint met snelle validaties en eindigt met controles die meer tijd of infrastructuur vereisen. Het doel is niet om zoveel mogelijk taken toe te voegen, maar om problemen zo vroeg mogelijk op te sporen zonder betekenisvolle dekking te verliezen.
- Reproduceerbare installatie: los dependencies op aan de hand van de definitie en lockfile van het project. Als dit mislukt, zijn de overige resultaten niet betrouwbaar.
- Opmaak en conventies: controleer de afgesproken opmaak- en stijlregels. Deze controles zijn snel en voorkomen dat opmaakverschillen pas bij een duurdere review aan het licht komen.
- Statische analyse: zoek naar incompatibiliteiten en fouten die kunnen worden opgespoord zonder alle applicatiestromen uit te voeren. Stem de regels af op de daadwerkelijke code en configuratie van het project.
- Tests: voer eerst unit tests uit en voeg integratie- of end-to-endtests toe op basis van het risico dat ze afdekken en de services die ze nodig hebben.
- Validatie van het artefact: controleer of het gegenereerde pakket of de image alles bevat wat nodig is om te draaien en geen ontwikkelbestanden, lokale gegevens of secrets bevat.
Niet elke applicatie heeft dezelfde tests of volgorde nodig. Als een statische analyse veel langer duurt dan een kleine unit test, kan het zinvol zijn beide controles parallel uit te voeren nadat de dependencies zijn geïnstalleerd. Ook onafhankelijke taken kunnen parallel worden uitgevoerd om de wachttijd te verkorten, zolang ze op een reproduceerbare basis steunen en hun resultaten aan dezelfde wijziging gekoppeld blijven.
Het is daarentegen niet verstandig om stappen blindelings parallel uit te voeren als ze dezelfde directory wijzigen of afhankelijk zijn van eerdere resultaten. Scheid de gemeenschappelijke voorbereiding van de daaropvolgende taken, beperk de gelijktijdigheid van gedeelde services en maak de afhankelijkheden tussen fasen duidelijk. Het doel is de feedbacktijd te verkorten zonder de pipeline onvoorspelbaar te maken.
Bepaal wat blokkeert en wat later wordt uitgevoerd
Blokkeer de integratie aanvankelijk wanneer een controle die relevant is voor de veiligheid van de wijziging faalt: installatie, afgesproken analyse, vereiste tests of validatie van het pakket. Een informatieve taak — bijvoorbeeld een controle die nog wordt geëvalueerd — kan gedurende een vastgestelde periode resultaten rapporteren zonder te blokkeren. Wijs daarvoor een verantwoordelijke aan, leg een evaluatiedatum vast en bepaal wanneer de controle verplicht wordt; anders worden waarschuwingen permanent en verliezen ze hun waarde.
Snelle controles moeten bij elke wijziging vroeg feedback geven. Dure tests kunnen parallel, in een latere fase of met een andere frequentie worden uitgevoerd als tijd of infrastructuur dat rechtvaardigt. Als alle belangrijke validatie pas na integratie plaatsvindt, ontstaat er echter een periode waarin wijzigingen nog niet zijn gecontroleerd. Bepaal wat vóór integratie vereist is en wat als aanvullende validatie dient, rekening houdend met de impact van een late fout.
Een geslaagde uitvoering betekent niet dat een deployment is geautoriseerd. CI controleert de wijziging en kan een artefact genereren; het deliveryproces bepaalt hoe dit wordt doorgezet, naar welke omgeving en onder welke controles. Door deze grens expliciet te houden, voorkom je dat een validatietaak per ongeluk naar productie publiceert. Als er automatische deployment is, definieer dan afzonderlijk de voorwaarden, goedkeuringen, strategie voor geleidelijke uitrol en het rollbackmechanisme.
Bescherm de configuratie en secrets
Secrets mogen niet in de repository, voorbeeldconfiguratiebestanden of uitvoeringsrapporten terechtkomen. Gebruik het secretmanagementmechanisme van de CI-omgeving, beperk de beschikbaarheid ervan tot de taken die ze nodig hebben en geef geen productiecredentials aan validaties die alleen geïsoleerde services nodig hebben.
Controleer ook de logs: een exception, mislukte test of diagnostisch commando kan gevoelige variabelen afdrukken. Waarden maskeren helpt, maar voorkomt niet dat ze worden weggeschreven. Gebruik testgegevens die geen echte informatie blootleggen en definieer een procedure om credentials in te trekken als ze in een log of artefact verschijnen.
Maak fouten diagnosticeerbaar
Een rode status zonder context leidt tot dubbel werk en maakt CI tot een black box. Bewaar test- en analyserapporten, de uitvoer die nodig is om de mislukte stap te identificeren en de versienummers van dependencies of het artefact. Leg daarentegen geen persoonsgegevens, secrets of ongerichte dumps van de omgeving vast.
Markeer een test die met tussenpozen faalt niet als geslaagd na onbeperkt opnieuw proberen. Leg vast welke tests wisselende resultaten geven, hoe vaak dat gebeurt en onder welke omstandigheden; onderzoek oorzaken zoals gelijktijdigheid, externe dependencies, gedeelde status of time-outs. Als een instabiele test tijdelijk wordt geïsoleerd, documenteer dan het risico, wijs een verantwoordelijke aan en stel een deadline vast voor het herstel van de test als blokkerende controle.
Maak ook onderscheid tussen een fout in de code en een infrastructuurprobleem. Rapporteer het als services niet konden worden gestart, dependencies niet konden worden opgehaald of een taak door een tekort aan resources niet kon worden voltooid. Opnieuw proberen kan redelijk zijn bij een tijdelijke onderbreking, maar moet beperkt en zichtbaar zijn; de eerste fout verbergen maakt terugkerende problemen moeilijker te herkennen.
Pas CI aan een legacyapplicatie aan
In een oud systeem kunnen strenge regels die ineens worden geactiveerd nuttige wijzigingen blokkeren en ongecontroleerde uitzonderingen in de hand werken. Begin met een baseline: stel vast welke tests nu slagen, welke bestaande fouten de analyse rapporteert en hoelang elke fase duurt. Presenteer een bestaand probleem niet als regressie, maar laat de baseline ook geen onbeperkt excuus worden.
- Maak eerst reproduceerbare, stabiele controles verplicht, zoals de installatie en een betrouwbare testsuite.
- Leg bestaande bevindingen vast en eis dat nieuwe wijzigingen het probleem niet uitbreiden, als de tool en het project die vergelijking toelaten.
- Voeg tests toe rond gebieden met het grootste wijzigingsrisico en breid de dekking geleidelijk uit.
- Beperk uitzonderingen met kleine, goed te reviewen wijzigingen; wijs voor elke tijdelijke uitzondering een verantwoordelijke aan en leg een einddatum vast.
- Meet de doorlooptijd en oorzaken van fouten om specifieke fasen te optimaliseren, in plaats van validaties te verwijderen zonder te weten welk risico ze afdekten.
Goede continue integratie in PHP wordt niet bepaald door het aantal fasen, maar door reproduceerbare en begrijpelijke resultaten. Als het team kan uitleggen wat elke stap valideert, wat de integratie blokkeert en hoe een fout wordt onderzocht, helpt de pipeline om op basis van bewijs te bepalen wanneer een wijziging klaar is om verder te gaan.
