Cube reduziert Toolchain-Komplexität und beschleunigt Bereitstellung

Vor sechs Jahren kämpfte Cube, ein Software-Entwicklungsunternehmen aus den Niederlanden, mit einer fragmentierten und isolierten Toolchain. Das Unternehmen suchte eine umfassende Lösung, die Entwicklungs-, Sicherheits- und Operations-Teams zusammenführt und eine zentrale Informationsquelle für bessere Zusammenarbeit mit Kund(inn)en schafft. Die Entscheidung fiel auf GitLabs DevSecOps-Plattform.

Operations Manager Mans Booijink und Lead Developer Remi Buijvoets sprachen mit GitLab darüber, wie der Wechsel zu einer All-in-One DevSecOps-Plattform bei Cube – intern und bei Kund(inn)en – einen signifikanten und positiven Unterschied gemacht hat und warum sie mit der Entscheidung zufrieden sind.

Bevor wir in die Migrationsgeschichte eintauchen, hier eine Übersicht der Verbesserungen, die Cube mit GitLab erreicht hat:

• Verbesserte CI/CD-Bereitstellungsgeschwindigkeit
• Verbesserte Service-Level-Agreement (SLA)-Reaktionszeit
• 80% der Cube-Kund(inn)en arbeiten aktiv in GitLab
• Zentrale Informationsquelle für Zusammenarbeit

| Mans Booijink | Remi Buijvoets

Warum ist Cube zu GitLab gewechselt?

Vor dem Wechsel nutzten wir eine Kombination aus Bitbucket, Trello und Jira. Die Kombination führte zu einer fragmentierten, isolierten Toolchain. Es gab viele Möglichkeiten zur Effizienzsteigerung. Wir begannen GitLab zu nutzen, weil wir ein DevOps-System wollten, das Ticket-Management, Sicherheit und Kundenzusammenarbeit umfasst. GitLab arbeitet nicht nur effizient. Die Einführung ist auch schnell und einfach. Tatsächlich haben wir unsere GitLab-Nutzerbasis in den letzten drei Jahren von 20 auf fast 70 verdreifacht. Jetzt nutzt fast die gesamte Cube-Organisation GitLab. Unsere Kund(inn)en und Kolleg(inn)en (Designer(innen), Entwickler(innen) und Projektmanager(innen)) können einfach kommunizieren, indem sie in derselben GitLab-Umgebung arbeiten.

Hat Cube vor GitLab andere Lösungen ausprobiert?

Wir haben andere Tools ausprobiert, bevor wir zu GitLab wechselten. Aber GitLab bot alles, was wir brauchten – Ticket-Management, CI/CD, DevOps, Versionsverwaltung, Dateimanagement und Sicherheit. Es dauerte nicht lange zu erkennen, dass GitLab perfekt war, weil wir ein Tool haben wollten, in dem wir alle gemeinsam mit unseren Kund(inn)en und dem Team arbeiten.

Wie hat sich die Toolchain seit der Nutzung von GitLab verändert?

GitLab hat alles zu einer zentralen Informationsquelle vereinfacht. Wir deployen in eine Private Cloud in den Niederlanden und haben Sentry zur Fehlerüberwachung in GitLab integriert. Ansonsten läuft alles, was wir tun, in GitLab.

Wie hat GitLab CI/CD Cube geholfen?

GitLab CI hilft uns, den Software-Entwicklungsprozess zu automatisieren, indem GitLab-Pipelines und ein Runner zum Deployen unseres Codes verwendet werden. Innerhalb der Pipelines führen wir Linter zur Überprüfung der Code-Qualität aus. Auch Unit- und Funktionstests werden durchgeführt, um die Funktionsfähigkeit der Anwendung sicherzustellen. Wenn ein Fehler auftritt oder ein Test fehlschlägt, schlägt die Pipeline fehl. GitLab CI bringt Mehrwert in unseren Software-Entwicklungslebenszyklus, weil es verhindert, dass Bugs deployed werden, und hilft, Features zu deployen, während andere Features noch in Entwicklung sind. Zusätzlich hilft es uns, die Qualität unserer Projekte zu überwachen, was essentiell ist.

GitLab CI hilft sicherlich bei der Bereitstellungsgeschwindigkeit, aber auch sehr bei der Erleichterung von Rollbacks, wenn ein Release versehentlich einen Fehler enthält. Wir verwenden einen Release-Zeitplan, und GitLab hilft uns, den Großteil der Arbeit zu automatisieren, sodass wir pünktlich liefern können.

GitLab CD verbessert die Geschwindigkeit unserer Code-Deployments. Wenn die Pipelines erfolgreich sind, können Entwickler(innen) sicherstellen, dass alles wie gewünscht funktioniert. Dadurch können sich Entwickler(innen) mehr auf die eigentliche Entwicklung konzentrieren und müssen keine Gedanken an das Deployment verlieren. Wir haben auch eine lokale Maschine eingeführt, die Releases baut. Die Maschine wird vor Ort gehostet und verfügt über viele Ressourcen. Mehrere GitLab Runner nutzen diese Maschine zum Erstellen von Releases. Die Nutzung der GitLab Runner mit einem lokalen Computer war einfach zu konfigurieren.

Wie haben GitLabs Agile-Funktionen dem Unternehmen geholfen, effizienter zu werden?

Vor GitLab nutzten wir verschiedene Kommunikationskanäle mit unseren Kund(inn)en. Jetzt bietet GitLab uns einen zentralen, zugänglichen Ort für alle Kommunikationen. Wir nutzen auch GitLab für Agile-Entwicklung. Wir haben unsere Epics zur Verwaltung größerer Entwicklungsprojekte und nutzen auch Milestones. Wir machen vier bis sechs Releases pro Woche und verwalten sie alle durch Erstellung von Milestones, die jeder sehen kann, einschließlich Kund(inn)en und Entwicklungsteam. Wir versehen alle Tickets mit Anforderungen, geschätzter Zeit, geplanter Veröffentlichung, Testverantwortlichen usw. Wir nutzen GitLab für 90 % unseres Projektmanagements, Agile-Managements und der Arbeitsfunktionalitäten, was sich als sehr effektiv erweist.

Wie misst Cube den Erfolg der GitLab-Migration?

Wir messen die Lead Time der Bereitstellung. Die Ergebnisse jeder einzelnen Phase in der Bereitstellung werden genau protokolliert. So können wir nachweisen, dass wir die mit unseren Kund(inn)en getroffenen Vereinbarungen einhalten. Wir verfolgen auch, wie effizient die verschiedenen Phasen während des Entwicklungsprozesses sind und ob sie sich im Vergleich zur Vergangenheit verbessern.

Da wir GitLab durchgehend im gesamten Prozess nutzen, ist es eine sehr wertvolle und nützliche Informationsquelle.