CI/CD
Deze pagina beschrijft hoe een iprox.headless oplossing te bouwen en te deployen in de straat. Dit loopt vooruit op de implementatie in IPCMS-1451
CMS build
Als er geen sprake is van maatwerk, is er geen build voor het CMS nodig. De standaard artifact/universal package kan gedeployed worden.
In het geval van maatwerk worden de plugins gebuild en in een artifact gestopt. NB: in de artifact zitten dus alleen de plugins, net zoals dat bij builds van implementaties van iprox.one het geval is.
CMS deploy
Bij een deploy van het CMS wordt een samengestelde deploy gedaan van iprox.headless en het maatwerk. Dit is gelijk aan hoe ook bij iprox.one gebeurt.
Eventuele databasewijzigingen vinden plaats bij het uitrollen van een CMS release.
API build
De build kan worden getriggerd vanuit de code of vanuit iprox.headless na het wijzigen van de configuratie. Builds vinden altijd plaats in de omgeving die de 'vroegste' plaats in de OTAP-straat heeft en worden na goedkeuring doorgezet naar latere omgevingen. Het is niet de bedoeling om in latere omgevingen afwijkende configuraties te hebben waarvoor een afwijkende build nodig is.
Als er geen sprake is van maatwerk, dan wordt de standaard build gedraaid
vanuit de repository iprox.open-api.release met toepassing van
de benodigde generator-opties; dat is in ieder geval
CmsUrl= URL van iprox.cmsEnvSyn= alias omgeving
Als er wel sprake is van maatwerk, dan wordt de build gestuurd door de repo waarin het maatwerk staat.
API deploy
Het uitrollen van een API release gebeurt in Azure door het deployen naar een App Service. In het geval van een productie-omgeving wordt hierbij een extra deployment slot gebruikt, zodat de omgeving met zero downtime kan worden geüpdatet.
Actiepunten
Op basis van de locatie van de build (gitlab/DevOps), van de hosting (Comsenso/Azure), het soort omgeving (CMS/API) en de aanwezigheid van maatwerk (ja/nee) zijn er 16 combinaties mogelijk. Deze sectie inventariseert welke actiepunten er openstaan om al deze 16 combinaties te ondersteunen.
Nader te bespreken is welke van de 16 combinaties we hiervan willen ondersteunen. Met name de combinaties gitlab+Azure en DevOps+comsenso liggen niet onmiddellijk voor de hand. In het laatste geval zelfs zo niet voor de hand dat deze combinaties niet in onderstaande tabel zijn opgenomen.
| Build | Hosting | Omgeving | Maatwerk | Actie |
|---|---|---|---|---|
| gitlab | Comsenso | CMS | Nee | 1 |
| gitlab | Comsenso | CMS | Ja | 1 + 2 |
| gitlab | Comsenso | API | Nee | 3 |
| gitlab | Comsenso | API | Ja | 4 |
| gitlab | Azure | CMS | Nee | 1 + 5 |
| gitlab | Azure | CMS | Ja | 1 + 2 + 5 + 6 |
| gitlab | Azure | API | Nee | 3 + 5 |
| gitlab | Azure | API | Ja | 5 |
| DevOps | Azure | CMS | Nee | 7 |
| DevOps | Azure | CMS | Ja | 7 + 8 |
| DevOps | Azure | API | Nee | - |
| DevOps | Azure | API | Ja | - |
Onderstaande actiepunten moeten worden opgepakt in IPCMS-1451.
Actie 1: iprox.cms+headless in dist
Een artifact van het standaard iprox.cms inclusief headless moet gepubliceerd worden naar dist.
Actie 2: iprox.cms+headless aanvullen met maatwerk (dist)
Conform de opzet van iprox.one moet een deploy van iprox.cms+headless kunnen worden aangevuld met een artifact dat alleen het maatwerk hierop bevat.
Actie 3: build API in gitlab (geen maatwerk)
In iprox.open-api.release moet een .gitlab-ci.yml komen die analoog aan
de bestaande azure-pipelines.yml de generieke build in gitlab verzorgt.
Actie 4: deploy API bij comsenso
In principe is dit niet heel anders dan andere uitrollen via dist. Het is
vermoedelijk wel nodig de betrokken apppool en/of website te stoppen ten
tijde van een update (nader uit te zoeken welke van de 2 precies). Vanuit
dist kan dit al aangegeven worden, maar daar moet de deploy client dan wel
naar gaan luisteren.
Zero-downtime updates zijn vooralsnog niet in scope.
Actie 5: autorisatie op Azure DevOps
Vanuit gitlab moet op een duurzaam goede manier verbonden worden met Azure DevOps. Dit betreft met name het goed en duurzaam implementeren van toegangscodes/PATs.
Actie 6: SQL scripts uitvoeren op Azure (vanuit gitlab)
Vanuit gitlab moeten bij de deploy naar Azure de gewijzigde SQL scripts worden uitgevoerd, zoals dat nu al gebeurd in de uitrol van RPP (?)
Actie 7: SQL scripts uitvoeren op Azure (vanuit DevOps)
Vanuit DevOps moeten bij de deploy naar Azure de gewijzigde SQL scripts worden uitgevoerd.
Actie 8: iprox.cms+headless aanvullen met maatwerk (Azure)
De build van maatwerk in het CMS wordt gewijzigd. De bestaande 4.9 deploys zullen bij een upgrade moeten worden aangepast, zodat ze zowel het standaard product als de plugins installeren, die nu dan in 2 verschillende artifact sources zitten.