Continuous Integration, Continuous Delivery und Deployment Flashcards
(70 cards)
1
Q
Was sind die Herausforderungen bei CI?
A
- Anfangs oftmals unterschiedliche(s) Sprache, Verständnis, Zielbilder
- Kunden/Anwender wissen nicht, was sie eigentlich wollen
- Anforderungen und Prioritäten können widersprüchlich sein
- Änderungen im zeitlichen Verlauf
- Anforderungen und Erwartungen änder sich
- Rahmenbedingungen ändern sich
- Zusammensetzung der Beteiligten (Stakeholder) änder sich
2
Q
Was ist das Problem, wenn man Anwender fragt, was sie benötigen?
A
Siehe Abbildung.
3
Q
Was ist der Unterschied zwischen Agiler Software Entwicklung und Plan Driven Entwicklung, bezogen auf die Produktsichtbarkeit und die Entwicklungsdauer?
A
- Agile Software Entwicklung
- man sieht recht früh das Produkt
- man kann in regelmäßigen Abständen den Fortschritt erkennen
- man kann, falls notwendig, Änderungen mit einbringen
- Plan Driven Entwicklung
- bei Projektbeginn werden Punkte geklärt und dann versucht alles umzusetzen
- man sieht das Produkt erst am Ende der Entwicklung wieder
- Änderungen dann nur noch schwer durchzuführen
4
Q
Beschreiben Sie ein Inkrementelles Vorgehen bei der Software Entwicklung
A
- beschreibt Vorgehen der kontinuierlichen Verbesserung
- häufig kleine oder kleinse Schritte
- Agile SWE basiert darauf
- Endzustand steht nicht gleich fest
- Projekt wächst organisch
5
Q
Beschreiben Sie ein Iteratives Vorgehen bei Software Entwicklung
A
- Strategie zur Überarbeitungsplanung
- Zeit für laufende Revision und Verbesserung
- Ergebnis der Iteration wird auf notwendige Änderungen untersucht
- Überarbeitung soll System schrittweise entwickeln
- Entwickler sollen Erfahrungen unmittelbar nutzen können
6
Q
Was ist ein MVP
A
- MVP ist Minimum Viable Product
- MVP ist ein das Minimum eines Produktes, welches die Grundvoraussetzung erfüllt und nicht mehr
- Darauf aufbauend kann das nächste Inkrement aufbauen
7
Q
Was bedeutet Minimum vialbe
und welche Stufen gibt es?
A
- Earliest testable/usable/lovable Product
- Earliest Testable Product
- Earliest Usable Product
- Earliest Lovable Product
- Aim for the Clouds, but deliver in Small Steps
8
Q
Welche Countinuous Phasen gibt es?
A
- Continuous Adaption
- Continuous Deployment
- Continuous Delivery
- Continuous Testing
- Continuous Integration
9
Q
Was sind die Treiber für die Continuous Initiativen?
A
- Qualität und Effizienz der Prozesse und Werkzeuge
- (Das beste Software Engineering, die beste Software-Architektur und die beste Code-Qualität nützen am Ende nichts, wenn beim Deployment Artefakte fehlen oder aufgrund inkonsistenter Quellen nicht zusammenpassen und aufgrund dessen das entwickelte System fehlerhaft bis schlimmstenfalls gar nicht lauffähig ist.)
- Frühe und regelmäßige Lieferungen als Erfolgsfaktor
- (Ergänzend zu den eigentlich schon immer bestehenden, klassischen Herausforderungen bei Softwareentwicklungsprojekten ändern sich in der heutigen Zeit immer schneller die Rahmenbedingungen wie Technologie, Märkte und Wettbewerber.)
10
Q
Warum ist Qualität und Effizienz der Prozesse und Werkzeuge so wichtig??
A
- Entwickler melden “done” in ihrer eigenen, isolierten Entwicklungsumgebung
- Release besteht aber aus Änderungen mehrerer Entwickler
- Änderungen vielleicht lokal compilier- oder buildbar
- im Gesamtsystem können Probleme auftreten
11
Q
Welche Probleme können auf dem Weg zum Release auftreten?
A
- die bereitgestellten Änderungen eines Entwicklers führen in einer anderen Umgebung
- zu Compile-/Build-Fehlern
- zu Laufzeitfehlern
z. B., weil neue oder aktualisierte Dateien nicht zur Verfügung gestellt wurden, falsche Versionsstände verwendet wurden, bereits neuere Artefakte bereitgestellt wurden.
- die Summe der Änderungen mehrerer Entwickler führen in einer anderen Umgebung
- zu Compile-/Build-Fehlern
- zu Laufzeitfehlern
weil die Kombination der Änderungen zu einem inkonsistenten Stand führt.
12
Q
Was wird erreicht, wenn Prozessschritte automatisiert werden?
A
- robuste Prozesse mit geringerer Fehleranfälligkeit
- Reduktion von lokalen Wissensinseln/Spezialwissen
- frühes Feedback und schnelle Erkenntnisgewinne.
13
Q
Was bedeutet Lean?
Und wie lauten die Prinzipien von Lean?
A
Lean bedeutet, Kunden den größtmöglichen Wert zu schaffen und dabei Verschwendung zu vermeiden und die Fähigkeiten der Mitarbeiter zu nutzen.
- Definiere Wert aus Kundensicht
- Identifiziere den Wertstrom
- Bringe die Arbeit in Fluss (Flow)
- Erzeuge den Sog der Arbeit (Pull)
- Strebe stets nach Perfektion
14
Q
Was bedeutet Agile?
Und was sind die Prinzipien von Agile?
A
Agilität bietet schnelle Reaktionsfähigkeit in einer komplexen Welt.
- Ermächtigung und Selbstorganisation
- Frühe und regelmäßige Lieferungen
- Überprüfung und Anpassung
- Transparenz
- Nutzung eines Takts
15
Q
Was sind die Gemeinsamkeiten der Ansätze von Lean-Management und der Agilen Bewegung?
A
- Stelle deinen Kunden in den Vordergrund, denn er ist ausschlaggebend für die Definition des Wertes des Produkts.
- Liefere früh und regelmäßig, damit der Kunde stets zeitnah darüber Feedback geben kann,
- ob die Annahmen stimmen,
- ob die Anfoderungen stimmen,
- ob die Prioritäten stimmen,
- ob wirklich mehr Wert entsteht
und damit ein kontinuierlicher Fluss entsteht.
- Lerne und verbessere dich kontinuierlich, denn die Geschwindigkeit (und damit verbunden die Reaktionsfähigkeit) bei hoher Qualität sind ein entscheidender Wettbewerbsfaktor.
16
Q
Welche Werkzeuge und Systeme gibt es bei der Unterstützung von Continuous Integration?
A
- Zentrales Source-Code Repository
- Alle Entwickler bringen ihre Änderungen regelmäßig und zeitnah ein (Check-In, commit)
- Jede Integration wird durch einen automatisierten Build und Test auf unabhängigen Build-/Test-Maschinen verifiziert, um schnelles Feedback zum integrierten Gesamtstand zu ermöglichen
- Nach dem Bereitstellen des Verifizierungsergebnisses wird bei Problemen unmittelbar reagiert und diese durch den Entwickler/das Team behoben
17
Q
Was ist das Resultat von Continuous Integration?
A
- keine Entwicklung über längeren Zeitraum
- sondern alle Änderungen unmittelbar integrieren
- regelmäßig Kontext vom Gesamtsystem und angelaufenen Änderungen überprüfen
18
Q
Welche Fragen können durch das frühe und kontinuierliche Integrieren, das automatisierte Bauen und das automatisierte Testen frühzeitig beantwortet werden?
A
- Ist mein Code, der ggf. mit Weiterentwicklungen von anderen Entwicklern zusammengeführt wurde, in einer „sauberen“ Umgebung überhaupt noch übersetzbar?
- Wie hat sich die Code-Qualität entwickelt und werden die Coding-Standards eingehalten (statische Quellcode-Analyse)?
- Wie hat sich die Testabdeckung durch automatisierte Tests entwickelt?
- Laufen noch alle automatisierten Tests fehlerfrei durch?
- Wirken sich die Änderungen negativ auf das Gesamtsystem aus?
- Werden die nicht-funktionalen Anforderungen noch erfüllt (bspw. Performance)?
19
Q
Continuous Integration.
Je früher das entsprechende Feedback kommt, desto
A
- schneller lässt es sich der eigentlichen Änderung/Ursache zuordnen,
- schneller und aufwandsärmer lässt sich die Ursache beheben und damit das Verdecken weiterer sich einschleichender Probleme vermeiden,
- schneller kann man aus dem Feedback lernen und bei der weiteren Entwicklung berücksichtigen.
20
Q
Welchen typischen Risiken können mit Continuous Integration begegnet werden?
A
- Nicht auslieferungsfähig (bzw. deploybare) Software
- Spätes Auffinden von Problemen und Fehlern
- Geringe Software-Qualität
- Unklarer, intransparenter Projektstatus
21
Q
Was ist der Mehrwert von Continuous Integration?
A
- Senken von Risiken
- Senken von manuellen Aufwänden
- Erhöhen von Software-Qualität
- Jederzeitige Verfügbarkeit von lauffähiger Software
- Jederzeitige Transparenz über Projektstatus
- Höheres Vertrauen im Entwicklungsteam und daraus resultierend:
Mut und höhere Entwicklungsgeschwindigkeit
22
Q
Was sind die Ziele von Konfigurationsmanagement?
A
- Änderungen kontrollieren
- Qualität sicherstellen
- Transparenz verbessern
- Produktivität sicherstellen
23
Q
Was sind die Ziele der Nutzung eines Quellcodeverwaltungssystems?
A
- Jede Version jeder Datei, die hinzugefügt wurde mit historischen Daten abzuspeichern und auch zugänglich zu machen. Pro Änderung wird die Information hinterlegt, welche Dateien durch wen hinzugefügt, geändert oder gelöscht wurden und aus welchem Grund dies erfolgte.
- Solche Systeme erlauben die Zusammenarbeit von mehreren Entwicklern, auch über verteilete Standorte hinweg.
Je nach System werden unterschiedliche Funktionalitäten und Workflows bspw. zum Stempeln von bestimmten Ereignissen, für die Parallelentwicklung via Branches oder Reviews zur Verfügung gestellt.
24
Q
Neben den Quellcodes gibt es noch viele Artefakte, die relevant für die Erstellung und Lauffähigkeit einer Software sind, die oftmals aber nicht mit versioniert werden.
Nennen Sie Beispiele hierfür.
A
- Anforderungen (bspw. Use-Case-Diagramme, Dokumente)
- Architektur- und Designdokumente/-modelle
- Build-, Datenbank-, Deployment-Skripte
- Konfigurationsdateien
- Schnittstellen und Bibliotheken
- Testspezifikationen, Test-Code und Testdaten
- Tools
- Konfigurationen für die Test- und Produktionsumgebung (bspw. DNS, Firewall, …)
25
Welche Vorteile ergeben sich, wenn alle relevanten Artefakte mit in die Versionsverwaltung genommen werden?
* Es besteht jederzeit die Möglichkeit, einen bestimmten Stand Software & Umgebung wiederherzustellen.
* Jeder kann mutig auch mal tiefgreifendere Änderungen vornehmen, wie bspw. das Löschen von nicht mehr benötigten Bereichen. Sollten solche Änderungen rückwirkend ein Fehler gewesen sein, können alle versionierten Dateien wiederhergestellt werden.
26
Explizites Abhängigkeitsmanagement
Ein Entwicklungsprojekt hat meist Abhängigkeiten auf drei Ebenen:
* Team-interne Abhängigkeiten (interne Komponentenbildung/Architektur)
* Team-externe Abhängigkeiten (Nutzung Komponenten anderer Teams)
* Externe Abhängigkeiten zu externen Bibliotheken (Nutzung externer Bibliotheken)
27
Was sind die Grundfunktionen von Versionsverwaltungssystemen?
* Sicherstellen der Nachvollziehbarkeit von Änderungen
* Markieren von bestimmten Ständen
* Wiederherstellbarkeit von Dateiversionen oder expliziten Ständen
* Zugriffslogiken bzw. Workflows für die Entwicklung im Team
* Ermöglichen der Parallelentwicklung mehrerer Versionen
28
Welche Arten der Versionsverwaltungssysteme gibt es?
* lokale
* zentrale
* verteilte
29
Wie funktioniert eine zentrale Versionsverwaltung (prinzipiell)?
* ein zentraler Server
* Admins legen Repository an
* geben Berechtigungen auf Repository
* Entwickler laden lokale Kopie
* Versionshistorie wird vom Server übernommen bei
* hinzufügen
* modifizieren
* löschen von Dateien
30
Wie funktioniert eine verteilte Versionsverwaltung (prinzipiell)?
* Entwickler haben eigenes, lokales Repository (inkl. eigenem Branching)
* Änderungshistorie entsteht lokal bzw. wird beim Holen aus anderen Repositories mitgeholt
* lokale Repository kann mit beliebigen anderen Repositories synchronisiert werden
Vorteil: volle Funktionalität, auch ohne Netzwerkverbindung und performanter als zentrale Versionsverwaltungssysteme.
31
Versionsverwaltungssysteme.
Was ist ein Repository?
Das (lokale/zentrale) Archiv, welches die Historie aus Struktur und Dateien enthält.
32
Versionsverwaltungssysteme.
Was ist ein Branch?
Code-/Entwicklungszweig
33
Versionsverwaltungssysteme.
Was ist ein Tag/Label?
Manuell und automatisiert setzbarer "Stempel", der einen definierten Zustand (Struktur und Dateien) sichert.
34
Versionsverwaltungssysteme.
Was ist ein Get/Pull/Fetch?
Holen der Änderungen vom zentralen bzw. von einem anderen Repository.
35
Versionsverwaltungssysteme.
Was ist ein Merge?
Zusammenführen von Änderungen an der gleichen Code-Basis.
36
Versionsverwaltungssysteme.
Was ist ein Konflikt?
Kann beim Merge auftreten, wenn an der gleichen Stelle (Datei, Struktur) parallel Änderungen vorgenommen wurden.
37
Was ist das Ziel von Continuous Integration?
* möglichst schnelles und frühes Feedback, welche Auswirkungen eine Änderung auf das Gesamtsystem hat
* Je früher der Entwickler die negative Rückmeldung erhält, umso früher können entsprechende Maßnahmen eingeleitet werden
38
Welche Mechanismen für frühes Feedback gibt es **vor** dem Check-In/Commit?
* TDD (Test-Driven Development), ATDD (Acceptance-Test-Driven Development) und BDD (Behavior-Driven Development)
* Pair/Mob Programming
* Code Review
* Holen aller Änderungen aus dem zentralen Repository, lokaler Build mit anschließendem
* Ausführen der automatisierten Tests bzw. Durchführen explorativer Tests
39
Welche Mechanismen für frühes Feedback gibt es **nach** dem Check-In/Commit?
* Frühzeitige Berücksichtigung der Änderungen durch die anderen Team-Mitglieder (während lokaler Entwicklung & Test)
* Build-Automatisierung
* Test-Automatisierung
* Regelmäßige Bereitstellung des Gesamtstandes für Demos, explorative Tests, ...
40
Was ist das Ziel von Build-Automatisierung?
* bei jeder Änderung automatisch einen Build auslösen
* um schnellen Test auszuführen: den Compile Test
* gibt schnelles Feedback von neu eingebrachten Änderungen
41
Warum sind dedizierte Build Maschinen so enorm wichtig?
* Einheitlicher Standard und erstes Quality Gate können etabliert werden, da
* Die Umgebung klar definiert ist
* Die Umgebung sauber ist
* alle benötigten Artefakte sich im Repository befinden müssen
* Build-Maschine wird allgemeingültige Referenz
* "Works on my maschine" ist Vergangenheit
42
Welche Build-Typen gibt es?
* Private Build (manuell durch Entwickler)
* Integration Build (unmittelbar nach Check-In --\> für zeitnahes Feedback)
* Release Build (stellt deploy- und testbare Software bereit)
43
Welche Build Mechanismen gibt es?
* On-Demand (bei Bedarf)
* Poll for changes (Prüfung nach Änderungen im VCS)
* Event-Driven (ähnlich Poll for changes, VCS löst Build bei CI-System aus)
* Scheduled (zeitgesteuerte, definierte Intervalle für Builds)
44
Welche Testarten gibt es bei der Testautomatisierung?
* Manual (Session Based) Testing
* Automated UI Tests
* (Automated API Tests)
* Automated Integration Tests
* (Automated Component Tests)
* Automated Unit Tests
45
Nennen Sie einige Vorraussetzungen und Praktiken für ein erfolgreiches Einführen von Continuous Integration.
* Nur bau- und lauffähigen Code aus dem Repository holen
* Für jede Änderung auch die Testautomatisierung sicherstellen
* Vor dem Einchecken den aktuellsten Stand aus dem Repository holen
* Nur funtioniernden Code einchecken (lokal gebaut und getestet)
* Niemals einchecken, wenn der Build gerade "broken" ist
* Änderungen möglichst regelmäßig einchecken
* Bei umfangreichen oder riskanten Änderungen private Builds zur Absicherung nutzen
* Nach dem Check-In den darauf laufenden Build verfolgen
* Build-Probleme sofort beheben
* Keine auf Fehler laufende Tests auskommentieren
* Alle Tests und Source-Code-Analysen müssen erfolgreich durchlaufen
* Die Builds schnell halten (Build- und Test-Performance)
* Information über den aktuellen Status leicht zugänglich machen
* Ein einfahes Holen und Nutzen der Build-Artefakte ermöglichen
46
Branching und Merging
Was ist ein Branch?
* ist im VCS ein Code- bzw. Entwicklungszweig
* Zweck ist die Isolation von Änderungen zu Risikominimierung
* Code-Basis kann unabhängig weiterentwickelt werden
47
Nennen Sie Gründe für Branches.
* Parallele Entwicklung von künftigen Versionen
* Wartung ausgelieferter Versionen
* Experimentelle Entwicklungen
* Zweige für unterschiedliche Umgebungen, Hardware, Customizing
* ....
48
Was versteht man unter Merging?
* das Zusammenführen von Änderungen eines Quell- und eines Ziel-Branches
* die Branches mergen
* das tatsächliche Zusammenführen von an zwei unterschiedlichen Stellen parallel erfolgten Änderungen
* bspw. auch das Mergen der Änderungen vom zentralen Repository mit den lokal vorgenommenen Änderungen
49
Beim Mergen von Branches wird bezüglich der Richtung differenziert. Welche Richtungen gibt es?
* Beim ersten Mergen erfolgt der Merge vom Parent- zum Child-Branch. Dies bezeichnet man auch als Forward Integration (FI)
* Beim zweiten mergen erfolgt der Merge vom Child- zum Parent-Branch. Dies bezeichnet man auch als Reverse Integration (RI)
50
Branching-Strategien
Was ist *Main Only*?
* Es gibt nur eine Entwicklungslinie
* es gibt keine Branches
* Releases werden durch Labels/Tags markiert
--\> Ideal für Continuous Integration, da es keine isolierten Änderungen gibt.
--\> Jede Änderung löst eine Build-/Testautomatisierung aus, es gibt stets einen integrierten Gesamtstand.
51
Branching Strategien
Was ist *Development Isolation*?
* stabiler Main-Branch im Vordergrund
* Weiterentwicklung in isoliertem Development-Branch
* Erst nach Erreichung eines stabilen Stand wird dieser gemerged
52
Branching Strategien
Was ist *Branch by Release*?
* Entwicklung erfolgt im Main-Branch
* nach Erreichung eines stabilen Stands wird ein Release-Branch erzeugt
* die Entwicklung erfolgt weiterhin im Main-Branch
* im Release-Branch erfolgt noch ggf. Hardening, Bugfixing, Tests, Vorabinstallation
53
Branching Strategien
Was ist *Branch by Feature*?
* Spezialisierung von Development Isolation
* Branch speziell für ein Thema
* Bspw. Experiment, Proof-of-Concept, umzusetzendes Feature, Technologieumstelleung
* Änderungen sollen isoliert abgeschlossen werden
* um bewusst entscheiden zu können, ob via Forward Integration nach Main eingebracht werden soll
54
Branching Strategien
Was ist *Branch by Team*?
* Mehrere Team arbeiten an je einem eigenen Branch
* Codebasis in Main soll stets auslieferungsfähig sein
* Jede Änderung in Main wird zeitnah in alle Branches gemerged (FI)
* Hat ein Team seine Story stabilisiert, so wird nach Main gemerged
55
Branching Strategien
Was ist *Trunk-Based-Development (TBD)*?
* alle Entwickler checken spätestens alle 24h in trunk ein
* Hier laufen auch kontinuierlich die CI-Mechanismen
* Release-Engineer erzeugt Release Branches
* merged bei Bedarf weitere Änderungen aus dem Trunk
56
Welche Probleme können bei parallel betriebenen Branches auftreten?
* Trotz Automatisierung und CI steigen die manuellen Aufwände
* dadurch seltenere Integration
* dadurch mehr Konflikte und höherer Integrationsaufwand
* späteres Feedback
* Aussagen zum Entwicklungsstand über Zeitstrecken kaum möglich
57
Was sind Gefahren bei der Architektur?
* Vorhandensein von God-Classes/Brain-Classes
* Risiko von parallelen Entwicklungen
* und späteres mergen der Änderungen
* Shotgun Surgery
* Änderungen an einer Stelle haben Auswirkungen auf den restlichen Code
58
Was sind die Clean Code SOLID-Prinzipien?
* Single Responsibility Prinzip
* Open Closed Prinzip
* Liskovsches Substitutionsprinzip
* Interface Segregation Prinzip
* Dependency Inversion Prinzip
59
Was sind Feature Toggles?
* Alternative zu Features-Branches
* es sind Schalter, über die definierte Codeteile an- oder ausgeschalten werden können
* Feature kann entwickelt werden ohne sichtbar zu sein
* Aktivierung durch Konfigurationsdatei oder durch Hinterlegung in Datenbank
60
Was ist die Definition von Continuous Delivery?
CD ist die Fähigkeit Änderungen aller Art, wie neue Features, Konfigurationensänderungen, Bug fixes und Experimente, in die Produktivumgebung oder an den Benutzer zu geben, auf eine sichere und schnelle nachhaltige Art.
61
Was sind Eigenschaften von Countinuous Delivery?
* Das erste Prinzip des agilen Manifests
* "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
* Die logische Erweiterung von Continuous Integration. (Von CI bis CD)
* Ein ganzheitlicher Ansatz von Software-Entwicklung
* Jeder Check-In führt im Idealfall zu einem Release-Candidate
* Fertig bedeutet: Released
62
Was ist das Ziel von Continuous Delivery?
* dem Anwender möglichst schnell, aufwandsarm, günstig und stabil Änderungen zu Verfügung zu stellen
* anhand des Feedbacks Erkenntnisse gewinnen
* diese dann in der weiteren Entwicklung berücksichtigen
63
Was versteht man unter einer Deployment-Pipeline?
* standardisierter und automatisierter Prozess von Check-In bis Release
* nach Check-In wandert Changeset durch die Pipeline
* bei Problemen, wird der Fluss abgebrochen
* entsprechendes Feedback wird gegeben
* sind keine Fehler vorhanden --\> manuelle Aktion --\> Freigabe
* es wird in die Produktion deployed
64
Welche Stages gibt es bei der Deployment-Pipeline?
* Commit Stage
* stellt sicher, dass das System auf technischer Ebene funktioniert: Compile- und Unit-Tests sowie Code-Analysen sind erforderlich
* Automated Acceptance Test Stage
* stellt sicher, dass das System auf funktionaler- und nicht funktionaler Ebene funktioniert: die Spezifikationen werden erfüllt und das Verhalten ist erwartungskonform
* Manual Test Stage
* stelle sicher, dass das System bedienbar ist und die Anforderungen erfüllt. Es werden Fehler identifiziert, die nicht über die Testautomatisierung erkannt wurden.
- -\> Diese Stage kann explorative Testumgebungen, Integrationsumgebungen und UAT enthalten
* Release Stage
* liefert das System an die Anwender aus. Entweder als Software-Package, das in die Produktion deployed wird oder sog. Staging Environment.
65
Was sind die Prinzipien von Continuous Delivery?
* Prozess zum Releasen der Software muss wiederholbar und stabil sein
* alle Schritte in diesem Prozess müssen automatisiert werden
* alle Informationen im VCS verwalten
* Wenn etwas Probleme/Schmerzen bereitet, es öfter machen und den Schmerz nach vorne holen
* Die Qualität frühzeitig reinkonstruieren
* jeder ist verantwortlich für den Release-Prozess
* Kontinuierliche Verbesserung
66
Was ist der Gedanke hinter DevOps?
* während der Entwicklung bereits an den operativen Betrieb denken
* nicht entwickeln und im Anschluss "über den Zaun werfen"
* meist weichen Entwicklungs- von Produktionsumgebungen ab
* beide "Seiten" möglichst frühzeitig zusammenbringen
* gemeinsame Rahmenbedingungen, Ziele und Kultur
67
Was ist der Unterschied zwischen Continuous Delivery und Continuous Deployment?
* bei Continuous Delivery sorgt die Deployment Pipeline dafür, dass Software auslieferungsfähig ist
* bei Continuous Deployment wird die Software automatisch in die Produktion deployed
68
Was ist IaaS (Infrastructure as a Service)?
Hier werden die grundlegenden IT-Ressourcen wie bspw. Netzwerktechnik, Storage, Rechenleistung zur Verfügung gestellt. Der Kunde hat die komplette Kontrolle und Verantwortung über alles, was darauf aufsetzt (Betriebssystem, Anwendungen,...). Der Kunde braucht sich nicht im das Aufrüsten der Ressourcen zu kümmern. Er mietet diese lediglich an.
69
Was ist PaaS (Platform as a Service)?
PaaS bietet die gleichen Services wie IaaS, schließt neben den Servern, dem Speicherplatz und der Netzwerktechnik auch die Middleware-Anwendungen wie Betriebssystem, Datenbank, Webserver ein.
Dieses Modell ist äußerst beliebt bei der Entwicklung von Cloud-Anwendungen. Über Selfservice-Portale können einfach und schnell gewünschte Services wie Message Queuing, Load Balancer, Datenbanken konfiguriert und genutzt werden. Ferner ist eine automatisierte Ansteuerung möglich, was im Zusammenhang mit Continuous Delivery/Deployment und der Deployment Pipeline äußerst interessant ist.
Die Umgebung lässt sich je nach Anforderung sehr gut skalieren.
70
Was ist SaaS (Software as a Service)?
Bei SaaS werden dem Kunden komplette Anwendungen zur Verfügung gestellt, ohne dass sich dieser um das Management der zugrundelegenden Infrastruktur oder Middleware-Anwendungen kümmern muss. Der Provider kümmert sich um sämtliche Belange wie das Einspielen von Updates, Sicherung der Daten, Aufrüsten und Austausch von Ressourcen.
