Hier folgt der zweite Teil des DevOps Glossars (der erste Teil findet sich hier). Ein einheitliches Verständnis der Begrifflichkeiten fördert und vereinfacht die tägliche Zusammenarbeit.
Continuous Deployment
Continuous Deployment ist die Automatisierung der Schritte, um Änderungen am Quellcode in definierter und wiederholbarer Art und Weise zu veröffentlichen. Dadurch wird die Vorlaufzeit für neue Features einer Software verkürzt und ermöglicht, vollautomatisiert neue Software-Releases zu veröffentlichen. Es ist kein manueller Verteilungsprozess mehr erforderlich.
Produkte wie Jenkins, Ant und Travis CI unterstützen das Continuous Deployment von Software.
Continuous Integration
Mit einer kontinuerlichen Integration meint man, das täglich mehrfach durchzuführende „Mergen“ von Code-Änderungen in die „Main Version“ des Versionkontrollsystems. Dadurch will man erreichen, dass Integrationsprobleme bereits nach geringen Code-Anpassungen erkannt werden. Im Nachgang ist sichergestellt, dass die Entwickler immer auf der gleichen „Baseline“ des Codes arbeiten. Versionskonflikte werden so verringert oder ganz eliminiert.
Continuous Integration profitiert vom Auftrennen der Funktionalitäten in kleinere Teile oder Aspekte, die vollständig programmiert werden und dann einfacher in die „Main Version“ übernommen werden können.
Continuous Learning
Lernen durch die bei der täglichen Arbeit gemachten Erfahrungen und die Notwendigkeit sich lebenslang weiterzubilden und die eigenen Fähigkeiten zu verbessern, wird unter dem Begriff „ContinuousLearning“ zusammengefasst.
„Continuous Learning“ kann auf drei Ebenen stattfinden:
Auf der individuellen Ebene, wo ein einzelner Mitarbeiter daran arbeitet, seine Fähigkeiten zu erweitern und zu verbessern. Das kann durch einfaches Fragenstellenerfolgen, wenn der Mitarbeiter eine Aufgabe nicht versteht oder wenn er an einer Schulung oder einem Weiterbildungsprogramm teilnimmt.
„Continuous Learning“ bezieht sich jedoch keineswegs nur auf das individuelle Lernen. Mentoring und Lehre kann ebenfalls eine Rolle in der eigenen Weiterentwicklung durch „Continuous Learning“ spielen.
Auf Team-Ebene nutzen und teilen die Team-Mitglieder ihr gemeinsames Wissen und ihre Erfahrungen, um das Team voranzubringen. Dies kann auch bedeuten, „Best Practices“ zu implementieren, die das Lernen und den Wissenstranfer erleichtern. Dazu zählen sog. Retrospektiven oder Team-Fragestunden.
Schließlich gibt es die unternehmensweite Ebene, auf der „Continuous Learning“ die Überprüfung und Erstellung von Policies und Prozessen bedeutet, um die Geschäftsziele zu erreichen. Dazu muss internes und externes Feedback von Mitarbeitern und Kunden gesammelt, zusammengetragen und ausgewertet werden.
Idempotency
Idempotency beschreibt die Möglichkeit im Konfigurationsmanagement, eine Operation oder einen Code mehrfach auszuführen, ohne unbeabsichtigte oder unerwünschte Auswirkungen. Wenn man beispielsweise auf seiner Konfigurationsmanagement-Plattform festgelegt hat, dass die Webserver den Apache installieren, wird der Apache nur genau einmal installiert, unabhängig davon, wie oft der Konfigurationsmanager gegen einen Server in dieser Gruppe ausgeführt wird.
Die meisten Tools für das Konfigurationsmanagement sind idempotent, z.B. Ansible, Chef, Puppet und Salt.
Infrastructure as Code
Hiermit ist die Möglichkeit gemeint, Infrastruktur durch maschinenlesbare Dateien zu beschreiben und damit alle Parameter eines Systems oder einer Serverumgebung eindeutig zu definieren und beliebig oft wiederherstellen zu können.
Bei Chef heißen die Dateien Recipes, bei Puppet Manifeste.
Das Konfigurationsmanagement-Werkzeug ist in der Lage, die Parameter zu ermitteln und neu erzeugte Server mit diesen Parameter zu installieren.
Ansible, Chef, Puppet und Salt implementieren alle das Konzept von „Infrastructure as code“, um Systeme zu konfigurieren, bereitzustellen und zu warten.
Infrastructure as a Service (Iaas)
Bei der Nutzung von IaaS wird kein eigenes Rechenzentrum benötigt, auch ein Housing in einem fremdem Rechenzentrum ist nicht mehr erforderlich. Anbieter von „Infrastructure as a Service“ betreiben Hardware, Server und Speicher, der kundenspezifisch angepasst werden kann. Auf dieser Plattform lassen sich Applikationen, Websites, Datenbanken, Cloudspeicher u.ä. betreiben. Der Aufwand für das Management der Plattform, des Netzwerkes und der Server liegt beim IaaS-Anbieter. Die Anbieter haben meistens nur reine Server-Instanzen mit einer Basisinstallation eines Betriebssystems im Angebot. Darauf müssen Kunden ihre Anwendungen dann selbst installieren, konfigurieren und für eine ausreichende IT-Security sorgen.
Microservices
Unter Microservices versteht man eine Service-orientierte Architektur, die die verschiedenen Komponenten einer Applikation nur lose koppelt. Kleinere Services können vielfältiger genutzt und wiederverwendet werden als komplexe Servicestrukturen. Microservices bilden die Grundlage für das Konzept der „Continous Integration“, da Entwickler kleinere Teile einer Applikation risikoloser und schneller in die Produktion bringen können als komplexe Software-Module.
Mutable/Immutable Infrastructure
Mutable Infrastructure bezeichnet eine Infrastruktur, die aktualisiert, geändert und adaptiert werden kann. Mutable Infrastructure ist langlebig und wird nicht vollständig ausgetauscht im Falle einer Aktualisierung der darauf betriebenen Softwarekomponenten. Im Gegensatz dazu gibt es „Immutable infrastructure“, die nicht geändert wird. Stattdessen wird die Instanz oder der Container neu aufgebaut, wenn Änderungen durchzuführen sind. Die alte Instanz wird dann beendet bzw. gelöscht.
Orchestration
Das automatisierte Management von Serverlandschaften, Software oder IT-Services wird als Orchestration bezeichnet. Dazu werden vorbereitend sog. Policies definiert und später genutzt, um Workflows, Serverinstallationen, Server-Wartungen und -skalierungen, je nach Anforderung, automatisch durchführen zu können.
Bekannte Werkzeuge zur Orchestrierung sind Chef und Puppet, für die Orchestrierung von Containern wird Kubernetes oder Docker genutzt.
Provisioning
Provisioningbezeichnet sämtliche Vorbereitungen und Tätigkeiten, um einen Server bereitzustellen. Dazu gehören die Installation des Betriebssystems und der benötigten Dienste sowie Konfigurationseinstellungen und weitere Aufgaben, bevor ein Server in die Produktionsumgebung integriert wird.
Serverless
Serverlose (serverless) Architekturen erlauben es Entwicklern ihren Code direkt an einen Service abzugeben, der die erforderliche Infrastruktur bereitstellt. Serverless Architekturen nutzen Dienste wie „Backend as a service“ oder „Function as a service“ von Drittanbietern. Damit müssen sich Entwickler nur noch um ihren Code kümmern und nicht mehr um die zugrundeliegende Infrastruktur.
AWS Lambda and Azure Functions von Microsoft sind zwei populäre Serverless-Dienste.
Test-Driven Development
Hierunter versteht man einen Ansatz in der Softwareentwicklung bei dem zuerst ein Test programmiert wird, danach wird die Funktionalität programmiert und gegen den erstellten Testfall geprüft. Wenn der Testfall nicht bestanden wird, wird der Code iterativ verbessert, bis der Testfall erfolgreich durchlaufen wird. Durch dieses Vorgehen werden Entwickler ermutigt, die Anforderungen zunächst zu durchdenken und vollständig zu verstehen, bevor die erste Zeile Code geschrieben wird.