Stel zelf een pipeline samen met zelfstandig bruikbare modules, of gebruik de optionele standaardpipeline voor Java. Elke module voert één herkenbare taak uit, kiest een eigen image en publiceert benoemde outputs. Je pipeline bepaalt stages, needs, voorwaarden en aanvullende jobs.
Beschikbaarheid: 15 actieve modules hebben uitvoerbare samples. Daarnaast staan 6 modules op TODO: npm-audit, fortify, image-scan, image-sign, image-verify en zap-baseline. Ze draaien niet in de demo en zijn niet selecteerbaar in CI samples. Zie status en resterend werk per module.
De demo bestaat uit vier openbare repositories:
| Repository | Inhoud |
|---|---|
| ci-components | Losse modules, uitvoerbare voorbeelden, moduletests en de demo-installer |
| ci-pipelines | Standaardpipeline java-service, eigen versies, pipelinetests en gebruiksdocumentatie |
| hello-world | Zelfstandige Java-backend, Angular-UI, Helm-charts en applicatietests |
| ci-samples | Volledige testapplicatie met een keuzelijst om de module- en pipelinevoorbeelden uit te voeren |
Elke repository kan afzonderlijk worden bekeken en gecloned. Volg voor een nieuwe Mac de installatiehandleiding: Docker-instellingen, installatie, validatie en inloggen staan daar bij elkaar. Haal voor de volledige demo alle vier samen op:
git clone --recurse-submodules https://github.com/woozer/ci-components.git
cd ci-componentsci-components verwijst met Git-submodules naar vaste commits van ci-pipelines onder pipelines/, hello-world onder java/ en ci-samples onder infra/seed/ci-samples/. Elk onderdeel wordt in zijn eigen repository beheerd. Voor alleen de CI-bibliotheek kun je --recurse-submodules weglaten.
De installer vult vier gelijknamige projecten in de lokale GitLab vanuit deze checkouts. Bestaande, gevulde GitLab-repositories worden behouden. GitHub bevat de openbare broncode; de pipelines draaien in GitLab. Links naar localhost werken na installatie op je eigen machine. De applicatie kan ook zelfstandig worden gebouwd en getest.
- Kies een module uit de modulehandleiding.
- Neem het minimale voorbeeld over, kies een uitgebrachte bibliotheekversie zoals
2.0.0en vul de verplichte inputs in. Optionele standaardwaarden kun je weglaten. - Verbind jobs met GitLabs
needsen artifacts/dotenv. Begin met een uitvoerbaar voorbeeld.
| Klein beginnen | Een volgende stap toevoegen | Modules herhalen |
|---|---|---|
| Maven-build | Bouwen → testen, image/chart → deployment → testen | Twee deployables |
Start deze via CI samples → New pipeline: kies sample en daarna New pipeline. Dezelfde YAML-bestanden dienen als voorbeeld voor afnemers en valideren modulewijzigingen in echte GitLab-jobs. Lees hoe de validatie werkt.
Voor één module heb je geen standaardpipeline, organisatieprofiel of releaseproces nodig. Je platform levert de images en toegangsgegevens voor diensten; de verplichte inputs en uitvoeringsvoorwaarden staan per module beschreven. De gedeelde afhandeling van hooks wordt automatisch ingeladen.
Gebruik binnen een eigen pipeline dezelfde componentversie voor alle losse modules. De standaardpipeline heeft een eigen versie in ci-pipelines en zet haar moduleafhankelijkheden vast. Wijzigingen vóór publicatie testen we op hun exacte commit-SHA.
De actieve modules zijn ook vindbaar in de CI/CD Catalog van de lokale GitLab, onder ci-components. De catalogus toont de gepubliceerde versies en inputs. Zie componentversies en cataloguspublicatie voor de inrichting en publicatiestappen.
Gebruik java-service uit ci-pipelines voor bouwen, testen, publiceren, Helm-deployment en releases. Deze cataloguscomponent heeft een eigen versie en gebruikt vaste versies van de bouwblokken. Alleen maven-project is verplicht; ui-directory: ui schakelt de optionele Angular-UI in.
include:
- component: $CI_SERVER_FQDN/root/ci-pipelines/java-service@1.1.0
inputs:
maven-project: hello-appDe pipelinehandleiding beschrijft bouwen, profielkeuze en de releaseknop. Het applicatievoorbeeld laat ook het formulier op New pipeline zien. De standaard ondersteunt één Java-deployable binnen een Maven-reactor en een optionele UI. Gebruik voor meer deployables expliciete module-instanties.
| Vraag | Handleiding |
|---|---|
| Hoe gebruik ik een module en verbind ik jobs? | Modulehandleiding: werking, voorwaarden, inputs, defaults, outputs en hooks bij elkaar |
| Hoe voer ik de voorbeelden uit? | Samples gebruiken en valideren |
| Hoe bedien ik de standaardpipeline? | Pipelinekeuzes en releasebeleid |
| Hoe richt ik het platform in? | Lokale installatie of platformvoorwaarden en eigen organisatie |
| Hoe onderhoud ik de bibliotheek? | Ontwerp en onderhoud en standaarden en keuzes |
We volgen GitLabs advies over componenttests en hergebruik. GitLab levert jobs, afhankelijkheden, artifacts, inputs en locks; de keuzetermijn van tien seconden en automatische patchversie zijn afspraken van onze optionele standaardpipeline. Zie standaarden en keuzes.
De vijftien actieve modules staan in templates/; zes toekomstige modules staan in modules/todo/. GitLab verwerkt de component-YAML rechtstreeks. Profielkeuze en releasereservering leveren tijdens de uitvoering een klein configuratieartifact voor hun childpipeline op.
De scanhandleiding beschrijft SonarQube en Dependency-Check in de demo, zonder handmatig aangevraagde API-keys.