Visual Studio Code im Web mit Gitpod: Ein Gewinn für jede Tool-Sammlung
Es ist erstaunlich, wie schnell der Editor Visual Studio Code(öffnet im neuen Fenster) (VS Code) die Entwicklergemeinde überzeugt hat (Platz 1 im Stack Overflow Developer Survey Ranking 2021). Selbst diejenigen aus der Linux-Fraktion, die Microsoft historisch bedingt, aber aus gutem Grund kritisch gegenüberstehen.
Der Konzern aus Redmond hat mit dem Tool viel richtig gemacht und eine große Schar an Open-Source-Entwicklern um sich versammelt (aktuell 1.640 Contributors). Sie tragen dazu bei, dass das Schweizer Microsoft-Team um Erich Gamma alle paar Wochen ein neues Release für Windows, Linux und MacOS herausbringen kann.
Angefangen hat alles mit dem Monaco Editor(öffnet im neuen Fenster) , um den herum VS Code gebaut ist und der am 14. April 2016 erstmals veröffentlicht wurde. Das Spannende an Monaco beziehungsweise VS Code ist, dass es konsequent mit Webtechnologien geschrieben ist, also HTML, CSS und Javascript. Verpackt und ausgeführt wird es mittels des von Github entwickelten Frameworks Electron(öffnet im neuen Fenster) , das wiederum auf Node.js(öffnet im neuen Fenster) und der quelloffenen Browser-Engine Chromium(öffnet im neuen Fenster) von Google basiert.
Nicht verwunderlich ist, dass die Entwickler vom Start weg einen richtig guten Editor gebaut haben, der dem damals ersten Chromium-basierten Tool Brackets(öffnet im neuen Fenster) von Adobe direkt Konkurrenz machen konnte. Denn Erich Gamma war viele Jahre lang Leiter der Entwicklungsumgebung Eclipse(öffnet im neuen Fenster) und weiß daher um die Bedürfnisse der weltweiten Entwicklergemeinde.
Erstaunlich ist hingegen, dass VS Code, obwohl es auf Webtechnologien basiert, einige Jahre gebraucht hat, um es aus seinem Electron-Karton heraus direkt in den Browser zu schaffen. So kündigte Microsoft erst 2020, zwei Jahre nach der Übernahme von Github, github.dev(öffnet im neuen Fenster) an. Allerdings ist dies lediglich ein Aufrufziel für den neu eingeführten Magic Dot und öffnet ein auf Github gehostetes Projekt im Browser.
Wer es ausprobieren mag: Einfach auf irgendein Github Repository gehen, die Taste PUNKT drücken, und das Projekt öffnet sich in einem VS Code Browser-Fenster. Eine Variante davon ist vscode.dev(öffnet im neuen Fenster) , das nicht nur Github-Projekte öffnen kann, sondern jedes beliebige von der eigenen Festplatte.
Mit beiden Browser-Editoren kann man wunderbar unterwegs coden, starten kann man die Projekte allerdings nicht und damit auch den eigenen Code nicht auf Lauffähigkeit validieren. Es fehlt der Unterbau, es ist somit keine echte IDE. Kein Pre-Processing via Grunt oder Gulp, kein startender Web-Server oder Ähnliches, schlicht weil es keine Konsole gibt, die mit dem Betriebssystem kommunizieren könnte.
.jpg)
Microsoft kündigte 2020 aber ein weiteres Tool an, das genau diesen Unterbau via Cloud-Container mitbringen soll: Github Codespaces(öffnet im neuen Fenster) . Seit ein paar Wochen werden die Beta-Zugänge ausgeweitet, ab August soll es für Team und Enterprise Cloud-Pläne verfügbar sein.
Ein Team um Sven Efftinge und Anton Kosyakov aus Kiel stellte sich aber schon 2017 die Frage: Warum nicht eine Online-Entwicklungsumgebung bauen? Sie riefen das Projekt Theia unter dem Dach der Eclipse Foundation ins Leben.
Cloud-basierte Entwicklungsumgebung aus Kiel: Gitpod
Die Idee war, eine Remote-First IDE zu entwickeln, die sowohl lokal als auch im Browser läuft und die bereits zahlreich vorhandene VS-Code-Erweiterungen voll unterstützt. Das eigentliche Produkt um Theia herum nannten die Entwickler Gitpod (gitpod.io)(öffnet im neuen Fenster) .
Obwohl es noch heute zahlreiche Theia-Lösungen wie Eclipse Che, Stackblitz oder den Google Cloud Shell Editor gibt, entschied sich Gitpod Ende 2020, zur VS Code Plattform zu wechseln, nachdem Gamma und sein Team den Remote Support in VS Code(öffnet im neuen Fenster) zur Verfügung gestellt hatten, auf dem unter anderem github.dev basiert.
Da Microsoft aber beschlossen hatte, die Server-Komponente zunächst nicht unter Open Source zu stellen (das kommerzielle Github Codespaces lässt grüßen), erstellte Anton Kosyakov nach eigenen Angaben in vier Tagen eine erste Arbeitsversion des Open VSCode Servers(öffnet im neuen Fenster) , der im September 2021 veröffentlicht(öffnet im neuen Fenster) wurde.
Zwar machte Microsoft nicht einmal einen Monat später die eigene Server-Lösung ebenfalls frei verfügbar - allerdings mit einigen Einschränkungen unter anderem bezüglich der Erweiterungen, die bei Gitpod über das Portal Open VSX Registry(öffnet im neuen Fenster) zu beziehen sind, da der Microsoft Extension Marketplace(öffnet im neuen Fenster) für Microsofts eigene Produkte vorbehalten ist.
Der Name Gitpod verrät schon einiges über die Technik hinter dem Dienst. Git steht für das System der Dateiverwaltung hinter dem Editor und pod für die Servertechnik unter dem Editor.
Der Name und die Technik dahinter
Quellcode liegt heutzutage (hoffentlich) nicht mehr nur lokal auf einer Festplatte, sondern zentral und verwaltet durch eine Quellcode-Management-Software. Der momentane Goldstandard in diesem Bereich ist das von Linus Torvalds 2005 initiierte freie Git(öffnet im neuen Fenster) , eine verteilte Versionsverwaltung, welche die Basis populärer Entwicklerplattformen wie Github, Gitlab oder Bitbucket darstellt.
Dazu kurz einen Schritt zurück in der Zeit: Es ist noch gar nicht so lange her, da nannten ITler eine Umgebung, auf der sie eine Server-Anwendung veröffentlichten " Maschinen ", weil es dafür zunächst Hardware (" Blech ") mit Prozessor, Hauptspeicher, Festplatten und dergleichen brauchte. Auf dieser wurde dann ein Betriebssystem der Wahl und darauf wiederum die besagte Anwendung installiert.
Wurde die Serveranwendung aber nur sporadisch genutzt, war die teure Hardware nicht ausgelastet, sprich: Ressourcen wurden verschwendet. Um dieses Problem zu beheben, wurde in den 70ern begonnen, an der Virtualisierung von Hardware zu arbeiten. Damit können sich mehrere logisch voneinander getrennte Systeme die Hardware teilen, um deren Auslastung zu erhöhen. In jeder der so entstehenden virtuellen Maschinen (VMs)(öffnet im neuen Fenster) können ein beliebiges Betriebssystem und darin die benötigten Serveranwendungen installiert und betrieben werden.
In diesem Konzept gibt es jedoch Redundanzen in Form des Betriebssystems. Will man zum Beispiel auf einem Blech fünf Linux-basierte Webserver laufen lassen, muss man dazu fünf womöglich identische Ubuntu-Installationen mitschleifen, die gewartet werden müssen.
Starten eines Gitpod-Arbeitsbereichs
Docker(öffnet im neuen Fenster) ist nicht die einzige, aber die bekannteste Software, die dieses Problem 2013 anging, indem eine weitere Schicht, in diesem Fall das Betriebssystem, abstrahiert wurde. Hier spricht man nun nicht mehr von einer Maschine oder VM, sondern von einem Container, in dem die Serveranwendung läuft. Für die Orchestrierung dieser Container gibt es seit 2015 die von Google initiierte Software Kubernetes(öffnet im neuen Fenster) , in der die kleinste einsetzbare Einheit als Pod bezeichnet wird, in dem einer oder mehrere Container enthalten sind, die sich die zugeteilten Ressourcen teilen.
Ein solcher Pod mit einem fertig installierten und konfigurierten Open-VS-Code-Server wird auf der Google Cloud Platform gestartet, wenn Nutzer ein Gitpod Workspace öffnen.
In Gitpod startet man ein auf Github, Gitlab oder Bitbucket gehostetes Projekt in einem sogenannten Workspace (Arbeitsbereich). Dazu genügt es, der URL seines Repositories die Zeichenkette gitpod.io/# voranzustellen.
Wer lieber Knöpfe mag, kann ein bereitgestelltes Bookmarklet(öffnet im neuen Fenster) verwenden und auf eine Browsererweiterung(öffnet im neuen Fenster) zurückgreifen, die einen Gitpod-Button in die Github-Oberfläche einfügt.
Wurde der Arbeitsbereich einmal gestartet und das Browserfenster ist geschlossen, steht der Arbeitsbereich eine Zeit lang auf dem Dashboard unter Workspaces zur Verfügung. Wenn man häufiger mit demselben Projekt arbeitet, ist es ratsam, sich dort unter Projects eine dauerhafte Verknüpfung anzulegen, wenn man weder auf manuelle URL-Änderungen noch Knöpfe steht.
Das I-Tüpfelchen ist die Installation eines dieser Gitpod-Projekte als Chrome-App und die Ablage in der Symbolleiste. Damit ist der Code nur einen Klick entfernt, und das Ganze fühlt sich aufgrund des reduzierten Browserfensters fast so an wie ein lokales VS Code.
Konfigurationen und Aufgaben beim Start
Neben den generellen Einstellmöglichkeiten bietet Gitpod eine individuelle Konfiguration je Projekt. Dazu wird im Stamm des Projektordners die Datei .gitpod.yml gesucht und verwendet.
Alle Einstellungsmöglichkeiten sind in den gitpod Docs(öffnet im neuen Fenster) gut dokumentiert.
Benutzerdefinierten Container verwenden
Der Standardcontainer, den Gitpod beim Start eines Arbeitsbereiches hochfährt, basiert auf Debian/Ubuntu und enthält bereits eine Menge an Frameworks und Sprachen wie Node, Java, Go und Python. Wer ein anderes Image verwenden möchte, kann dies über den Eintrag image einstellen, entweder indem ein öffentliches Image referenziert oder der Name eines Dockerfiles im Projekt angegeben wird.
Die Möglichkeiten sind zahlreich und im Abschnitt Custom Docker Image(öffnet im neuen Fenster) zu finden.
Installation von Node.js
Um ein Projekt in Visual Studio Code zum Laufen zu bringen, braucht es gerade im Node-Umfeld noch ein paar Dinge, die eingerichtet werden müssen. Das ist zum Beispiel die Installation der richtigen Node.js-Version und die der abhängigen Pakete mittels NPM oder einem anderen Paketmanager. Gleiches gilt natürlich für Gitpod, obgleich diese Maßnahmen nach dem Start der Arbeitsumgebung immer wieder durchgeführt werden müssen, wenn zum Beispiel der Pod nach einer Weile verworfen wurde.
Für diese wiederkehrenden Aufgaben bietet die Software in der .gitpod.yml den Abschnitt Tasks(öffnet im neuen Fenster) und dort in vorderster Front den Eintrag init. Im folgenden Beispiel werden Node 14.17, alle lokalen Pakete und ein globales Paket als Multi-Line Task installiert:
tasks:
- init: |
nvm install 14.17.2
npm install
npm install -g grunt-cli
Mit der Gruppierung und Benennung von Tasks, mit den Terminal-Anzeigeeinstellungen und den insgesamt drei Ausführungsstufen before, init und command ist es leicht, sich eine Konfiguration anzulegen, die den Arbeitsbereich fix und fertig hochfährt und bei der Nutzer den Überblick behalten.
Wer es noch schneller mag, kann Prebuilds(öffnet im neuen Fenster) einsetzen, die als Snapshot zur Erstellung eines neuen Arbeitsbereiches dienen. Diese Prebuilds verwenden die .gitpod.yml des Projekts und sind eng mit der verwendeten Quellcode-Verwaltung (derzeit Github, Gitlab und Bitbucket) verknüpft
So wird ein Prebuild jedes Mal neu erstellt, wenn veränderter Code in das Projekt eingecheckt wird. Schneller und bequemer von überall im Browser zu coden, geht kaum.
Erweiterungen automatisch einbinden
Beim Erstellen des Gitpod-Arbeitsbereichs lassen sich über die Konfigurationsdatei .gitpod.yml die Visual-Studio-Code-Erweiterungen einbinden, die zum Arbeiten erforderlich sind.
Am einfachsten geht das, wenn die Erweiterung auf der offenen Plattform Open VSX Registry(öffnet im neuen Fenster) vertreten ist, da Gitpod standardmäßig dort nach dem Muster ${publisher}.${name} sucht.
Hier ein Beispiel:
vscode:
extensions:
- HookyQR.beautify
- kamikillerto.vscode-colorize
Es lassen sich aber auch VSIX-Dateien aus anderen Quellen über die vollständige URL einbinden.
Microsoft bietet mit dem Visual Studio Marketplace(öffnet im neuen Fenster) zwar die primäre und größte Quelle an Erweiterungen an, verzichtet aber auf die Angabe eines kompletten Downloadpfades der VSIX-Datei.
Nutzer können diesen aber anhand des nachfolgenden Musters einfach nachbauen:
https://${publisher}.gallery.vsassets.io/_apis/public/gallery/publisher/${publisher}/
extension/${extension}/${version}/assetbyname/
Microsoft.VisualStudio.Services.VSIXPackage
Die notwendigen Information zu den Variablen Publisher, Extension und Version in diesem Muster sind über die Detailseite einer Erweiterung in Visual Studio Code erhältlich.
Die Ausgabe:
Name: vscode-hexo-utils Id: fantasy.vscode-hexo-utils Description: vscode extension for hexo Version: 0.2.1 Publisher: fantasy VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=fantasy.vscode-hexo-utils
Daraus wird in der .gitpod.yml folgender Eintrag:
vscode:
extensions:
-https://fantasy.gallery.vsassets.io/_apis/public/gallery/publisher/fantasy/
extension/vscode-hexo-utils/0.2.1/assetbyname/Microsoft.VisualStudio.Services.VSIXPackage
Einstellungen synchronisieren
Jede IDE sieht anders aus, je nach Geschmack und Vorlieben des Entwicklers. So gab es relativ schnell nach der ersten Veröffentlichung von VS Code die ersten Erweiterungen, welche die Einstellungen der IDE über mehrere Maschinen hinweg synchronisieren konnten (meist über Gists) - bis Microsoft sich des Features annahm und es direkt in die IDE integrierte.
Nun haben wir mit Gitpod eine neue, etwas anders geartete Instanz von Visual Studio Code, aber auch daran haben die Kieler gedacht. Auf die Daten der integrierten Synchronisation konnten sie zwar nicht zugreifen, allerdings schufen sie mit einer eigenen Erweiterung einen By-Pass, der genauso gut funktioniert.
Nach der Installation in VS Code und einem Neustart desselben meldet man sich an der Erweiterung mit dem gleichen Konto an, mit dem man sich bei Gitpod registriert hat. Danach lassen sich neben den Einstellungen auch Aufgaben, Code-Snippets-Erweiterungen und Tastaturkürzel synchronisieren.
Preise und Leistungen von Gitpod
Gitpod ist ein Unternehmen und muss sehen, dass es kostendeckend arbeiten kann. Daher gibt es - wie so oft - verschieden ausgebaute Pläne zu buchen.
Im Saas-Bereich sind es vier, wobei sich Free von den anderen Plänen lediglich in der möglichen Rechenzeit, dem Timeout und den parallel laufenden Workspaces unterscheidet.
So sind es im Free-Plan 50 Stunden, die man mit vier Workspaces arbeiten kann, bei Inaktivität werden die Pods nach 30 Minuten wieder heruntergefahren. Das ist ein faires freies Angebot für alle, die unterwegs mal coden wollen, aber die meiste Zeit über einen Rechner und ein lokal installiertes VS Code verfügen.
Man kann Gitpod aber auch selbst auf einer bestehenden Managed-Kubernetes-Umgebung hosten, zum Beispiel wenn man bereits Kunde von Clouddienstleistern wie Amazon, Azure oder Google ist.
Fazit
Es wird spannend zu sehen sein, inwieweit sich das Microsoft-eigene Github Codespaces gegen diesen sehr gut handhabbaren Gegenspieler wird behaupten können - wenn es denn mal in der Masse an den Start gegangen ist.
Das Team aus Kiel hat die Latte hoch gehängt, auch weil es fantastisch dokumentiert und strukturiert ist - ein echter Gewinn für jede Tool-Sammlung.
Kristof Zerbe(öffnet im neuen Fenster) arbeitet seit mehr als 25 Jahren in der IT in unterschiedlichsten Rollen wie Freelancer, Administrator, Datenbankentwickler, Coach, Web-Entwickler, Architekt, Devops-Engineer, Analyst, Team-Lead sowie aktuell IT-Manager und Führungskraft. Seine technologischen Schwerpunkte sind Web und Microsoft.