Geteilte Entwicklungsumgebungen auf Kubernetes-Basis Gitpod – Web-IDE und mehr

Entwickeln mit VS Code, auf GitHub, im Browser, auf leistungsfähiger Hardware – mit Gitpod geht das sogar auf einem simplen Tablet. Was das Open-Source-Projekt zu bieten hat, zeigt dieser Artikel.

Der Name des noch recht jungen Projekts – Gitpod Inc. wurde erst 2020 gegründet – lässt bereits vermuten, worum es in etwa geht: Entwicklung rund um Git/GitHub, „Pod“ deutet meist auf Dinge wie Kubernetes hin. Wie immer bei komplexen Produkten aus dieser Sparte dauert es vielleicht ein wenig, bis dem interessierten Homepage-Besucher klar wird, was „in etwa“ ganz konkret in der Praxis bedeutet.

Eine wirklich kurze Erklärung gibt es vermutlich nur für all jene, die bereits mit GitHub Codespaces vertraut sind: Gitpod ist direkte Konkurrenz mit sehr ähnlichem Leistungsspektrum, will allerdings schneller sein und setzt komplett auf Open Source. Codespaces-Nutzer, die weniger von Microsoft abhängen möchten, sollten also hellhörig werden.

Bildergalerie

Nun, auch bei Gitpod geht es ganz zentral um Microsofts GitHub-Plattform und Microsofts IDE VS Code, die derzeit mit Abstand beliebteste integrierte Entwicklungsumgebung. Allerdings arbeitet Gitpod alternativ auch mit den Plattformen Bitbucket und GitLab sowie mit den Desktop-IDEs IntelliJ IDEA, GoLand, PyCharm und PhpStorm. Wobei die Desktop-Unterstützung derzeit noch im Beta-Stadium läuft.

Was leistet Gitpod?

Ohne Codespaces-Wissen fällt die Erklärung etwas länger aus. Gitpod versucht ein ganz übliches Problem, oder vielleicht besser gesagt einen üblichen Aufwand zu lösen: Das Aufsetzen von und verteiltes Zusammenarbeiten in Entwicklungsumgebungen.

Das Aufsetzen einer solchen Umgebung kann schon mal eine ganze Zeit lang dauern. Eine IDE will eingerichtet sowie mit Einstellungen und Plug-ins versehen sein, Repositories müssen angebunden werden, Abhängigkeiten werden benötigt, gegebenenfalls müssen zusätzliche Datenbanken und Programmiersprachen installiert und verwaltet werden und so weiter. Vieles davon muss für jedes Projekt separat stattfinden. Obenauf könnten sogar noch aufgabenspezifische Einstellungen einfließen, die dann nach Abschluss wieder revidiert werden müssen.

Bei diesem ganzen Aufwand sind die Aspekte Zusammenarbeit und benötigte Hardware noch gar nicht inbegriffen. Geschweige denn die Frage, wie man die Zeit sinnvoll nutzt, während der Rechner mit der Einrichtung oder dem Bauen von Projekten blockiert ist. Und wenn solche Umgebungen immer wieder für neue Mitarbeiter, kurzfristige Projektbeteiligte oder externe Entwickler benötigt werden, wiederholen sich große Teile dieser Aufwände immer wieder.

Hier tritt Gitpod auf den Plan. Entwicklungsumgebungen mit all den oben angesprochenen Punkten können hier einmalig eingerichtet und dann per Klick aufgabenspezifisch als frische Instanz aufgerufen werden – natürlich komplett im Browser. Solche Instanzen lassen sich dann auch ganz einfach per Link für die Live-Zusammenarbeit teilen. Damit ist dann ein gleichzeitiges gemeinsames Editieren von Dokumenten möglich, wie man es zum Beispiel von Google Docs kennt. Zwei Kern-Features von Gitpod sind sicherlich die Prebuilt-Workspaces und der VS-Code-Server, dazu mehr im nächsten Kapitel.

Der Namensteil „pod“ hat es schon angedeutet: Gitpod selbst ist eine Kubernetes-Anwendung, basiert also auf orchestrierten Containern. Und wie bei Containern üblich, sind die Arbeitsumgebungen flüchtig (ephemeral) konzipiert: Nutzen, löschen, frische Instanz starten. Oder eben eine weitere Instanz für eine parallele Aufgabe öffnen – kein blockierter Rechner mehr als Nadelöhr.

Freilich kommt es dann doch wieder zur Hardware-Frage: Gitpod kann selbst gehostet werden, aber sofern keine eigenes (Cloud-)Rechenzentrum zur Verfügung steht, dürfte die SaaS-Variante näher liegen. Hier werden diverse Tarife angeboten.

In der kostenlosen Variante stehen 50 Arbeitsstunden und 4 parallele Arbeitsumgebungen für öffentliche wie private Repositories zur Verfügung, bei einem fixen Timeout bei Inaktivität von 30 Minuten. Für 8 (Personal), 23 (Professional) oder 35 Euro (Unleashed) pro Monat und Nutzer stehen dann bis zu 16 parallele Umgebungen, beliebig viele Arbeitsstunden, mitarbeiterspezifische Abrechnungen und ein Timeout von bis zu 4 Stunden zur Verfügung.

Praktische Einblicke

Das Alles klingt soweit vermutlich arg theoretisch. In der Praxis ist zumindest der Einstieg recht simpel und einleuchtend: Am einfachsten geht das wohl, indem man sich bei Gitpod mit einem GitHub-Konto einloggt und dann einfach das Präfix „gitpod.io/#“ vor die URL eines eigenen GitHub-Repositories setzt, also etwa „https://gitpod.io/#https://github.com/bili123/cli-help“.

Der Anblick dürfte dann vertraut sein, ein ganz normales VS Code im Browser (auch wenn es Gitpod Code heißt), betrieben durch Gitpods OpenVSCode-Server, oder auf Wunsch auch im Desktop-VS-Code. Im Browser verläuft das hier in Tests reibungslos, auf dem Desktop hakt es ein wenig – aber da bei Gitpod sowieso Browser-First gilt und die Desktop-Apps offiziell Beta sind, ist das zunächst nicht weiter schlimm.

Die Arbeit verläuft dann wie gewohnt, git-Kommandos laufen wahlweise über GUI oder die Konsole, es können Erweiterungen vom Marktplatz bezogen werden und so weiter, eben ein ganz normales VS Code. Nicht via Git gespeicherte Änderungen verbleiben übrigens natürlich im Workspace, wenn zum Beispiel der Browser-Tab geschlossen wird (was einen dreiminütigen Timeout und dann automatisches Stoppen nach sich zieht).

Das zweite oben erwähnte Kern-Feature sind Pre-Builds: Gemeint sind hier Aufgaben zum Aufbauen eines Workspaces, wie etwa Laden von Änderungen, Installation von Abhängigkeiten, Bauen von Skripten und so weiter. All jene Aufgaben werden nicht beim Start einer neuen Umgebung ausgeführt, sondern immer dann, wenn Änderungen ins Repository gepusht werden! Und so dauert der Aufruf eines neuen Workspaces gerade mal ein paar Sekunden. Gitpod agiert hier also in etwa wie ein Continuous-Integration-System. Etwas genauer: Für Pre-Builds werden in der Konfigurationsdatei „gitpod.yml“ hinterlegte Kommandos nach jedem empfangenen Push ausgeführt.

Im Alltag könnte die Nutzung von Gitpod ganz heruntergebrochen im Grunde einfach heißen, dass nicht mehr VS Code auf dem Desktop gestartet und dann ein Projekt aktualisiert wird, sondern stattdessen schlicht ein Gitpod-Workspace im Browser geöffnet wird. Das Ergebnis ist immer gleich: Entwickler landen in der gewohnten VSC-Entwicklungsumgebung. Sie müssen sich nur um weniger kümmern.

Der Container für Workspaces basiert übrigens (derzeit) auf Ubuntu 20.04 LTS, Details liefert das Workspace-Dockerfile.

Theia

Wer sich mit Gitpod beschäftigt, stößt schnell auf Gitpod-Projekt-Theia, ein Framework zum Erstellen eigener IDEs in Anlehnung an VS Code, aber mit Browser-First-Maxime. Sinn der Sache war im Grunde, ein herstellerunabhängiger VSC-Klon für den Browser als Gitpod-IDE. Allerdings gab es Probleme mit VSC-Erweiterungen.

Ein Zugriff direkt auf den VSC-Marktplatz war nicht möglich und das Adaptieren von VSC-Neuerungen in die Theia-basierte IDE gestaltete sich zunehmend aufwändig. Und so wurde dann bei Gitpod von VSC-ähnlich zu VSC selbst gewechselt, für den Browser betrieben über den eigenen OpenVSCode Server. Dennoch lebt das Projekt als Eclipse Theia fort und es gibt auch einige konkrete IDEs auf Theia-Basis.

Für Gitpod selbst spielt es keine Rolle mehr – sollte hier aber aus einem simplen Grund nicht unterschlagen werden: Viele Artikel, offizielle Blog-Beiträge und teils die Doku beziehen sich noch auf Theia, was bisweilen etwas verwirrend ist – vor allem, wenn sich in offiziellen Dokumenten Links auf einen Theia-Workspace finden, einen aber natürlich in eine VSC-Instanz führen. Zumal Theia-basierte IDEs nahezu komplett wie das Original-VSC aussehen können. Ein Beitrag zum Switch findet sich im Gitpod-Blog.

(ID:47951497)