GitLab – Insights https://insights.tuhh.de/de/ Einblicke in das digitale Experimentierfeld für Lehre und Forschung an der Technischen Universität Hamburg Thu, 06 May 2021 20:28:14 +0000 de-DE hourly 1 https://wordpress.org/?v=4.9.17 https://insights.tuhh.de/wp-content/uploads/2018/06/cropped-Flavcon_I_Kusiv-32x32.png GitLab – Insights https://insights.tuhh.de/de/ 32 32 Nachhaltige digitale Orientierungsangebote – Ein Erfahrungsbericht von Hop-on https://insights.tuhh.de/de/blog/hooutuhh/2020/05/25/notwendigkeit-und-nachhaltigkeit-digitaler-orientierungsangebote-ein-erfahrungsbericht-von-hop-on/ Mon, 25 May 2020 08:00:50 +0000 https://insights.tuhh.de/?p=21014

Mit einem lachenden und einem weinenden Auge haben wir uns die vielen großartigen Ideen beim HFD-Hackathon angesehen. Vor allem acht der 76 vorgestellten Projekte planen, Orientierungsangebote zu entwickeln, die die zunehmend unübersichtliche Anzahl an Beratungsangeboten oder digitalen Tools und Lernangeboten zielgruppenspezifisch strukturieren und Nutzer_innen auf ein passendes Angebot hin- oder direkt verweisen.

So fokussiert die Toolbox eine Orientierung hinsichtlich vorhandener Tools in der digitalen Bildung anhand bestimmter Kategorien. Sie soll kollaborativ weiterentwickelbar sein. Die Plattform zu Rassismus an Hochschulen soll das aktuell nicht ausreichende Angebote an Antidiskriminierungsberatung ergänzen und einen Raum zum Austausch von Menschen bieten, die von Diskriminierung betroffen sind bzw. unterstützen wollen. Das Digital Education Dashboard (DigEDa) soll einen Überblick über Tools der digitalen Lehre geben – jedoch nach Institutionen filterbar – und zudem konkrete Empfehlungen geben. Darüber hinaus sollen Lehrende (persönlichen) Support bei technischen Problemen erhalten. Die Plattform „Chancengleichheit für alle Studierende-StudEqual“ soll barrierefreie Lerninhalte und Unterstützungsangebote bereitstellen. Der Beratungslotse „Follow me“ soll Studierenden helfen, ihren Weg durch den “Beratungsdschungel“ an einer Hochschule ausgehend von einem Entscheidungsbaum zur richtigen Anlaufstelle bzw. Person für ihr Anliegen zu finden. Das Toolcast: digitale Tools in Lehrerbildung und Schule strebt eine expert_innenbasierte Erprobung und Auswahl verschiedener Werkzeuge und Plattformen sowie der Ergebnisdarstellung an. Der RecoMentor – Lern- und Information Recommender ist ein KI-Empfehlungssystem für Lerninhalte. Survey² – Research goes on(line): Community für Onlineforschung will eine Plattform entwickeln, auf der Forschenden sowie Studierenden u.a. passende Tools empfohlen werden.

Diese Projektideen zeigen, dass ein hoher Bedarf, nicht nur an konkreten Tools und Angeboten, sondern auch der zielgruppen- und themenspezifischen Orientierung vorhanden ist.

Rückblick

Mit derselben Idee sind wir 2016 mit Hop-on gestartet. Wir wollten Erwachsenen und insbesondere erwachsenen Neuankommenden mit Fluchtgeschichte und dem Wunsch, einen (anerkannten) Berufs- oder Studienabschluss zu erreichen, einen möglichst nachvollziehbaren Weg durch das mehr als komplexe föderale Bildungssystem mit unterschiedlichsten Beratungs- und Unterstützungsangeboten sowie die rechtlichen Rahmenbedingungen – insbesondere dem Asyl- und Sozialrecht – bahnen und sie an individuell passende Beratungs- und Weiterbildungsinstitutionen verweisen. Ziel war es, selbstbestimmte Entscheidungen in einem System zu ermöglichen, das durch Intransparenz und strukturelle Hindernisse, aber auch von Ausgrenzungen geprägt ist. Hop-on wurde von der TU Hamburg und dem Projekt EMSA bei der INBAS GmbH  initiiert und in Kooperation mit der Kiron Open Higher Education gGmbH  und der DQG mbh weiterentwickelt.

Nach intensiver Entwicklungsarbeit mit zahlreichen engagierten Menschen zwischen 2016 und 2018 haben wir uns aufgrund fehlender Ressourcen für die Pflege und Weiterentwicklung sowohl der Technik als auch der Inhalte in diesem Jahr schweren Herzens entschlossen, unsere Webpräsenz zu beenden und das Projekt zu archivieren. Hier möchten wir Einblick in die Entwicklung geben und unsere Erfahrungen über zu berücksichtigende Schritte und Rahmenbedingungen sowie den Archivierungsprozess teilen.

Was haben wir in Hop-on entwickelt?

  • Prozesse

    Verknüpfung von GitLab mit der Webseitenanwendung

    Integration der Übersetzungsplattform crowdin

    Übersetzung aller Hop-on-Inhalte in Arabisch, Englisch und Persisch (mit Ausnahme des Leitfadens für Berater_innen)

    Übersetzung der Untertitel von drei Videos in Arabisch, Farsi und Englisch

    Integration einer Newsseite

    Integration eines Formulars für individuelle Anfragen (Abschaltung nach Inkrafttreten der DSGVO)

    Beantwortung individueller Anfragen

Prinzipien der Entwicklung

Hop-on folgte in seiner Entwicklung vier grundsätzlichen Prinzipien:

Prinzip 1: Selbstbestimmung

Obwohl Hop-on das Erreichen eines beruflichen oder akademischen Bildungsabschlusses in den Fokus stellte, sollten Nutzer_innen ohne (anerkannten) Abschluss immer die Möglichkeit haben, andere Wünsche oder Bedarfe zu äußern. Dies beinhaltet sowohl die Unsicherheit über die eigenen Wünsche als auch die Entscheidung, Arbeit zu finden. In diesen Fällen stellte Hop-on weitere Informationen zu Beratungsangeboten und Online-Informationsplattformen zur Jobsuche zur Verfügung.

Prinzip 2: Offenheit

Alle Inhalte von Hop-on wurden von Anfang an in GitLab für die Öffentlichkeit zugänglich gemacht und unter CC-Lizenz gestellt. Dies erlaubt die Weiterverwendung und Anpassung der Inhalte. Wir wissen dabei nicht, ob von dieser Möglichkeit Gebrauch gemacht wurde.

Prinzip 3: Mehrsprachigkeit und Fairness

Die meisten deutschen Webseiten bieten Informationen nur auf Deutsch und Teile auf Englisch an. Während insbesondere Projekte und Angebote für Migrant_innen weitere Sprachen anbieten, sind insbesondere Persisch und Tigrinya unterrepräsentiert. Uns war wichtig, dass Übersetzer_innen für ihre Leistungen auch finanziell entlohnt werden und wir – als gut bezahlte Angestellte – nicht auf Ressourcen des dringend gebrauchten ehrenamtlichen Engagements zurückgreifen. Aufgrund unserer begrenzten finanziellen Ressourcen war eine Übersetzung nur in drei Sprachen möglich. Die Übersetzer_innen arbeiteten dabei in crowdin, welches einmal übersetzte Begriffe und Sätze speichert. Da wir die deutschen Texte in einfacher Sprache formuliert und zur Verständlichkeit konsequent dieselben Begriffe verwendet haben, erleichterte dies auch die Übersetzungstätigkeit.

Prinzip 4: Fachkompetenz und Zielgruppenorientierung

Das Lotsen durch Angebote muss durch entsprechende Fragen an die Nutzenden gestaltet werden. Für die Entwicklung der Fragen ist die Einbeziehung der Zielgruppen entscheidend, da nur sie wissen, welche Fragen sie haben. Die Einbeziehung erfolgte in Hop-on vor allem über Berater_innen, die mit der Zielgruppe von Hop-on arbeiten und sowohl die Fragen als auch Antworten bündeln konnten. Darüber hinaus haben wir teilnehmende Beobachtungen bei der Nutzung des Fahrplans und des Kompasses zur beruflichen Bildung von erwachsenen Neuankommenden und zwischen dem dem 25.07. und dem 30.10.2017 eine Nutzer_innenumfrage auf der Webpräsenz durchgeführt. Die Erkenntnisse – beispielweise zur Navigation oder unverständlichen Begriffen – wurden in Hop-on integriert. Grundsätzlich hätten wir uns jedoch eine stärkere Einbeziehung der Menschen gewünscht, die wir ansprechen wollten. Dies wird unter den Herausforderungen noch einmal aufgenommen.

Wie funktionierte der Hop-on-Fahrplan?

In Hop-on haben wir ausgehend von der Praxis der Bildungsberatung für erwachsene Migrant_innen bzw. Erwachsene aus Einwandererfamilien einen Fahrplan entwickelt, der die wesentlichen Fragen eines Beratungsgespräches abbildet. Inhaltlich basiert er auf einem Entscheidungsbaum (Abb. 1), der Ratsuchende ausgehend von ja/nein-Fragen über berufliche, schulische und akademische Vorerfahrungen und ihren Wünschen durch das System des Aufenthaltsrechts, des Sozialgesetzbuches II, des Berufsbildungsgesetzes und den Zugangsbedingungen zum Studium zu entsprechenden Ergebnissen mit Empfehlungen zum Aufsuchen einer persönlichen Beratung führt. In dieser sollten die Ergebnisse besprochen werden. Im verlinkten Kompass (Berufliche oder Akademische Bildung) waren die entsprechend recherchierten Beratungsangebote in den Bundesländern aufgelistet und grundsätzliche Fragen ausführlicher beantwortet. Er richtete sich zu Beginn an Erwachsene mit dem Ziel, einen Berufsabschluss nachzuholen und wurde in einer weiteren Projektphase für Studieninteressierte durch entsprechende Abfragen erweitert. Jedes Ergebnis war ausgerichtet an dem angegebenen Aufenthaltsstatus – Aufenthaltsgestattung, -genehmigung oder Duldung – da dieser maßgeblich über die Teilhabe an Bildungs- (aber auch Beratungs-)angeboten entscheidet. Insgesamt wurden 65 Ergebnisse verfasst. Dieser Entscheidungsbaum wurde über die Webpräsenz als Abfrage umgesetzt (Abb. 2 und 3).

Die Webanwendung Hop-on wurde auf Python Django aufgesetzt, weil die Anforderungen an ihre Funktionalität weiter gingen, als es bspw. WordPress oder andere Content-Management-Systeme bieten. Zudem war in der Entwicklung von Interesse, wie verschiedene Prozesse der (halb)automatischen Generierung von Open Educational Resources in eine Webanwendung integriert werden können. Damit war die Anwendung auch ein komplexer und sehr lernhaltiger Gegenstand für das Team.

Der Entscheidungsbaum des Fahrplans ist eine individuelle Implementierung in Django. Hierfür wurden die möglichen Wege zu Ergebnissen zunächst in Zeichnungen modelliert (vgl. Abb. 1). Um eine zuverlässige Reproduktion und Anpassung der Pfade im Fahrplan zu ermöglichen, wurden die drei Entscheidungsbäume für “Aufenthaltsgestattung”, “Aufenthaltserlaubnis” und “Duldung” als Skripte implementiert, mit denen eine relationale Datenbank populiert werden kann. Auf dieser Datenbank aufbauend entstand dann die Implementierung des Fahrplans.

Herausforderungen und lessons learned

Herausforderung 1: Zielgruppenorientierung vs. Zeit und Geld

Ein befristetes Projekt wie Hop-on ist darauf ausgerichtet, so schnell wie möglich Ergebnisse zu produzieren. Dieser Druck kann dazu führen, dass die eigentlichen Zielgruppen zu wenig in die Entwicklung einbezogen werden. Partizipative Formate zu organisieren, umzusetzen und auszuwerten, erfordert Zeit. Auch das Erreichen der Zielgruppen ist kein Automatismus einer Webpräsenz. Grundsätzlich ist es schwierig, als kleines Projekt so viel Aufmerksamkeit zu generieren, dass die angestrebten Zielgruppen davon wissen und es nutzen können. Wir waren auf verschiedenen Veranstaltungen, zum Beispiel beim Digitalen Flüchtlingsgipfel. Wir waren bestrebt, insbesondere an Initiativen von Neuankommenden wie Syrer-Azubis und Make it German anzuknüpfen. Die Videointerviews sollten den Menschen Raum geben, die die in Hop-on beschriebenen Wege gegangen sind. Insgesamt hätten wir uns gewünscht, ein größeres festes und diverseres Team zu sein und partizipativer vorgehen zu können – sowohl bei der Entwicklung der Inhalte als auch der technischen Umgebung.

Herausforderung 2: Wartung und Pflege von Inhalten vs. Kurzlebigkeit im Internet/auf dem Markt

Es ist großartig, dass mittlerweile fast alle Beratungsangebote Webpräsenzen haben, auf denen man sich über die Inhalte und Kontaktmöglichkeiten informieren kann. Problematisch ist, dass kontinuierlich

1) (befristete) Projektangebote verschwinden,

2) neue dazu kommen und

3) Änderungen an den Webseiten stattfinden.

Für ein Angebot, das Orientierung schaffen und Menschen durch die Tiefen des Internets begleiten möchte, heißt dies dementsprechend, kontinuierlich Links und Angebote zu prüfen und zu korrigieren. Eine Hilfe kann dabei ein Linkchecker sein, der automatisch benachrichtigt, wenn Links nicht mehr funktionieren. Angesichts der komplexen Inhalte und der unterschiedlichen Orte derselben Links in Hop-on, ist die Korrektur jedoch ein nicht zu unterschätzender Aufwand. Bereits Zertifikatsänderungen führen dazu, dass Links nicht mehr funktionieren. Da es sich vor allem um Beratungsangebote handelt, war eine Einbettung der Inhalte wie Kontaktinformationen keine Option, da sich diese auch stetig ändern können.

Webbasierte Angebote eignen sich besonders dazu, von Engagierten weiterentwickelt zu werden. Bei Hop-on war es insbesondere bei crowdin möglich, Übersetzungen in andere Sprachen selbstständig einzupflegen. Diese Möglichkeit wurde jedoch in nur sehr geringem Maße wahrgenommen. Grundsätzlich ist ein kollaborativer Ansatz unserer Meinung nach gut für kurzfristige, jedoch weniger für langfristige Angebote geeignet, es sei denn, er wird kontinuierlich angeregt und – nicht zu vernachlässigen – die Freiwilligen sehen einen Sinn, Mehrwert und Ziel in ihrem Engagement. Zudem stellt sich die Frage nach der Qualität. Hinsichtlich der Übersetzungen von Hop-on ist zu berücksichtigen, dass Behörden- und Fachbegriffe auch für deutsche Muttersprachler_innen oftmals nicht verständlich sind. Es kommt demnach nicht nur auf eine korrekte Übersetzung, sondern auch eine Einschätzung an, wann ein Begriff so landes- und sprachspezifisch ist, dass er nicht übersetzt, sondern der deutsche Begriff verwendet werden sollte. Für einen deutschen Grundlagentext bedeutet dies wiederrum, dass Begriffe erklärt werden. Zur Qualitätssicherung bräuchte es zudem Personen, die die Übersetzungen prüfen können – wo wir wieder bei Herausforderung 1 sind.

Herausforderung 3: Wartung und Pflege eines komplexen technischen Systems

Hop-on lag eine komplexe technische Infrastruktur zugrunde, die verschiedene Anwendungen verzahnte. Im Kontext der oben beschriebenen Fahrplanentwicklung konnten wichtige Erkenntnisse für die Anwendungsentwicklung mit GitLab, Docker und Django gesammelt werden, die in einem späteren Projekt des ITBH, dem digital.learning.lab, aufgegriffen und weiterentwickelt werden konnten. Insofern ist ein wesentlicher Gewinn darin zu sehen, dass soziale und kulturelle Praktiken, aber auch technische Kenntnisse und Fertigkeiten erworben und transferiert werden konnten.

Komplexe technische Systeme bergen somit Chancen, aber auch Risiken für eine Weiterentwicklung, da bereits kleine Veränderungen zu Fehlern im Zusammenspiel dieser führen können. Aus unserer Erfahrung braucht es demnach entweder einfache Anwendungen, die auch mit wenig Entwickler_innen-Knowhow entwickelt und gepflegt werden können. Oder es braucht eine verlässliche Ausstattung mit technischem Personal, das auch nach dem Aufsetzen des technischen Systems kontinuierlich ausreichende Ressourcen hat, sich um Probleme und Weiterentwicklung zu kümmern. Es ist daher die Frage zu stellen, welche Aufgabe Hochschulen an dieser Stelle zukommt: Liegt diese in der Entwicklung lauffähiger Anwendungen, die als Produkte langfristig vorgehalten und gewartet werden können, oder in einem Moment des forschenden Lernens an neuen Technologien, zukunftsweisenden Szenarien und innovativen Ansätzen, dessen Erkenntnisgewinn einen Beitrag zur digitalen Transformation leisten kann. Die Antwort liegt vielleicht irgendwo dazwischen und fordert die Entscheidung heraus, ob unter den geschilderten Rahmenbedingungen, vor allem im Hinblick auf Personalressourcen, produktive Lösungen überhaupt anzustreben sind.

Archivierung

Da wir Hop-on über GitLab aufgesetzt haben, waren von Anfang an alle Inhalte archiviert und wurden von uns für die Öffentlichkeit freigeschaltet. Da die Ordnerstruktur jedoch nicht die übersichtlichste ist, haben wir als HOOU-Projekt das Glück, die Materialien zusätzlich auf der HOOU-Plattform zu hinterlegen, wo sie ebenfalls unter CC-Lizenz zugänglich sind.

Eine weitere Möglichkeit, die sehr attraktiv ist, wir jedoch ressourcenbedingt nicht umsetzen konnten, ist der Webrecorder. Angesichts der unzähligen Webseiten, insbesondere von befristeten Projekten, stellt dies eine weitere Möglichkeit dar, komplette Webpräsenzen zu archivieren, ohne die Interaktivität zu verlieren. Nachhaltigkeit sollte insbesondere in Zeiten des Internets von Projektbeginn an mitgedacht werden.

Wir haben mit Hop-on alle viel gelernt, darin besteht kein Zweifel, und wir sind froh, dass wir zumindest die entwickelten Materialien archivieren und weitergeben können. Was wir uns für alle wünschen, die solch – unserer Meinung nach – immer wichtiger werdenden Orientierungsangebote entwickeln, sind nachhaltige Ressourcen und Strukturen, um Orientierung als Teil des (digitalen) Bildungs- und Beratungssystems langfristig zu implementieren. Wir freuen uns, dass Survey² – Research goes on(line): Community für Onlineforschung einen Preis beim Hackathon gewonnen hat. Wir drücken den anderen Orientierungsprojekten jedoch sehr die Daumen, dass auch sie ihre Ideen nachhaltig umsetzen können.

Wir würden uns freuen, wenn unsere in einem großartigen Team von vielen engagierten Menschen entwickelten Ansätze weiterverwendet und -entwickelt werden. Ihnen und unseren Interviewpartner_innen gilt unser Dank: Ali, Andreas, Anne, Daphne, Dodo, Dr. Abouelmaati, Faisal, Fouad, Herr Cissé, Herr Mengesha, Isidora, Johanna, Konstantin, Lothar, Michael, Mohammad, Nazime, Omar, Prof. Dr. Dr. h.c. Garabed Antranikian, Sam, Sami, Stephan und Zeinah.

Gerne stehen wir für Fragen zu Verfügung.

Axel Dürkop, Christiane Arndt und  Dr. Tina Ladwig (TUHH)

 

Weitere Beiträge

Mehr Beiträge zeigen
]]> GitLab: kollaborativ und interdisziplinär die digitale Zukunft gestalten https://insights.tuhh.de/de/blog/tools/2018/11/04/kollaborativ-und-interdisziplinaer-die-digitale-zukunft-gestalten/ Sun, 04 Nov 2018 00:27:05 +0000 https://insights.tuhh.de/?p=14556

Der Einfluss von Software auf unsere Lebens- und Arbeitswelt wird immer deutlicher wahrnehmbar und verstärkt sich zusehends. So besteht bspw. das Internet, wie wir es heute in Form des World Wide Web hauptsächlich verwenden, nicht mehr nur aus statischen Webseiten, sondern aus komplexen Applikationen wie Shops oder sozialen Netzwerken. Auf unseren Mobiltelefonen befinden sich Apps, mit denen wir ständig interagieren und Daten austauschen, technische Geräte wie Waschmaschinen, Autos, Fahrkartenautomaten und Fernseher funktionieren nicht mehr ohne Software.

Software entsteht in interdisziplinärer Teamarbeit

U.a. aus diesem Grund ist eine oft gehörte Forderung dieser Tage, dass Menschen früh das Programmieren lernen sollten, um später in der Arbeitswelt bestehen zu können und besser zu verstehen, wie die Welt um uns herum funktioniert. Auch wenn diese Forderung vielleicht berechtigt ist und Grundkenntnisse der Softwareentwicklung in digitalen Zeiten nicht schaden können, liegt der eigentliche Kern der Sache woanders: Moderne Softwareanwendungen bestehen nicht nur aus dem Quellcode, der sie antreibt. Sie enthalten Informationen in Form von (bewegten) Bildern, Tönen, Texten und Daten, die erstellt und in die Anwendung integriert werden müssen. Häufig müssen die Anwendungen auch noch in zahlreiche weitere Sprachen übersetzt werden. Diese Aufgaben verteilen sich im Entwicklungsprozess von Software in der Regel auf ganz unterschiedliche Personen, Berufe und Professionen, und am Ende kommt ein multimediales digitales Produkt heraus, das durch Programmcode zusammengehalten wird und seine interne Logik und Funktionsweise erhält.

Was in diesem Sinne für Software gilt, ist auch auf digitale Medien allgemein übertragbar. Bücher sind heute zunächst immer digital vorhanden, auch wenn sie in einem letzten Schritt auf Papier gedruckt werden. Lehr-/Lernmaterialien in Form von PDF-Dokumenten, Webseiten oder Infografiken entstehen in der Regel durch Viele, die gemeinsam an einem Produkt arbeiten und ihren professionellen Teil dazu beitragen. Für eine technische Hochschule ist es daher nicht nur wichtig, das Programmieren zu lehren. Es ist heute ebenso wichtig, mit den Tools und Workflows vertraut zu machen, die Kollaboration und Teamarbeit an digitalen Artefakten erst ermöglichen. Software – und damit auch die Welt, in der wir in Zukunft leben werden – entsteht in interdisziplinärer Teamarbeit.

Daher sei an dieser Stelle die These gewagt, dass nicht jede und jeder unbedingt programmieren können muss. Wichtiger ist die Kenntnis von Kollaborationstools und -workflows, da sie auch nichtprogrammierende Menschen in die Lage versetzt, die digitale Zukunft mitzugestalten und sich aus seiner Profession heraus an digitalen Projekten beteiligen zu können. An der TUHH ebnen wir mit einer hauseigenen weltöffentlichen GitLab-Instanz dieser Kompetenzförderung den Weg.

Von der Open-Source-Bewegung lernen

GitLab ist eine Software zur dezentralen Zusammenarbeit an textbasierten digitalen Artefakten. Das bedeutet, dass Menschen weltweit verteilt, aber dennoch gemeinsam an Software, Webseiten, Texten und Datensammlungen arbeiten können. Sie müssen sich dazu nicht einmal persönlich kennen oder sehen und können doch Großes vereint zustande bringen. Diese Form der Kollaboration ist aus der Open-Source-Bewegung entstanden und erhielt 2005 neuen Schwung durch die Veröffentlichung von Git, einem Tool zur Verwaltung von Zwischenständen im Entwicklungsprozess von Software. Zu dieser Zeit war der Kollaborationsaspekt von Git noch nicht sehr ausgereift. Als 2008 das amerikanische Unternehmen GitHub mit seiner gleichnamigen Webplattform zum gemeinsamen Arbeiten an Code auf den Markt trat, veränderte sich die Entwicklungskultur der Open-Source-Gemeinschaft entscheidend: Durch den Mechanismus des Forkens ist es nicht mehr wie zuvor nötig, das Vertrauen einer Projektcommunity zu gewinnen, um Code beisteuern zu dürfen. Man fertigt nun online eine Kopie des Quellcodes an, verbessert ihn und stellt dann einen pull request an die Urheber_innen, mit dem diese aufgefordert werden, den Beitrag zu integrieren. Diesem Feature der Plattform ist es zuzuschreiben, dass sich die Entwicklung großer und kleiner Softwareprojekte im Open-Source-Umfeld rasant beschleunigte.

Die TUHH hostet eine eigene GitLab-Instanz

Für eine Hochschule stellt sich die Frage, ob die systematische Förderung von Kollaboration und Teamarbeit auf der proprietären Plattform GitHub im amerikanischen Rechtsraum strategisch klug ist. Rechtliche Aspekte in verschiedener Hinsicht sowie die Abhängigkeit von sich wandelnden Geschäftsmodellen im Startup-Sektor legen nahe, Alternativen im Bereich freier und quelloffener Software zu suchen. Aus diesen Gründen hat sich die TUHH entschieden, Kollaboration und Teamarbeit im skizzierten Sinne mit GitLab zu betreiben und aktiv zu fördern.

Seit dem 17. November 2016 hostet das Rechenzentrum der TUHH eine eigene GitLab-Instanz in der Community Edition. Der Prozess bis dahin ist eng verwoben mit dem HOOU-Projekt an der TUHH, in dem wir mit GitLab die ganzheitliche Entwicklung von Open Educational Resources (OER) implementiert haben. Am Prozess der Einrichtung und Bereitstellung des Dienstes waren und sind viele Akteur_innen der TUHH beteiligt, die gemeinsam daran arbeiteten, den Dienst weltöffentlich für alle Interessierten online zu stellen. Nichts Geringeres als interdisziplinäre und internationale Forschungs- und Lehrkooperationen sind das Ziel des öffentlichen GitLabs der TUHH. GitLab ist für viele Institute der Hochschule zu einem zentralen Werkzeug der Zusammenarbeit geworden, wir zählen bis heute über 1000 registrierte Nutzer_innen und entwickeln fortlaufend neue Ideen zum Einsatz in Forschung, Lehre und Projektmanagement.

Der Prozess bringt Akteur_innen näher zusammen

Darüber hinausgehend hat der Prozess der Einrichtung von GitLab viele Angehörige der TUHH in der Diskussion über die Digitalisierungsstrategie der Hochschule näher zusammengebracht. U.a. wurde die Arbeitsgruppe openTUHH gegründet, in der sich die Diskurse Open Education, Open Science und Open Access bündeln. Sie werden von verschiedenen Instituten, der TUHH-Bibliothek, dem Rechenzentrum und dem Präsidium verfolgt und gestaltet. Die Zusammenarbeit mit dem Datenschutzbeauftragten der TUHH hat dazu geführt, den Dienst von Anfang an sicher im Angebot der Hochschule zu verankern und alle Akteur_innen für die Anforderungen an Sicherheit, Datenschutz und verschiedene rechtliche Aspekte zu sensibilisieren. Schließlich hat sich eine monatliche Arbeitsgruppe zu GitLab herausgebildet, in der die Wünsche und Anforderungen der Nutzer_innen reflektiert werden, um die Nutzungsmöglichkeiten entsprechend anzupassen.

Zusammenfassung

Zu diesem Zeitpunkt können wir festhalten, dass GitLab mit seinen vielen technischen Möglichkeiten zahlreiche Nutzer_innen an der TUHH begeistert. Zudem zeigt der Prozess der Einrichtung und Bereitstellung, welche positiven Effekte sich auf verschiedenen Ebenen innerhalb der eigenen Hochschule ergeben können. In den zahlreichen Projekten, die wir bisher mit GitLab durchgeführt haben, haben sich Menschen mit unterschiedlichen Hintergründen, Erfahrungen und Kenntnissen produktive Teams gebildet, die gemeinsam freie Software und offene Bildungsressourcen entwickeln können.

Weitere Artikel zum Thema in diesem Blog

GitLab kam bisher in einer Reihe verschiedener Projekte zum Einsatz, die in den folgenden Beiträgen weiter ausgeführt werden:

Dieser Beitrag wurde verfasst von Axel Dürkop.

]]> GitLab als CMS einsetzen https://insights.tuhh.de/de/blog/tutorials/2018/10/04/gitlab-als-cms-einsetzen/ Thu, 04 Oct 2018 09:06:51 +0000 https://insights.tuhh.de/?p=14807

Ziel dieses Tutorials

Das folgende Tutorial zeigt, wie ein GitLab-Projekt für das gemeinsame Schreiben eines Textes eingerichtet und GitLab im Sinne eines Content Management Systems (CMS) genutzt werden kann. Die Autor_innen erhalten immer ein fertiges PDF bzw. LibreOffice-Dokument, wenn sie in GitLab einen Text schreiben bzw. ändern.

Idee und Motivation

Tools und Plattformen für die gemeinsame Arbeit an Texten gibt es mittlerweile einige: GoogleDocs, Etherpads und Hackpads sind hierbei sicherlich die bekanntesten, Lösungen im Rahmen der bekannten Office-Suiten ergänzen das Spektrum.

Neben diesen vielen Möglichkeiten gehen wir an der TUHH noch einen anderen Weg beim kollaborativen Schreiben, indem wir GitLab im Sinne eines Content Management Systems (CMS) einsetzen. Motiviert ist dieser Ansatz dadurch, dass wir auch Menschen, die nicht programmieren, an partizipative und kollaborative Prozesse im Netz heranzuführen möchten, an deren Ende ein digitales Artefakt steht. Diese können in ausführbarer Software, in kompletten Webseiten oder auch nur in Textdokumenten bestehen. Mit dem kleinsten gemeinsamen Nenner, dem Schreiben, wollen wir alle an der gleichen Stelle abholen und den Grundstein für eine interdisziplinäre Zusammenarbeit legen.

Voraussetzungen

Los geht’s!

Anlegen eines neuen Projekts und der Beispieldateien1

Zunächst legen wir in GitLab ein neues Projekt an. Dabei ist nichts Besonderes zu beachten. Nun erstellen wir drei neue Markdown-Dokumente mit Beispieltexten, einleitung.md, hauptteil.md und schluss.md. Das Tutorial funktioniert auch mit einer einzigen Datei, wir wollen aber schon an dieser Stelle die Zusammenarbeit mit mehreren vorbereiten. So könnten unterschiedliche Autor_innen für einzelne Teile bzw. Dateien in einem größeren Text- oder Softwareprojekt zuständig sein.

Die README.md wurde beim Anlegen des Projekts erstellt. Die Blindtexte stammen aus dem Blindtextgenerator. Wichtig: Die Dokumente sollten eine Leerzeile vor der ersten Überschrift enthalten, damit die Markdowndateien bei Zusammenfügen richtig erkannt werden.2

Unser Repository nach dem Anlegen von drei Beispieldateien in Markdown

Artefakte erzeugen: PDF- und LibreOffice-Dokumente

Ziel des nächsten Schrittes ist es, aus dem “Quellcode”, also unseren Markdowntexten, ein PDF bzw. LibreOffice-Dokument zu erstellen. Dieser Vorgang steht stellvertretend für einen Prozess, der continuous integration genannt wird und sich mittlerweile in der Softwareentwicklung etabliert hat. Kurz gesagt bedeutet er, dass neue Beiträge zum Quellcode kontinuierlich in das Gesamtprodukt einfließen und nach kurzer Zeit immer ein verbessertes und funktionsfähiges Produkt zur Verfügung steht.

Was wir in den folgenden Schritten tun, ist demnach nicht nur für den beschränkten Rahmen dieses Tutorials relevant. Vielmehr handelt es sich um Wissen, durch das die Mitarbeit auch in komplexeren Projekten möglich ist. Also – weiter!

Die Zutaten

Wir brauchen für nun folgenden Schritte vier Zutaten:

  • pandoc, ein kommandozeilenbasiertes Konvertierungstool, das aus unseren Markdowndateien die Zieldateien generiert
  • Docker, eine schlanke Virtualisierungslösung, die uns Container mit pandoc zur Verfügung stellen soll. In diesen Containern werden online unsere Zieldateien generiert.
  • einen GitLab Runner. Dabei handelt es sich um ein Programm, das wir beauftragen können, etwas ganz Bestimmtes für uns zu tun, wenn bestimmte Ereignisse eintreten. Es wird dafür sorgen, dass bei jeder Änderung einer Markdowndatei ein Dockercontainer gestartet wird, in dem mit pandoc die Zieldateien generiert werden.
  • eine Datei .gitlab-ci.yml, in der die bisherigen Zutaten entsprechend konfiguriert werden.

Die Konfiguration der Pipeline

Um continuous integration für unser Beispiel zu konfigurieren, verwenden wir die folgende .gitlab-ci.yml-Datei. Sie ist im Hauptverzeichnis unseres Repos anzulegen.3 In der offiziellen Dokumentation ist sehr ausführlich beschrieben, was hier noch zu welchem Zweck eingestellt werden kann.

image: marcelhuberfoo/pandoc-gitit

build:
  script:
    - pandoc *.md -o bericht.pdf 
    - pandoc *.md -o bericht.odt
  artifacts:
    paths:
      - "*.pdf"
      - "*.odt"

In der ersten Zeile steht, welches Dockerimage wir verwenden wollen. Das angegebene funktioniert gut, baut allerdings noch nicht auf der aktuellen Version 2.0 von pandoc auf. Es liegt bei Dockerhub und kann auch gegen andere oder eigene Images ausgetauscht werden.

In den restlichen Zeilen ist angegeben, welches Kommando in dem Dockercontainer ausgeführt werden soll, der jedes Mal vom GitLab Runner gestartet wird, um unsere Dokumente zu bauen.

Dabei sorgen die Zeilen

- pandoc *.md -o bericht.pdf 
- pandoc *.md -o bericht.odt

dafür, dass aus allen Markdowndateien im Verzeichnis die finalen Dokumente gebaut werden. Die Reihenfolge, in der wir die sie aneinanderhängen, ergibt sich aus der Nummerierung im Dateinamen.4

Das angegebene Dockerimage enthält eine lauffähige Version von pandoc, sodass wir den Befehl pandoc mit entsprechenden Parametern hier geben können. Wir tun dies zweimal, um die beiden verschiedenen Dokumentformate zu erhalten.

In dem Block, der mit artifacts überschrieben ist, sagen wir, dass wir die Endprodukte der Pipeline, also das, was generiert wurde, behalten möchten. Der Dockercontainer schiebt dann diese Artefakte zurück in unsere GitLab-Projekt, wo wir sie herunterladen können.

Pipelines

Pipelines sind in GitLab definierte Abläufe, in denen verschiedene Stadien eines Bauvorgangs oder auch build process nacheinander und parallel abgearbeitet werden. Unsere Pipeline hier ist sehr einfach aufgebaut, sie hat genau eine Stufe (stage), die in der .gitlab-ci.yml mit build benannt ist.

Nachdem wir unsere .gitlab-ci.yml angelegt haben, versucht GitLab die Konfiguration darin abzuarbeiten. Das gelingt noch nicht gleich, wie wir unter CI/CD -> Pipelines sehen können.

Die Pipeline nach dem Anlegen der Konfigurationsdatei. Sie bleibt momentan noch stecken.

Ein Klick auf das Label Pending führt zu einer nächsten Seite, die den Aufbau der Pipeline genauer darstellt. Hier taucht der Name unserer einzigen Stufe (stage) auf.

Detaillierte Darstellung der Pipeline

Ein weiterer Klick auf das Label build zeigt uns, woran es liegt:

Damit die Pipeline läuft, muss noch ein Runner zugewiesen werden

Wir haben noch keinen Runner für unser Projekt zugewiesen, der für unsere Pipeline zuständig ist. Wenn wir dem Link in der Meldung, Runners Page, folgen, können wir dies nachholen.

Den GitLab Runner zuweisen

GitLab Runner sind dafür zuständig, Jobs für uns zu erledigen. Sie können auf unterschiedliche Weise konfiguriert werden, was in der offiziellen Dokumentation von GitLab ausführlich beschrieben wird.

Im GitLab der TUHH stehen momentan zwei Runner zur Verfügung, die von Nutzer_innen der Instanz verwendet werden können. Unter Settings -> CI/CD -> Runners können diese geteilten Runner mit einem Klick auf Enable shared Runners aktiviert werden.

Aktivierung der Shared Runner

Ein erneuter Blick auf die Übersicht der laufenden Pipelines über CI/CD -> Pipelines zeigt, dass nach einer Weile unsere Pipeline abgearbeitet wird.

Erfolgreiche Pipeline

Ein Klick auf die Label Passed und auf der folgenden Seite auf build zeigt, was stattgefunden hat:

Logausgabe des Jobs

Unser GitLab-Runner auf flint2 zieht sich das angegebene Dockerimage marcelhuberfoo/pandoc-gitit und startet darauf einen eigenen Container. In den Container, den man sich als schlanke virtuelle Maschine vorstellen kann, clont der Runner nun den Inhalt unseres Repositorys und damit auch die drei Markdowndateien.

Anschließend lässt er auf den Dateien des Repositorys die Befehle laufen, die wir in der .gitlab-ci.yml angegeben haben, um letztlich die generierten Artefakte aus dem Container wieder in GitLab hochzuladen. Der Container hat nun seinen Dienst erfüllt und wird gelöscht, die Pipeline ist erfolgreich durchgelaufen. Aber wo sind jetzt unsere Dateien?

Zugriff auf die Artefakte

Auf die generierten Artefakte kann an verschiedenen Stellen zugegriffen werden.

Artefakte, die zum Job gehören

Artefakte, die in einem speziellen Job erzeugt wurden, können rechts neben dem Job Log über die Button Keep, Download und Browse gefunden werden (s. Screenshot oben).

Artefakte der letzten erfolgreichen Pipeline

Auf der Homepage des Projekts können die Artefakte der letzten erfolgreichen Pipeline heruntergeladen werden.

Die Artefakte an dieser Stelle stammen immer aus der letzten erfolgreich durchgelaufenen Pipeline.

Zusammenfassung und Ausblick

Wenn alles geklappt hat, sind wir nun in der Lage, mit mehreren Autor_innen an einem Textprojekt zu schreiben oder auch allein an einem größeren Projekt wie einer Qualifikationsarbeit oder einem Forschungsbericht.

Die Idee war, GitLab im Sinne eines CMS zu verwenden, um digitale Artefakte zu erzeugen. Der Content, den wir hier managen, sind die Markdowndateien, die Ausgabe erfolgt in einem PDF- bzw. LibreOffice-Dokument. In zukünftigen Tutorials werden wir uns ansehen, wie in dem gleichen Verfahren auch Webseiten gepflegt werden können. Der vorgestellte Ansatz ist übertragbar auf andere Szenarien und hat damit eine relativ große Reichweite. Mit anderen Worten: Es lohnt sich, die Lernkurve von GitLab zu erklimmen, weil es sich um sehr universelle Kenntnisse und Kompetenzen handelt.

Ausgehend von diesem Tutorial werden wir in Zukunft weitere Praktiken und Verfeinerungen betrachten. So ist es interessant zu sehen, wie das PDF-Dokument formatiert werden kann oder Bilder eingebunden werden können. Aber auch Workflows mit Fokus auf Kollaboration und Qualitätskontrolle sind zu betrachten.

  • Dürkop, A. & Ladwig, T. (2018). Kollaborativ schreiben mit GitLab. Markdown & Pandoc (2. Auflage, S. 196–205). Graz: ebooks.kofler.
  1. In der aktuellen Version von GitLab wird nach dem Anlegen eines neuen Projekts auch eine sogenannte Auto DevOps-Pipeline angelegt. Da wir diese nicht verwenden wollen, können wir sie über Settings -> CI/CD -> Auto DevOps deaktivieren, indem wir Default to Auto DevOps pipeline abwählen. Anschließend löschen wir noch unter CI/CD -> Pipelines die steckengebliebene erste Pipeline mit Klick auf den roten Button rechts.↩
  2. Der Grund dieser Vorsichtsmaßnahme ist, dass die meisten Editoren den letzen Umbruch eines Textdokuments löschen, um einen sauberen Abschluss zu haben. Damit ist aber die Raute (#) der folgenden Überschrift nicht mehr sauber vom vorhergehenden Text abgetrennt. Es kann auch \newpage vor der ersten Überschrift gesetzt werden, womit ein manueller Seitenumbruch erzeugt wird.↩
  3. Da es sich bei der .gitlab-ci.yml um das YAML-Format handelt, ist streng auf die korrekte Einrückung der Zeilen zu achten!↩
  4. Damit die README.md nicht auch in unser Dokument einfließt, benennen wir sie um in README.markdown. Dadurch wird sie immer noch als Markdowndatei von GitLab erkannt, aber wegen der anderen Dateiextension nicht mehr einbezogen.
    Das Umbenennen lässt sich erledigen, indem die README.md editiert wird und dann einen anderen Namen erhält.↩

Dieser Beitrag wurde verfasst von Axel Dürkop.

]]>