DevOps im Embedded Development

DevOps ist in der Web-Entwicklung häufig anzutreffen, in der Embedded-Entwicklung jedoch selten. Häufig bestehen bereits bei der Automatisierung in der Softwareentwicklung Defizite. Diese Automatisierung ist jedoch eine Grundvoraussetzung für die erfolgreiche Umsetzung von DevOps. Umgekehrt kann sie als Katalysator für die notwendigen Veränderungen dienen.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Die Umsetzung in der Embedded-Entwicklung stellt bereits auf technischer Ebene besondere Anforderungen. Quality Gates, Testing- und Release- Bedingungen müssen neu gedacht werden, Schnittstellen zu Fertigung und Feld stellen sich völlig anders dar, als bspw. im Web-Kontext. Architektur und Entwicklung müssen Anforderungen des „neuen Stakeholders“ DevOps erfüllen.

Wie kann die Softwareentwicklungszeit, die Time-to-Market für neue und erweiterte Produkte minimiert werden? Agile Entwicklungsmethoden liefern hier eine eindeutige Antwort: Kontinuierliche kleine Schritte und ein iterativer Ansatz. Und wie schon Henry Ford treffend feststellte: „Nothing is particularly hard if you divide it into small jobs.“ Viele dieser Schritte sind so einfach, dass sie automatisiert ablaufen können.

Begriffsdefinition DevOps

DevOps bezeichnet eine Unternehmenskultur, welche die Softwareentwicklung als Kreisprozess sieht und auf dessen Beschleunigung ausgelegt ist. Wichtig in Abgrenzung zu ‚agile‘ ist dabei die Einbeziehung aller an der Software Beteiligten – auch und insbesondere außerhalb der Softwareentwicklung: Tester, Management, Vertriebskanäle, Kunden. Ein möglichst hoher Automatisierungsgrad wird angestrebt.

Begriffsdefinition Quality Gate

Ein Quality Gate ist jede definierte, systematische und nachvollziehbare Überprüfung der Fitness eines Entwicklungsprodukts. Sie umfasst eine Erfolgs- bzw. Freigabevoraussetzung – idealerweise in Form eines Kennzahlwertes.

Schlüsselfaktor für die Umsetzung von DevOps ist – neben dem Willen dazu – ein hoher Grad an Automatisierung. Dabei wird allzu oft nur die Umsetzung eines Arbeitsschrittes automatisiert – nicht jedoch die Bewertung der Ergebnisse und damit verbunden die Frei- und Weitergabe des Outputs an nachgeschaltete Instanzen. Der Erfolg von DevOps wird gemeinhin an der Durchlaufgeschwindigkeit und Wiederholungsfrequenz des oben dargestellten DevOps-Kreislaufs gemessen. Das bedeutet, es geht bei der Automatisierung darum, die Übergaben an die nächsten Instanzen schnell und reibungslos zu vollziehen. Und somit auch und insbesondere, um das Automatisieren von Quality Gates.

Quality Gates und Automatisierung am Beispiel Testen

Tests auf allen Ebenen gehören zu den klassischen Quality Gates. Bei der Automatisierung müssen zum einen die Tests selbst, aber auch ihre Sequentialisierung umgesetzt werden. Typische Automatisierungsserver, wie beispielsweise Jenkins, bieten entsprechende Möglichkeiten. Build- und Testpipelines können mit den entsprechenden Nebenläufigkeiten, Abhängigkeiten und Abbruchbedingungen definiert werden.

Unit- und Komponententests werden ohnehin meist in einen Automatisierungsserver mit eingebunden. Bei Embedded-Software und Cross-Compiling Toolchains muss man klären, ob sie nativ auf dem Entwicklungssystem, auf einer Zielsystem-Simulation und/oder auf dem echten Zielsystem durchgeführt werden können und sollen. Die Umsetzbarkeit ist vom Test-Framework und den Gegebenheiten auf dem Zielsystem abhängig. Integrationstests und Systemtests sind häufig aufwendig zu automatisieren, da hier üblicherweise eine Umweltsimulation und Zusatzhardware notwendig sind.

Bei allen Arten von Tests gilt im Embedded Umfeld: Unter Verwendung von Simulation und Target ist sowohl das Deployment, als auch das Einlesen und Aufbereiten der Testergebnisse mit mehr Aufwand verbunden, als in der Entwicklung von Desktop- oder Web-Software. Die Testergebnisse liegen in Form des Testergebnisses (OK/NOK), sowie Kennzahlen zu Testumfang und -tiefe vor. Auf ihrer Basis erfolgt die Freigabe an die jeweils folgende Ebene nach den festgelegten Vorgaben automatisch.

Strukturvoraussetzungen

Um eine optimale Zusammenarbeit zu ermöglichen, sollte die Software möglichst modular gestaltet sein. Dies gilt zum einen für die Architektur, aber auch für die Gestaltung der Repository-Strukturen. So kann beispielsweise eine Softwarevariante durch den Austausch eines Moduls eleganter gelöst werden, als durch im gesamten Code verteilten kleinen Anpassungen. Ergebnisse aus Quality Gates für den gemeinsamen Code können wiederverwendet werden. Gleiches gilt für SW-Zulieferungen, welche an mehreren Stellen eingesetzt werden, wie z.B. ein Kommunikations-Framework oder eine SW-Plattform. Hier können Quality Gate Ergebnisse implizit oder explizit mitgeliefert und weiterverwendet werden. Umso größer und komplexer die Software wird, umso wichtiger werden diese Punkte, da sich kleine Einzelpakete fast in jedem Fall schneller und effizienter behandeln lassen als das Gesamtsystem. Standardisierte Schnittstellen helfen dabei und unterstützen eine hohe Kompatibilität (vgl. unten).

Nachvollziehbarkeit und Reproduzierbarkeit

Nachvollziehbarkeit und Reproduzierbarkeit von Entwicklungsergebnissen sind Voraussetzung für eine nachhaltige und zuverlässige Entwicklung. Automatische Arbeitsschritte sind im Vergleich zu manuellen Arbeitsschritten inhärent reproduzierbarer und lassen sich leichter messen und mit Kennzahlen belegen. Gleichzeitig sind Arbeitsschritte in der Regel umso einfacher automatisierbar, je langweiliger sie sind und umso schwerer, je mehr Kreativität sie erfordern. Eine erhöhte Mitarbeiterzufriedenheit kann also durchaus als Nebeneffekt einer Automatisierung von Arbeitsschritten auftreten.

Neben der Automatisierung kann die Nachvollziehbarkeit und Reproduzierbarkeit von Entwicklungsergebnissen erhöht werden, indem man alle Eingangsgrößen und deren Änderungen dokumentiert. Sourcecode, Requirements und ähnliche Artefakte werden diesbezüglich oft sehr gut abgedeckt. Gleichzeitig werden die Toolchain selbst, und deren Konfiguration oft vernachlässigt. IoC (Infrastructure as Code) Mechanismen helfen hier weiter: Buildumgebung, VMs, Automatisierungsabläufe und ähnliches werden anhand von textuellen Beschreibungen automatisiert erzeugt. Die Beschreibungsdateien können, gemeinsam mit dem Sourcecode, in einem VCS verwaltet werden. Als konkrete Beispiele seien hier Vagrant-Konfigurationen und Jenkins-Buildfiles genannt.

SW-Update und Versionskompatibilität

Je nach Update-Mechanismus, Field-Deployment-Strategie, Systemaufbau und Datenstrukturen erfordert die Versionskompatibilität besondere Beachtung. Es gilt Software- und Hardwarestände, Systemkomponenten sowie deren Bedatung und Konfiguration in Einklang zu halten. Auch hier zeigt sich eine Besonderheit der Embedded Entwicklung: Der Kunde nutzt eine Kombination aus Hard- und Software. Kompatibilitätsmatrizen können rasant wachsen und nur noch mit leistungsfähigen Servern zu verwalten sein. Der Versuch entsprechende Logik auf den Zielcontrollern unterzubringen, kann schnell deren Kapazitäten überschreiten. Auch hier helfen standardisierte bzw. stabile Schnittstellendefinitionen Aufwände zu minimieren.

Embedded Operations

Mit dem Ausrollen verlässt die Software das angestammte Aufgabengebiet der Entwicklung (Dev) und geht in den Bereich des Betriebs (Ops) über. Hier ist anzumerken, dass neben der reinen Software noch weitere Entwicklungsergebnisse mit ausgerollt werden müssen. Beispielhaft seien hier, Nutzerhandbücher und Backend-Server Features, genannt. Ohne die frühzeitige, fortlaufende und idealerweise automatisierte Koordination der Entwicklung dieser ‚Nebenprodukte‘ mit der ‚Kern-Software‘ sind hier Reibungsverluste und Verzögerungen vorprogrammiert.

Um den Bogen von Operations und Kunde zurück zu den Anforderungen zu schlagen, ist es notwendig ein Feedback System zu etablieren. Dieses muss leicht zu verwenden sein, um angenommen zu werden. Auch sollte es nicht auf Fehlerreporting beschränkt sein –Idealerweise bezieht es den Kunden in die Anforderungserhebung für Erweiterungen und eventuelle Neuentwicklungen ein.

Literatur- und Quellenverzeichnis

Brian Dawson: Missverständnisse rund um DevOps – und wie man es richtig macht. Was ist eigentlich DevOps?

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2018 entnommen.)

Autor

* Hendrik Spies hat Informatik an der TU Kaiserslautern studiert. Neben verschiedenen Stationen als technischer Consultant und Projektleiter für Embedded-Entwicklung in den Bereichen Automotive, Automation und Commercial Vehicle ist er seit sechs Jahren verstärkt mit Projekten im Bereich Embedded SW-Architektur und Konfigurations-Management befasst und betreut dort Kunden bei der Konzeption und Umsetzung von Continuous Integration, Testing- und Deployment-Lösungen.

(ID:45969280)