Sidjämförelse

Dessa inställningar görs i en fil som överskrider standard inställningarna i VP. Detta görs : för att VP skall fungera i sitt sammanhang i NTJP ellle på annan regional installation. Detta realiseras med en inställnings fil som överskriver “standard inställningarna” (application.properties). Dessa filer är egna projekt (åtminstone för NTJP), men

I VP projektet finns en fil med standard inställningar (application.property) som fungerar under utveckling (eftersom den är en del av VP så innebär alla ändringar i denna en ny VP version).

Det omvända gäller de lokala inställningarna som av naturliga skäl inte är en del av VP, men de är såklart nära kopplade till VP:s deployment.

Men för För NTJP gäller att på lokala inställningar är egna projekt. Ett per respektive miljö (dev, test, qa, prod) så skall ändringar . Ändringar i dessa versionshanteras separat i Gitlab, Dessa ändringar påverkar (naturligtvis) inte versionsnummret för VP och det finns ingen explicit koppling mellan en “version” av lokala inställningar och en VP version.

För NTJP gäller att ändringar i inställningar normal först skall genomföras och testas i devel miljön följt av Test QA och Prod. För QA och Prod.

Rent praktiskt har endas driftsleverantören rätt att ändra inställningar i QA och Prod varför “vi/helpdesk”: lägger en beställning/instruktion på dessa ändringar antingen . Antingen som en del av deployment instruktionen i samband med en ny version av VP, eller som en separat uppgift/beställning. Driftsleverantören säkerställer sedan Det är sedan upp till driftsleverantören att säkerställa att dessa uppdateringar/ändringar pushas till GitlabMedan “Standard application.properties” är däremot en del av VP projektet och följer med i deployment filen som maven skapar. Ändringar som sker i denna kommer därför (naturligtvis) att resultera i att en ny version av VP.