...
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 | 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. 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. Se exempelvis https://github.com/open-condo-software/gitexporter Möjlighet att förhindra att oönskad historik kommer med med hjälp av “shallow clone” då det enbart är 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) publicering till publikt repository, även om det bör vara ett aktivt val att faktiskt göra det. Det här steget möjliggör också att införa kontroller för att förhindra att oönskad information slinker med. 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 (katalogstrukturer etc) så att känslig information ska kunna filtreras bort på ett vettigt sätt. |
...