...
Expandera | ||
---|---|---|
| ||
(Tillskillnad från applikationer som är beroende av någon webb/applikations-server) Men ingår normalt som en komponet i ett system (NTJP). Eftersom detta är enda filen som skall instaleras som har sitt ursprung i VP projektet så slutar formellt komponentlistan här. |
Expandera | ||
---|---|---|
| ||
Dessa inställningar görs i en fil som överskrider standard inställningarna i VP. Detta görs : Dessa ingår egentligen inte (av naturliga skäl) i VP projektet. Men för att VP skall fungera i sitt sammanhang i NTJP ellle på annan regional installation krävs att det finns en sådan fil. 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. exakt vilka inställningar som behöver överskridas kan variera). För NTJP gäller att lokala inställningar är egna projekt. Ett per respektive miljö (dev, test, qa, prod). Ä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 som en del av deployment instruktionen i samband med en ny version av VP, eller som en separat uppgift/beställning. Det är sedan upp till driftsleverantören att säkerställa att dessa uppdateringar/ändringar pushas till Gitlab. |
Expandera | ||
---|---|---|
| ||
Poängen med VP är att skapa en lös koppling mellan olika system inom svensk sjukvård som vill byta tjänster. |