feature/adr-0005
Beschreibung
Beantragung
Marvin hat das GitLab Onlineformular ausgefüllt. Dort wurden einige Fragen bezüglich uns und vor allem unser Lizenz gestellt. Außerdem habe ich geschrieben das wir weg von GitHub wollen und wie wir unser Geld verdienen.
Im Formular habe ich die URL zum GitHub Repository geschickt. Auf die Anfrage einer automatischen E-Mail von GitLab sollte ich ein Screenshot aus dem GitLab Repository Einstellungen schicken. Aus diesem Grund habe ich Cosinnus Core unter anderem in unser GitLab migiert.
Danach konnte ich die Lizenz herunterladen
Die Lizenz
Habe eine 118 User Lizenz bestellt (aktuelle Anzahl der User)
Diskussion
- fast alle Inhalte müssen öffentlich sein
- Vorteile
- Siehe folgende Tabelle
- Fast alle Inhalte sind öffentlich
- Nachteile
- Aufwand bei GitLab Umstellung
- Fast alle Inhalte werden öffentlich
- Ausnahmen können gemacht werden. Wenn dort sensible Daten sind, z.B. Security Team oder Personaldaten vom Personalkreis
- erneute Umstellung, falls wir ein Jahr als OS Projekt akzeptiert werden und im nächsten wieder nicht. ca. 25.000 € im Jahr für premium und Ultimate halte ich bei unserer aktuellen finanziellen Lage deutlich zu viel
- Finanzierung des FOSS Model, nur solange GitLab uns mag
- Was kostet das FOSS Modell, ist das in der Tabelle unten unter "Premium" abgebildet?
- Was bedeutet "solange GitLab uns mag"? Was sind die Kriterien die erfüllt sein müssen?
-
Unsere Produkte sind OSS, aber nicht FOSS.
- FOSS im Sinne von frei verfügbarem und veränderbarem Code, nicht zwingend im Sinne von kostenlos zur Verfügung gestellter Software.
Tabelle - GitLab Varianten
Feature | Free | Premium | Ultimate | Zusatz | Kommentar |
---|---|---|---|---|---|
Lizenz (pro Monat) | 0$ | 2.261$ (116x19$) für jeden Account und Gast | 2.178$ (22x99$) Gastaccount kostenfrei | Aktuell haben wir 116 Acc. und 22 Mitwirkende in der Geno. Anzahl User Steigend z.B. für FOSS Community oder Portalpartner:innen | Warum haben / brauchen wir 116+22 Accounts? Was wären proktikable Minimum-Szenarien (nur für Portal-Teams, nur aktive Mitarbeitende o.ä.)? Antwort: rund 15-20 MA mit Produktbezug, zzgl. Portalkunden (Gastaccount) -> ca. 300 € Premium oder 1.500 € Ultimate |
Accounting: Gast Acc. | - | nicht kostenlos | kostenlos | ||
Code: Merge Request Abhängigkeiten | nein | ja | ja | ||
Code: Mirroring Code (pull und push) | nein | ja | ja | z.B. zu GitHub oder OpenCode | Mirroring zu opencode.de brauchen wir für eine aktuelle Ausschreibung auf jeden Fall - ist in jedem Fall möglich, aber nur mit Premium und Ultimate bidirektional! Mit Free muss manuell auf opencode aktualisiert werden. |
Code: Blockieren des Pushen von Secrets | nein | ja | ja | ||
Sicherheit: Prüfung der Abhängigkeiten nach bekannten Sicherheitslücken | nein | ja | ja | Haben wir even. auch bei GitHub | |
Sicherheit: Suche nach Secrets | nein | nein | ja | ||
CI/CD: Secret nicht allen zeigen | nein | ja | ja | Könnte aus datenschutztechnisch notwendig werden, wenn Kunden, Freelancer oder Freelancer, bei denen die NDA keine Wirkung hat | |
CI/CD: Operations Dashboard | nein | ja | ja | Übersicht über die laufenden Pipelines und ob diese even. fehlgeschlagen sind | |
CI/CD: Rollback in Falle eines Fehler | nein | nein | ja | Ist das wichtig? Ohne Rollback entsteht Risiko Mehraufwand für Fehlerbehebung | |
Dateien: Gruppen/Instanz Datei Templates | nein | ja | ja | Dort können Dateien als Template für die ganze Instanz oder Gruppe verwendet werden, wie z.B. LICENSE oder gitlab-triage
|
Bei Änderungen müssen diese ohne Templates in allen manuell angepasst werden |
PM: Mehrere Assignees | nein | ja | ja | sollten wir eher vermeiden? - ist hilfreich | |
PM: Roadmap | nein | ja | ja | sehr hilfreich | |
PM: Epics | nein | ja | ja | sehr hilfreich | |
PM: Gewichten von Tickets | nein | ja | ja | Sehr wichtig für SCRUM | |
PM: Abhängigkeiten | nein | ja | ja | Wir arbeiten da gerade mit den Titel mit Hängt ab von #TICKETNUMMER
|
effektiver |
PM: Gannt und Ressourcenplanung | nein | ja | ja | ersetzt Googletabelle | Ressourcenplanung ditekt in GitLab als Teil des Scrum Prozesses wünschenswert (Muka) |
PM: Burndown Charts | nein | ja | ja | ||
PM: Mehrere Gruppen Boards | nein | ja | ja | ||
PM: Listenspalten nur mit ausgewählten Assignee | nein | ja | ja | ||
Status Seite | nein | nein | ja | Könnte ein Cachet (Status Page Tool) oder die Portaladmingruppe für Statusmeldungen ersetzen |
nicht so wichtig Tabelle
Feature | Free | Premium | Ultimate | Zusatz | |
---|---|---|---|---|---|
Code: Code Owner | nein | ja | ja | ||
Code: Mehrere Approvers (Merge Request) | nein | ja | ja | könnte relevant sein für unseren Multi-Stakeholder Ansatz? - eher relevant für Code approval, z.B. Fehlervermeidung bei DevOps auf Codebasis | |
Code: Überprüfungsregeln | nein | ja | ja | Im Moment noch zu klein, aber zukünftig werden die Entwickler:innen spezifische Bereiche innerhalb einer Repo haben z.B. Bob macht BBB und Eive macht Etherpad | wird bestimmt relevant (NC, RC, BBB, andere externe Dienste) - für Skalierung des Dev-Teams sehr sinnvoll |
Code: Code Suche | ja, nur im Repo | ja | ja | ||
Sicherheit: Nur verifizierte Commits erlauben | nein | ja | ja | ||
PM: Diskussion beenden | nein | ja | ja | even. Relevant, für die Integration der FOSS Community |
Konsent
- Natalija: 1
- Markus: 0
- Marvin: 0
- Ludwig: 0
Edited by Marvin Wilke