Embedded- und IoT-Geräte werden in der heutigen Welt immer beliebter. Diese Geräte werden in verschiedenen Branchen eingesetzt, etwa im Gesundheitswesen, in der Fertigung, bei Konsumgütern und in der Heimautomation. Die Sicherstellung der Qualität dieser Geräte ist entscheidend, um deren Zuverlässigkeit, Sicherheit und Funktionalität zu gewährleisten. Aber wie macht man das?
Nachdem wir die GitLab DevSecOps Serie abgeschlossen haben, hat Patrick den Job gewechselt — und sein neues Team arbeitet mit GitHub. Das Problem ist dasselbe: keine Security-Checks während der Entwicklung. Die Plattform ist eine andere. In Teil 1 unserer GitHub DevSecOps Serie zeigen wir, was GitHub ist, welches CI/CD-Vokabular man teilen muss, bevor irgendein Pipeline-Gespräch funktioniert, und wie die DevSecOps-Pipeline aussieht, die wir in den nächsten Sessions aufbauen werden.
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.
In den letzten Jahren habe ich zu jeder einzelnen Aktivität im SAFe DevOps Health Radar einen Deep-Dive veröffentlicht. Dieser Beitrag ist die Tour rund um den Radar: eine einzige Seite, die Sie durch alle vier Aspekte und alle sechzehn Stages führt, mit dem Originalvideo zu jeder Aktivität und einem Link zum vollständigen Artikel. Nutzen Sie ihn als Karte — um Ihren Einstiegspunkt zu finden, um ihn mit Ihrem Team zu teilen oder um zu bewerten, wo Sie heute stehen und wohin Sie als nächstes wollen.
In diesem Artikel erkläre ich, was Test End to End innerhalb des SAFe® DevOps Health Radars bedeutet und warum es für die Lieferung hochwertiger Software unverzichtbar ist. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.
Build ist der Schritt im SAFe for DevOps Health Radar, in dem committed Code kontinuierlich integriert, getestet und zu einem deploybaren Artefakt mit eingebauter Qualität verarbeitet wird. In diesem Video erkläre ich, was der Build-Schritt umfasst, warum Continuous Integration wichtig ist und wie Techniken wie Gated Commits und statische Sicherheitsanalyse helfen, Qualität bei hoher Geschwindigkeit aufrechtzuerhalten.
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.
Ein Wertstrom ist der Weg, den Wert von der ersten Idee bis in die Produktion zurücklegt. Er ist die Summe aller Schritte, Übergaben und Wartezeiten dazwischen. In diesem Video zeige ich ein einfaches Vorgehen in sieben Schritten: einen Wertstrom identifizieren, ehrlich messen, ein Zielbild entwerfen und dann Schritt für Schritt dorthin arbeiten. Die Zahlen im Beispiel sind bewusst vereinfacht, damit die Methode im Vordergrund steht und nicht ein einzelnes Ergebnis.
