Kategorien
Seiten
-

IT Center Blog

Der GitLab Project LifeCycle geht in die zweite Runde

16. August 2021 | von
Symbolbild: Ein Kreis aus Pfeilen.

Quelle: Pixabay

GitLab wird an der RWTH Aachen gern und rege genutzt. Nach der Bearbeitung von Projekten fallen jedoch oft viele Daten an, die nicht mehr genutzt werden. Damit sich kein Berg an Datenmüll in GitLab anhäuft, wurde am IT Center ein Project LifeCycle für die RWTH konzipiert und eingeführt. Im März 2021 wurde dieser scharf geschaltet.

In den ersten Wochen haben wir von den Nutzenden einige Anpassungsvorschläge und Wünsche zum Prozess erhalten. Damit diese eingehend von der zuständigen Fachabteilung geprüft werden konnten, wurde der GitLab Project LifeCycle vorerst pausiert.

Die Überprüfungs- und Überarbeitungsphase wurde nun beendet. In diesem Beitrag stellen wir euch die mithilfe des Feedbacks vorgenommenen Anpassungen vor.

1. Feature „Archivierung“

Wer kennt es nicht: Manchmal besitzt man Projekte, an denen zwar aktuell keine Änderungen oder Aktivitäten vorgenommen werden, die man aber trotzdem noch regelmäßig nutzt. Oder aber man muss diese aus unterschiedlichen Gründen für einen längeren Zeitraum vorhalten.

Damit solche Projekte vom GitLab Project LifeCycle ausgeschlossen werden, weisen wir ausdrücklich auf das GitLab Feature „Archivierung“ hin. Sobald dieses aktiviert ist, wird das entsprechende Projekt in den Read Only-Modus versetzt. Der GitLab Project LifeCycle ignoriert diese Projekte dann.

Weitere Hinweise sowie eine Anleitung zum Feature „Archivierung“ findet ihr auf IT Center Help.

2. Anpassung der Fristen

Aufgrund der Rückmeldungen wurden die Fristen für den GitLab Project LifeCycle wie folgt angepasst:

  • Die Zeitspanne, ab der ein Projekt ohne Aktivität als inaktiv gilt, wird von 12 auf 24 Monate angehoben.
  • Der Zeitraum, zwischen der Benachrichtigung über die Markierung als inaktiv und der endgültigen Löschung des Projekts, wird von 8 Wochen auf 25 Wochen erweitert.
  • Die Gültigkeitsdauer für Verlängerungsanträge beträgt weiterhin 12 Monate.

3. Erinnerungen per E-Mail

Wir leben im digitalen Zeitalter, wo man täglich auf vielfältigen Kommunikationskanälen geradezu mit Nachrichten überschwemmt wird. Da kann schon mal eine einzelne E-Mail untergehen.

Deswegen erinnert euch der GitLab Project LifeCycle, falls ein Projekt als inaktiv gekennzeichnet wurde. Innerhalb der 25-wöchigen Frist zwischen Markierung als inaktiv bis Löschung des Projekts werden mehrere E-Mails versendet. Solltet ihr also nach der ersten E-Mail nicht tätig geworden sein, erhaltet ihr in der 12. und 24. Woche jeweils eine erneute E-Mail. Diese erinnert daran, dass das entsprechende Projekt aktuell noch als inaktiv markiert ist.

Sofern keine neue Aktivität am Projekt, keine Archivierung des Projekts und auch kein Antrag auf Verlängerung eingeht, wird mit Ablauf der Frist die Löschung des Projekts angestoßen.

Nach der Löschung des Projekts steht allen Projektinhabenden für weitere 4 Wochen ein Projekt-Export zur Verfügung. Der Export kann dann über einen zufällig generierten Downloadlink heruntergeladen werden.

Ablaufschema des GitLab Project LifeCycles.

Der vereinfachte GitLab Project LifeCycle.
Quelle: Eigene Darstellung

Wir sehen in diesen Anpassungen einen geeigneten Kompromiss zwischen euren Rückmeldungen und den anbieterseitig zu erfüllenden Anforderungen rund um den GitLab Project LifeCycle. Wir hoffen auf euer Verständnis, falls euer Vorschlag nicht berücksichtigt werden konnte.

Der GitLab Project LifeCycle wird ab dem 17.08.2021 mit den genannten Anpassungen wieder starten.

Ihr wollt mehr zu GitLab an der RWTH Aachen wissen? Dann empfehlen wir euch den Blogbeitrag Nice to know: Die ersten Schritte in GitLab an der RWTH Aachen. Schaut mal rein!

 

Weitere Hinweise zum GitLab Project LifeCycle sowie die ausführlichen Nutzungsbedingungen findet Ihr auf IT Center Help.

 

Verantwortlich für die Inhalte dieses Beitrags sind Matthias Becker und Linda Jörres.

8 Antworten zu “Der GitLab Project LifeCycle geht in die zweite Runde”

  1. Sehr informativer Beitrag, vielen Dank

  2. Bernhard sagt:

    Es mag den Verantwortlichen im IT Center immer noch nicht aufgefallen sein, aber ein wesentlicher Bestandteil einer Versionskontrollsoftware ist, dass man sich darauf verlassen kann, alte Versionen stets wiederherstellen zu können. Ich finde es wirklich schade, dass dies bei der Konzeption der Gitlab-Bereitstellung übersehen worden ist.

    Wenn die RWTH die dauerhafte Bereitstellung der eingerichteten Repositories ressourcenmäßig nicht stemmen kann, dann sollte sie die Nutzungsbedingungen ändern und z. B. nur Forschungsdaten zulassen (zurzeit Forschung, Lehre, Open Source). Die Projekte nach einer Weile – auch mit Nachfrage – zu löschen, ist jedenfalls das komplette Gegenteil eines zuverlässig bereitgestellten Versionskontrolldiensts.

    https://de.wikipedia.org/wiki/Versionsverwaltung#Hauptaufgaben

    • Jörres, Linda sagt:

      Hallo Bernhard,

      vielen Dank für deinen Kommentar. Zur Beantwortung deiner Punkte haben wir unsere Fachabteilung kontaktiert.

      1. Git ist nur für Projekte der Lehre zugelassen, oder OpenSource. Forschung ist nicht gestattet, wie du in den Nutzungsbedingungen nachlesen kannst:
      https://help.itc.rwth-aachen.de/service/ubrf9cmzd17m/article/1a0cfe327ffd46d7a62ab48df29c5b72/

      2. Wie im obigen Blogbeitrag unter „1. Feature „Archivierung““ beschrieben, gibt es die Möglichkeit Projekte zu archivieren, wenn sie nicht aktiv genutzt werden. Dann fallen sie nicht in den GitLab Project LifeCycle.

      3. Weiterhin ist es jederzeit möglich, in einem Projekt wieder aktiv zu werden – dann wird die Markierung entfernt und das Projekt nicht gelöscht.

      Solltest du weitere Fragen haben, wende dich gerne an unsere Kolleginnen und Kollegen vom IT-ServiceDesk (servicedesk@itc.rwth-aachen.de).

      Viele Grüße,
      das IT Center Blog Team

      • Bernhard sagt:

        Vielen Dank für die Antwort.

        Zu 1: Das hatte ich in der Tat falsch in Erinnerung. So herum ist es natürlich sehr schade; m. E. sollte die Universität diese Plattform gerade der Forschung bereitstellen, denn diese ist wohl am meisten auf zuverlässige und vertrauliche Speicherung solcher Daten angewiesen.

        Zu 2: Ja, ich weiß, dass man Projekte archivieren kann. Das hilft allerdings nicht bei Projekten, die sich naturgemäß nur langsam ändern. Solche müssen jetzt durch völlig sinnlose Änderungen „am Leben gehalten werden“, was das komplette Gegenteil von aussagekräftiger Versionierung ist. Das bedeutet, man muss sich in git log oder git blame ab sofort durch eine Menge sinnloser Änderungen wühlen, bis man das findet, was man eigentlich sucht.

        Zu 3: Siehe 2.

        Ich weise noch einmal darauf hin, dass DAUERHAFTE Vorhaltung alter Versionen eine zentrale Aufgabe eines Versionskontrollsystems ist. Dass dabei in manchen Fällen Datenmüll durch nicht mehr genutzte Projekte entsteht, ist ein unerfreulicher Nebeneffekt; das hätte die RWTH sich vor der Bereitstellung von GitLab überlegen müssen. Jetzt rückwirkend Projekte zu löschen, entwertet jedenfalls die Plattform sehr.

        • Jörres, Linda sagt:

          Hallo Bernhard,
          vielen Dank für deine Rückmeldung.
          Wir haben für dich noch einmal unsere Fachabteilung kontaktiert. Hier die Antworten:

          Zu 1.: Der erste Hinweis mit der Plattform für Forschung ist leicht beantwortet: Dafür haben wir eine zweite GitLab-Instanz git-ce.rwth-aachen.de.
          So wie es in den Nutzungsbedingungen steht:
          ——
          „GitLab wird auf zwei unterschiedlichen Serverinstanzen angeboten.

          Die Instanz „git.rwth-aachen.de“ wird mit einer „GitLab for Education“ Lizenz betrieben und darf nur für die Ausbildung von Studierenden und das Entwickeln von OpenSource Software ohne Gewinnerzielungsabsicht genutzt werden. Die Einhaltung der zugrundeliegenden Lizenzbedingungen von GitLab (https://about.gitlab.com/terms/#edu-oss) ist dabei verpflichtend.

          Die Instanz „git-ce.rwth-aachen.de“ unterliegt einer „Community Edition“ Lizenz. Sie bietet gegenüber der „GitLab for Education Edition“ weniger Funktionen, die Lizenzbedingungen erlauben aber eine freiere Nutzung.“
          ——
          Die kompletten Nutzungsbedingungen kannst du auf IT Center Help finden:
          https://help.itc.rwth-aachen.de/service/ubrf9cmzd17m/article/1a0cfe327ffd46d7a62ab48df29c5b72/

          Zu 2.-3.: Es ist klar, dass es Projekte gibt in denen mehr Aktivität herrscht als in anderen. Wenn jedoch für 2 Jahre keine Aktivität festzustellen ist, sollte ein kleines Lebenszeichen alle 2 Jahre nicht allzu viel verlangt sein, wenn das Projekt tatsächlich noch benötigt wird. Zumal hier sämtliche Aktivitäten für ein Projekt gezählt werden: Commits, Pushes, Merges, Issues, Branches, Mitgliedschaftsänderungen, Wiki Änderungen, Kommentare, etc.
          Ansonsten kann man es mit dem Archiv auch für längere Zeit stilllegen und bei Bedarf wieder aus dem Archiv herausholen.

          Darüber hinaus werden Projekte nicht einfach so gelöscht, sondern mit Hilfe des GitLab Project LifeCycle mehrmals nachgefragt, ob das Projekt noch benötigt wird.
          Mit einer Aktivität, dem Archiv und den Verlängerungsanträgen haben wir hier eine gute Grundlage für mögliche Optionen.

          Solltest du weitere Fragen haben, wende dich gerne an unsere Kolleginnen und Kollegen vom IT-ServiceDesk (servicedesk@itc.rwth-aachen.de).

          Viele Grüße,
          das IT Center Blog Team

  3. Michael Gerhards sagt:

    Zitat „Deswegen erinnert euch der GitLab Project LifeCycle, falls ein Projekt als inaktiv gekennzeichnet wurde.“
    Welche Rechte muss man dann innerhalb des Projektes haben, um erinnert zu werden?

    Zitat von IT Center Help: „Wird ein Projekt 24 Monate lang nicht genutzt, werden alle Projektinhabenden per E-Mail darüber informiert, dass das genannte Projekt durch den Projekt-Lifecycle als inaktiv markiert wurde.“

    Projektinhabenden ist jedoch nicht sauber definiert, insbesondere für Gruppenprojekte. Man kann Owner der Gruppe sein. Man kann auch Maintainer des Projektes sein. Dann kommt noch hinzu, dass Gruppenrechte hierarchisch an Untergruppen vererbt werden. Bis hier hin klappt alles. Problematisch wird es allerdings, wenn man Owner aus einer anderen nicht-hierarchischen Gruppe einer Gruppe hinzufügt. In diesem Fall werden die vererbten Owner NICHT benachrichtigt.

    • Jörres, Linda sagt:

      Hallo Michael,

      vielen Dank für deinen Kommentar. Wir haben zur Beantwortung deiner Fragen unsere Fachabteilung kontaktiert.
      Hier die Antworten:

      1) „Welche Rechte muss man dann innerhalb des Projektes haben, um erinnert zu werden?“
      Antwort: Es werden alle „Owner“ eines Projekts oder bei Gruppenprojekten alle „Owner“ der Gruppe sowie allen übergeordneten Gruppen informiert.
      Dabei wird zum Zeitpunkt der Erinnerung immer vom aktuellen Status ausgegangen, den die Mitglieder innehaben.

      2) „Projektinhabenden ist jedoch nicht sauber definiert, insbesondere für Gruppenprojekte. Man kann Owner der Gruppe sein. Man kann auch Maintainer des Projektes sein.“
      Antwort: Bei Gruppenprojekten haben wir absichtlich die Owner der zugehörigen Gruppe gewählt, da die höchste Berechtigungsstufe von Projekten in einer Gruppe Maintainer ist. Aus unserer Sicht ist es demnach bei Gruppenprojekten am sinnvollsten direkt die Owner zu informieren, wenn ein Projekt schon sehr lange Zeit inaktiv ist, da es in den meisten Fällen keine direkten Mitglieder in Gruppenprojekten gibt und die Berechtigungen aus der zugehörigen Gruppe vererbt werden.

      3) „Dann kommt noch hinzu, dass Gruppenrechte hierarchisch an Untergruppen vererbt werden. Bis hier hin klappt alles. Problematisch wird es allerdings, wenn man Owner aus einer anderen nicht-hierarchischen Gruppe einer Gruppe hinzufügt. In diesem Fall werden die vererbten Owner NICHT benachrichtigt.“
      Für die Beantwortung dieses Punkts benötigt die Fachabteilung ein Beispiel anhand eines konkreten Falls. Hierzu wird dich unser IT-ServiceDesk kontaktieren, damit dir schnellstmöglich weitergeholfen werden kann.

      Viele Grüße,
      das IT Center Blog Team