Bevor wir irgendwelche Security-Checks nach links verschieben können, brauchen wir ein Projekt, ein Repository und eine Pipeline, die tatsächlich etwas baut. In Teil 2 unserer GitLab DevSecOps Serie loggen sich Patrick Steger und ich in GitLab ein, legen ein neues .NET-Core-Projekt aus einem Template an und schauen uns die .gitlab-ci.yml an, die GitLab automatisch für uns generiert — inklusive Build- und Test-Job, die das Fundament für alles werden, was wir später ergänzen.
Warum wird Security immer noch am Ende des Entwicklungsprozesses angeflanscht — und wie können wir sie nach vorn verschieben, ohne die Teams auszubremsen? In Teil 1 unserer GitLab DevSecOps Serie legen Patrick Steger und ich die Grundlage: Was GitLab ist, was Shift Left wirklich bedeutet und welche CI/CD-Konzepte man verstanden haben muss, bevor man eine DevSecOps-Pipeline bauen kann, die in der Praxis funktioniert.
Hast du dich jemals gefragt, was “DevOps Engineers” eigentlich tun? Was bedeutet “DevOps” überhaupt? Dieser Blogbeitrag soll das Konzept von DevOps erklären und den Wert aufzeigen, den es einer Organisation bringt.
Feature Toggles sind eines dieser Konzepte, die auf den ersten Blick einfach klingen, aber in der Praxis enormes Potenzial entfalten. In dieser Session des DevOps Meetup Zürich spreche ich gemeinsam mit Ben Rometsch, dem Gründer von Flagsmith, über das Was, Warum und Wie von Feature Toggles. Wir behandeln die grundlegenden CI/CD-Konzepte, die Feature Toggles notwendig machen, den Unterschied zwischen Deployment und Release, und wie moderne Feature-Flagging-Plattformen progressive Rollouts, User-Segmentierung und A/B Testing ermöglichen.
Continuous Deployment ist der finale, aggressivste Schritt in der CI/CD-Progression. CI beweist, dass der Code baut und die Unit Tests grün sind. Continuous Delivery beweist, dass das Artefakt in einer produktionsähnlichen Umgebung funktioniert. Continuous Deployment entfernt den letzten manuellen Checkpoint: Wenn alle Tests auf dem Weg grün sind, geht die Änderung direkt in Produktion. Kein “Deploy”-Button, kein Freitagnachmittag-Release-Fenster, kein Mensch im Loop für den letzten Schritt.
Continuous Integration endet mit einem getesteten Artefakt. Das klingt gut, aber ein grüner Build heisst nicht, dass die Software in einer realistischen Umgebung tatsächlich funktioniert. Unit Tests laufen isoliert. Integrationstests laufen gegen Mocks. Solange man die Software nicht irgendwo hinstellt, das aussieht wie Produktion, und sie unter echten Bedingungen ausführt, hat man eigentlich noch nichts bewiesen. Continuous Delivery ist der Schritt, der diese Lücke schliesst.
In der traditionellen Softwareentwicklung wird Software von allen Entwicklern in einem grossen einzigen Integrationsschritt zusammengeführt und getestet, der in der Regel Wochen oder gar Monate dauert. Da dies nur alle paar Monate passiert, ist dieser Schritt sehr zeitaufwändig.
In der klassischen Softwareentwicklung war Integration ein einziges, schmerzhaftes Ereignis. Jeder Entwickler arbeitete wochen- oder monatelang isoliert, und am Ende wurde alles in einem grossen Big Bang zusammengeführt. Dieser Integrationsschritt dauerte Wochen, manchmal Monate. Konflikte häuften sich an, Bugs versteckten sich in den Nahtstellen zwischen Modulen, und niemand konnte mit Sicherheit sagen, ob das System tatsächlich funktionierte. Continuous Integration wurde erfunden, um genau diesen Schmerz aufzulösen.
