Det senaste året har jag intresserat mig mycket för digital självständighet, både på ett personligt plan och på ett organisatoriskt eller gemensamt plan. När jag tittat på vilka mjukvarutjänster jag själv använder från amerikanska techjättar och framgångsrikt bytt ut dem mot motsvarande tjänster gjorda med öppen källkod eller av europeiska bolag så har det även influerat hur jag tänker kring utveckling i mitt dagliga arbete som konsult.
I denna artikel tar jag dessa tankebanor till sin spets och tar fram ett förslag på en så gott som komplett teknikstack för ett bolag som bedriver sin egen mjukvaruutveckling, oavsett om det är deras huvudverksamhet eller en sidoverksamhet. Alla program som listas nedan är antingen projekt med öppen källkod eller projekt med stängd källkod men som inte kräver uppkoppling till molntjänster. Jag har delat in stacken i tre delar med efterföljande kommentarer: Utvecklingsmiljö och CICD, Driftmiljö samt Produktivitet och kommunikation.
Utvecklingsmiljö och CICD
Först ut i vår hypotetiska teknikstack är alla de verktyg som krävs för att utveckla, testa och driftsätta mjukvara. Här finns det gott om öppna och molnfria alternativ, vilket gör att vi kan välja och vraka.
Versionshantering
Utvecklingsmiljön är det dagliga verktyget för programmerare och behöver vara både stabil och mångsidig. Här finns det tack och lov många bra, öppna och självhostade alternativ att välja bland.
För versionhantering med Git väljer vi bort det populära valet GitHub för det mer öppna och fristående GitLab. Om GitLab av någon anledning inte skulle passa så finns dock andra bra alternativ i form av Forgejo och Gitea. Det bör dock nämnas att GitLab innehåller mer funktionalitet och verktyg än både Forgejo och Gitea, varför de inte är perfekta alternativ.
Pipelines
För CICD-pipelines så finns det gott om motsvarigheter till det populära GitHub Actions. Mitt förstaval skulle vara GitLab Pipelines som är ett fullgott alternativ med många likheter. Har man däremot valt Forgejo eller Gitea så finns det även där motsvarigheter till GitHub Actions, men med färre features.
En sak som är viktig att tänka på och som gäller för alla CICD-pipelines är att en molnfri stack kommer att kräva att ni själva står för alla runners, det vill säga processer som lyssnar efter inkommande CICD-pipelinejobb, klonar repon och kör byggstegen. För detta problem finns det dock gott om dokumentation och delade erfarenheter, då det är vanligt att företag förr eller senare börjar använda egna runners för att det typiskt blir billigare än att använda molnbaserade runners när man nått en viss storlek.
Pakethantering
Pakethantering i en självhostad miljö kan med fördel hanteras med JFrog Artifactory, som är helt agnostisk till hur din miljö ser ut i övrigt. Sonatype Nexus är ett annat bra alternativ som tillåter självhostning. Har man däremot redan gjort valet att använda GitLab så kan man istället använda den inbyggda pakethantering där i. Här bör det dock nämnas att just för pakethantering är det svårt att bli helt-och-hållet självhostad eftersom man ofta behöver hämta paket från tredjeparter (Maven Central för Java, NPM för Javascript, Nuget för C#/.NET, osv). Beroende på vilket krav på säkerhet ditt företag har så kan man här välja mellan att underhålla en lokal kopia av en del av tredjeparts-repot eller att låta sin pakethanterare agera proxy till en eller flera tredjeparts-repon.
Driftsättning
För driftsättning så är min rekommendation verktyget ArgoCD eller alternativet Spinnaker. Dessa verktyg kopplas till versionshanteringssystemet och triggas av olika händelser där för att sedan laddar ner kod eller artefakter och driftsätta dem i molnmiljöer eller Kuberneteskluster. De kan även hantera mer komplexa driftsättningar som red/blue deployments, canary deployments, rolling releases och liknande.
Utvecklingsmiljöer och kodeditorer
När det kommer till IDE är mitt förstahandsval produkter från Jetbrains som Intellij IDEA, Pycharm, Rider, osv. Dessa består inte av öppen källkod, men har licenser och utforming som gör att de kan användas i miljöer helt utan kontakt med övriga internet, förutsatt att man inte behöver plugins (som i normalfallet kräver internetuppkoppling för att ladda ned). Vill man ha ett mer lättviktigt (och billigare) utvecklingsverktyg så finns även VSCodium att tillgå. Detta är en fork av Visual Studio Code som plockat bort de proprietära delarna av kodbasen samt de delar som kommunicerar med Microsofts servrar. Kombinerar man VSCodium med separat inhämtade plugins för olika språk och verktyg så kan man få ett nästan fullgott alternativ till Jetbrains IDE:er.
Sist men inte minst vill jag även tipsa om två alternativ till VSCodium som har en liten men växande skara följare: Zed och Pulsar. Dessa editorer är avancerade och feature-rika, men saknar dock den rikedom av plugins som finns för VSCodium.
Remote-utvecklingsmiljöer
I listpunkten för Remote-utveckling avser jag verktyg för där företaget av säkerhetsskäl inte vill att utvecklarmaskiner har några lokala kopior av källkoden eller tillhörande data. Ett vanligt sätt att lösa detta är endast tillåta utvecklings i virtuella miljöer där de fysiska utvecklarmaskinerna kopplar upp sig till den virtuella miljön med SSH eller olika remote desktop-verktyg. Har du ovan valt att använda Jetbrainsprodukter så löses detta med Jetbrains Remote Hub, men det går även att lösa med exempelvis sshfs, ett verktyg som skapar ett virtuellt filsystem som synkroniserar filer över SSH eller med rena virtualiserade desktops. Har du istället valt VSCodium så finns det ett plugin, Open Remote, som låter dig koppla upp till en virtualiserad miljö med SSH.
Det finns även remote-desktopapplikationer som lämpar sig för säker utveckling. Genom att sätta upp en komplett utvecklingsmiljö på en server (antingen fysisk eller virtuell) och sedan koppla upp sig mot den med ett säkert protokoll får man en isolerad miljö för utveckling utan att behöva kompromissa på resten av mjukvaran som finns tillgänglig för utvecklingsmiljön. Två bra program om man väljer att gå denna väg är Remmina och RustDesk.
Containers
När det gäller containers så är mitt förstahandsval en kombination av Podman, Podman Compose (en kompatibel klon av Docker Compose) samt Minikube för lokala Kuberneteskluster. Dessa verktyg ger dig allt du behöver för att skapa och köra lokala containers och är dessutom kompatibla med Artifactory och Gitlabs container-repos. Alternativt kan du använda vanliga Docker, Docker compose och MicroK8S för lokala containers och Kuberneteskluster. Det bör dock även här nämnas att Docker inte är ett perfekt val i miljöer med höga säkerhetskrav då containrar i sitt defaultutförande körs i ett priviligerat läge som ger dem onödigt breda rättigheter.
Operativsystem
Sist men inte minst kommer vi till valet av operativsystem för utvecklingsmiljöerna. Här är mitt förstahandsval (och egentligen enda val) en Linuxdistribution för desktops. Anledning till detta är att varken Windows eller MacOS är lämpade att användas i självhostade miljöer: Windows då den kräver internetåtkomst och MacOS då den överhuvudtaget inte kommer med något stöd för virtualisering. Det lämnar då bara Linux som alternativ. När det gäller specifika distributioner för utveckling är min rekommendation antingen en Debian-baserad distribution som Ubuntu eller Red Hats rivaler RHEL eller Fedora. Dessa distributioner innehåller en lagom blandning av “inkluderade batterier”, konfigurationsmöjligheter och professionell support.
I nästa del av denna spännande följetong i tre delar kommer vi att titta på driftmiljön för vår teknikstack.
