| Page Properties | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
\uD83D\uDCD8 Bakgrund
I Confluence finns en övergripande beskrivning för hur vi kan hantera öppen källkod inom Sundsvalls kommun i allmänhet och Utvecklingsfabriken i synnerhet. Dock finns några viktiga beaktanden att göra när det kommer till hur vi delar källkoden (med tillbehör) öppet. Se uppställning nedan.
En annan viktig frågeställning vi behöver ta ställning till är för vilket syfte vi ska tillgängliggöra källkoden för våra tjänster.
Att tillgängliggöra koden för att andra ska kunna bidra i utvecklingen enligt klassisk open source-modell.
Att vi delar med oss av det färdiga resultatet av respektive tjänst vi vill dela med oss av. Dock på ett sånt sätt att vi kan begränsa vad som delas publikt för att säkerställa att känsliga uppgifter inte sprids.
🤝 Beroenden
Oavsett alternativ som väljs behöver Utvecklingsfabrikens SpringBoot-ramverk (a.k.a. Dept44) finnas publikt tillgängligt för den som vill bygga något utifrån den öppna källkoden. Bör inte vara några konstigheter.
...
Option 1 | Option 2 | |||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Helt öppet Vi låter våra repositories i GitHub vara helt öppna och publika. Självklart att vi då lägger känsliga uppgifter, i den mån det går, som lösenord etc i separat konfigurationsrepo i GitLab. Och vi låter naturligtvis inte vem som helst att committa in saker till ett publikt repository.
| Privat & publikt Vi skiljer på publikt och privat genom att ha separata repositories där kod från det privata på lämpligt sätt kan speglas till det publika. O-öppet alltså. Vi jobbar i privata repositoryn, varifrån vi även bygger och deployar. Det är ett aktivt val att “publicera” kod från ett privat till publikt repository. Känsliga uppgifter återfinns i GitLab och de som inte kan finnas där ska kunna filtreras bort i samband med publicering till publikt repository. Kan merge från main till en branch som heter “public” i det privata repositoryt vara det som något ett jobb i Jenkins ska gå på för att kunna skyffla rätt saker (mha shallow clone etc) till det publika repositoryt?
| |||||||||||||||||||||||||||||||||||
Pros/cons |
⚠️ Potentiellt hög säkerhetsrisk om känslig information slinker med. |
⚠️ Kräver ändå att det privata repositoryt sätts upp på rätt sätt (katalogstrukturer etc) så att känslig information ska kunna filtreras bort på ett vettigt sätt. |
Enkelt. Det vi pushar in till GitHub blir tillgängligt för alla.
Varje enskild utvecklare behöver vara noggrann och se till att oönskad information inte kommer med då det är begränsat med kontrollfunktioner innan något de facto hamnar i repot. Mänskliga faktorn kan spela in....
- Vad blir följden av att personnummer eller personuppgifter “läckt”? Viten?
- För varje certifikat vi har måste vi ha färdiga rutiner för att invalidera och beställa nya certifikat.
\uD83C\uDF1F Outcome
Ja, vad blev det?Beslutet är att interimistiskt gå på Option 2, med ambitionen att nå enkelheten (helautomatiserat) i Option 1 över tid. Men det kräver att vi vet mer om möjligheterna i kommande OpenShift-uppsättning etc. Med OpenShift finns till exempel möjligheter att separera kod från certifikat och (förhoppningsvis) keystores.
Beslutet är också att tillhandahålla Dept44 publikt i form av en nedladdningsbar JAR-fil.