Bereits Anfang des Jahres erschien GitLab 10.7. Die wichtigste Neuerung betraf damals die GitLab Web IDE, welche Open Source gestellt wurde. Vor wenigen Wochen gewährte Dimitrie Hoekstra, UX-Designer bei GitLab, einen Einblick hinter die Kulissen und berichtete über die eigentliche Idee der Web IDE. Wir werfen einen genaueren Blick auf die Web IDE und die interessantesten Fakten ihrer Entstehung.

Die GitLab Web IDE ermöglicht es, kleine Fehler schneller zu korrigieren, da es nicht mehr notwendig ist, Branches zu wechseln oder Änderungen lokal zu verwalten. Ebenso können Merge Requests auf diese Weise leichter ausgeführt werden.

Obwohl die GitLab Web IDE bereits mit GitLab Ultimate 10.4 eingeführt wurde, war die Nutzung bis dato auf genau diese bezahlte Variante beschränkt. Mit GitLab 10.7 steht die Web IDE seitdem allen Nutzern zur Verfügung. Doch erst im Juni erklärte Dimitrie Hoekstra, UX-Designer bei GitLab, auf welcher Idee die Web IDE basiert und wie viel Arbeit zur Realisierung des Projekts geleistet wurde.

Die Idee hinter der WEB IDE

Die eigentliche Idee, ursprünglich schlicht „Repo Editor“ genannt, stammt von Staff Developer Jacob Schatz. Er beobachtete, welche Probleme es Nicht-Entwicklern bereitete, mehrere Dateien zu bearbeiten und diese Änderungen zu übernehmen. Bei GitLab plante man schon länger, auch in Absprache mit CEO Sid Sijbrandij und VP of Product Job van der Voort, die Implementierung einer integrierten Entwicklungsumgebung (IDE), allerdings war ihnen nicht klar, wie man dieses Ziel erreichen konnte und welche genauen Probleme es tatsächlich lösen würde.

Nach langen Diskussionen innerhalb des GitLab-Teams und einem eigens erstellten Proof of Concept von Schatz, nahm das Konzept langsam Form an:

Jacob set up a proof of concept where he made our file viewer work in the context of a file editor. It removed the page refresh when switching between files and it approached editing from a branch perspective instead of per file. – Dimitrie Hoekstra

Vom Repo-Editor zur Web-IDE

Allein die Erstellung des Proof of Concept war mit einem enormem Arbeitsaufwand verbunden. Product, UX und andere Entwickler brachten sich mit ein, um zu sehen, ob dieses Produkt auf dem Markt bestehen kann.

Quelle: GitLab

Einige Diskussionen später entstand, basierend auf bestehenden UI-Paradigmen und inspiriert durch andere Code-Editoren wie VSCode und Atom, das aktuelle dreigeteilte Layout. Obwohl die GitLab Web IDE erst seit Kurzem für alle öffentlich zu Verfügung steht, ist sie bereits in einer Vielzahl verschiedener Use Cases nützlich, was auch am Monaco Editor liegt, der in die Entwicklungsumgebung integriert wurde. GitLab plant zukünftig noch weitere Verbesserungen, wie beispielsweise eine Live-Umgebung, um den Code zu testen und Review-Diskussionen der Codeüberprüfung, welche direkt lösbar sind.

Verbesserungen in GitLab 11

Weitere Verbesserungen gibt es auch in GitLab 11. In der gerade erst veröffentlichten Version kann nun ein Wechsel zwischen verschiedenen Merge Requests erfolgen, ohne dafür die IDE verlassen zu müssen. Das funktioniert auch über unterschiedlichste Projekte hinweg, wenn der Nutzer das Merge Request selbst erstellt hat oder ihm zugewiesen wurde. In der Web IDE steht zudem eine Anzeige des CI-Status des gegenwärtig geöffneten Commits zur Verfügung, die fest in die IDE-Ansicht integriert ist. Außerdem ist es möglich, den CI-Status für jeden einzelnen Job und dessen jeweilige Logs in der IDE einzusehen. So könne man Probleme mit der Continuous Integration nun beheben, indem man den nicht ausgeführten Job unmittelbar neben die entsprechende Datei lege, wie Ramos im Blogpost zum Release ausführt.

Den lesenswerten Artikel von Dimitrie Hoekstra über den Denk- und Entscheidungsprozess hinter der Erstellung der GitLab Web IDE, finden sich auf dem Blog von GitLab. Neben der Geschichte zur Realisierung des Konzepts, findet sich hier eine Liste der Stufen, die das Designkonzept durchlaufen hat.