Öppen källkod-hantering

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.

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 till det publika repositoryt.

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. Mänskliga faktorn kan spela in.

Risk att personuppgifter (framförallt i testdata) slinker med och blir publika.

Risk att keystores med certifikat slinker med och blir publika.

⚠️ Potentiellt hög säkerhetsrisk om känslig information slinker med.

Möjlighet att begränsa vilka delar av det privata repositoryt som speglas ut till det publika.

Möjlighet att förhindra att oönskad historik slipper med - det är enbart skillnaden mellan respektive “publicering” som är önskvärd i det publika repositoryt. Minskar risk för att “fulkod” kommer med (även om vi naturligtvis aldrig fulkodar något, någonsin…).

Möjlighet att automatisera (förslagsvis via Jenkins) även om det bör vara ett aktivt val att faktiskt publicera ut något till ett publikt repository.

Mer komplex uppsättning.

Kräver dubbla repositoryn.

Oklart hur arbetsflödet bäst sätts upp för att åstadkomma detta.

⚠️ Kräver ändå att det privata repositoryt sätts upp på rätt sätt så att känslig information ska kunna filtreras bort på ett vettigt sätt.