Die technischen Entscheidungen werden vom Feature-Team getroffen und ** angenommen.
Das Feature-Team muss verantwortungsvoll handeln , um die Auswahlmöglichkeiten zu identifizieren, die sich ausschließlich auf das Feature-Team auswirken, sowie die Auswahlmöglichkeiten, die sich auf das Unternehmen auswirken.
Die Optionen , die den Umfang des Feature-Teams überschreiten (z. B. Lizenz, seltene Programmiersprache), müssen von der Organisation oder durch den Peer-Konvergenzprozess validiert werden .
Das richtige Werkzeug für gute Nutzung ist eine Ersparnisquelle.
Ein schlechtes Werkzeug , das allen auferlegt wird, ist ein Risiko. Der Missbrauch eines guten Tools kann sehr schädliche Folgen haben **. Zum Beispiel sind schlecht verwendete Agile-Methoden gefährlich.
Werkzeuge müssen befragt werden.
Excel ist oft eine vernünftige Wahl , aber es ist nicht ein Werkzeug, um alles zu tun ** (CRM, ERP, Datamart, …)
Privileg Build für das Kerngeschäft.
Betrachten Sie Buy für den Rest, von Fall zu Fall.
Je mehr ein Tool eine Funktion zur Differenzierung für die Organisation aufweist, desto mehr soll es gebaut werden. Das Kerngeschäft muss Spezifität ermöglichen und sich schnell und oft anpassen. Einige Softwarepakete werden manchmal an diesen Bedarf angepasst.
Für den Rest : SaaS, Open Source, Build oder Owner sind von Fall zu Fall zu untersuchen **.
Machen Sie das Beste aus Open Source.
Alternative Auswahlmöglichkeiten müssen unterstützt werden.
Die proprietären Lösungen sind ein Risiko für die Organisation, die in der Lage sein muss, die Wartung bei Bedarf fortzusetzen.
Es gibt wenige proprietäre Tools, die keine Open-Source-Alternativen haben.
Die Organisation profitiert von der Open Source Community und kann ihre Beiträge zurückzahlen.
Develop Stand-alone und schwach gekoppelte Dienste.
schwache Kopplung muss die Norm sein.
Jeder Micro-Service hat eine klar definierte Schnittstelle.
Diese Schnittstelle bestimmt den Link zwischen den Micro-Services.
Domain Driven Design erlaubt, insbesondere mit den Bounded Contexts , dieses Problem vorherzusehen.
Jeder Dienst hat sein eigenes ** Datenspeichersystem.
Ein Data Store soll nur mit einem einzigen Micro-Service ** gekoppelt sein.
Der Zugriff auf Daten von einem Micro-Service zu einem anderen erfolgt ausschließlich über seine Schnittstelle.
Dieses Design bedeutet Konsistenz über die Zeit hinweg auf der gesamten Plattform. Es muss auf allen Ebenen einschließlich UX aufgegriffen werden.
Jeder Micro-Service muss einen angemessenen Funktionsumfang haben, der "in den Kopf passt".
Ein Micro-Service bietet eine angemessene Anzahl von Funktionen.
Zögere nicht, einen Micro-Service zu schneiden, wenn es anfängt zu wachsen.
Ein Dienst von angemessener Größe macht es möglich, das Umschreiben ** gelassen zu betrachten, wenn die Notwendigkeit besteht.
Das Reaktive Manifest öffnet den Weg zur Gestaltung reaktiver Architekturen.
Responsive Programmierung konzentriert sich auf den Datenfluss und die Verbreitung von Änderungen. Es basiert auf dem Muster " Beobachter " im Gegensatz zu dem Ansatz " Iterator ", traditioneller.
Das Reaktive Manifest legt die grundlegenden Achsen fest: Verfügbarkeit und Geschwindigkeit, Ausfallsicherheit für Zusammenbrüche, Flexibilität , Elastizität und Nachrichtenorientierung.
asynchrone Prozesse bevorzugen Entkopplung und Skalierbarkeit zugunsten Leistung.
Der Austausch zwischen Anwendungen muss zuerst ** asynchron sein.
Asynchrone Austausche erlauben **** *-* - - - - und **** - *-* - **** - *-* - - - **** **.
synchrone Kommunikation sollte nur berücksichtigt werden, wenn die Aktion es erfordert.
Das Informationssystem muss Ereignisse orientiert sein.
Die **** ereignisgesteuerten *funktionalen* Prozesse sind natürlich **** asynchron ** implementiert.
Die Event Orientation ermöglicht die Implementierung von Ansätzen wie C ommand Q sehr R Verantwortlichkeit S egregation (CQRS) und Event Sourcing.
Privilegieren Sie einen einfachen, robusten und leistungsfähigen Message-Broker zu einer "Smart Pipe".
ESB zeigte Grenzwerte : Skalierbare Wartung ist kritisch , sowohl von technischer als auch organisatorischer Sichtweise.
**** Broker *-Nachrichten wie* Kafka bieten eine einfache , dauerhafte und belastbare Lösung.
Intelligente Endpunkte und Einfache Pipes ist eine Architektur, die im Maßstab funktioniert: es ist Internet.
Die vollständige Synchronisation des Systems sollte berücksichtigt werden, sobald es entworfen wurde.
Wenn die Synchronisation zwischen zwei Systemen durch einen Ereignisfluss sichergestellt wird, muss die Gesamtsynchronisation dieser Systeme zur Entwurfszeit geplant werden.
Ein automatisches **** *Synchronisations-Audit* (Beispiel: per Stichprobe) erlaubt es, mögliche Synchronisationsfehler zu messen und zu erkennen.
Die Konfiguration der Dienste ist zentralisiert, ihre Entdeckung wird durch ein Verzeichnis gewährleistet.
Die Konfiguration der Micro-Services ist zentralisiert für alle Umgebungen.
Ein zentrales Verzeichnis gewährleistet dynamische Erkennung von Micro-Services.
Die **** globale *Skalierbarkeit* hängt von diesem Verzeichnis ab.
Feature-Teams bieten eine Sandbox-Umgebung.
Feature Teams unterhalten eine Sandbox -Umgebung (aktuelle Version und bevorstehende Version), um anderen Teams das Scale-up zu ermöglichen.
In einigen nicht-nominalen Fällen können Funktionen in der Entwicklungsumgebung **** deaktiviert sein.
Ihr System wird abstürzen!
Entwerfen Sie es so, dass es tolerant ist.
Ihr System wird abstürzen, es ist unvermeidlich. Es muss dafür ausgelegt sein (Design For Failure).
Predict Redundanz auf allen Ebenen: Hardware (Netzwerk, Festplatte, etc.), Anwendungen (mehrere Instanzen von Anwendungen), geographische Zonen, Anbieter (Beispiel: AWS + OVH)
Stellen Sie Toolkits zur Verfügung, stellen Sie keine strengen Frameworks auf.
Achtung auf die technischen Komponenten Häuser und Quer ! Sie sind restriktiv, teuer und schwer zu warten.
Beschleuniger , Toolkits , technische Stacks können zusammengefasst , frei Feature-Teams sein, die einen dogmatischen Ansatz vermeiden.
Öffentlich, privat oder hybrid, die Cloud (IaaS oder PaaS) ist der Standard für die Produktion.
PaaS -Dienste sind bevorzugt, einfach und skalieren schnell.
IaaS -Dienstleistungen ermöglichen es Ihnen, Fälle anzugehen, die eine größere Flexibilität erfordern, aber mehr operative Arbeit erfordern.
Eine Private Cloud ist keine herkömmliche Virtualisierungsumgebung, sie beruht auf Standardhardware.
Feature Teams verwalten die Infrastruktur nicht, sie wird von der Organisation bereitgestellt und verwaltet.
Infrastrukturprobleme gehören nicht zu Feature Teams. Die Infrastruktur muss durch einen funktionsübergreifenden Dienst bereitgestellt und ** gewartet werden.
Container bieten die Flexibilität, die für heterogene Werkzeuge benötigt wird.
Container bieten die Flexibilität , die Feature Teams benötigen, um heterogene Werkzeuge in einem homogenen Kontext zu aktivieren.
Die Verwendung von Containern ermöglicht es, die Probleme der technischen Umgebung zu überwinden.
Die Container (Beispiel: Docker) ermöglichen ** die Befreiung von den Umgebungsdifferenzen.
Der Bereitstellungsprozess muss für die Umgebung agnostisch sein.
Einige Komponenten wie Datenbanken sollten nicht in Containern bereitgestellt werden. Ihr Einsatz ist noch automatisiert.
Maßnahmen müssen zentralisiert und für alle zugänglich sein.
Die Messwerte sind für alle Benutzer mit unterschiedlichem Detaillierungsgrad zugänglich: Detailansicht für das jeweilige Team-Feature, Aggregationen für andere Mitglieder des Unternehmens.
Der Zugriff auf Metrik bedeutet nicht den Zugriff auf die Daten der Einheit , sie muss kontrolliert werden, um die Vertraulichkeit zu wahren.
Alle Umgebungen sind betroffen.
Softwarequalität ist ein Schlüsselfaktor.
Code Reviews sind systematisch. Sie werden von Mitgliedern des Feature Teams oder anderen Mitgliedern der Organisation im Rahmen von Continuous Improvement durchgeführt.
Das ist nicht auditiert, aber dein Code : "Du bist nicht dein Code!".
Die Qualimetrie kann teilweise automatisiert werden, aber nichts schlägt das neue Auge.
automatisiertes Testen ist eine nicht verhandelbare Voraussetzung für die kontinuierliche Bereitstellung.
Automatisierte Tests gewährleisten die Qualität des Produkts im Laufe der Zeit.
Es ist eine Voraussetzung für die kontinuierliche Bereitstellung, es **** Änderungen *und* häufige Bereitstellungen ** ermöglicht.
Der Production Rollout wird zu einem anekdotischen Event!
Tests auf allen Ebenen : Einheit, Integration, Funktionalität, Belastbarkeit, Leistung.
Die Tests Integration und Funktional sind die wichtigsten, sie garantieren den effektiven Betrieb.
Einheit -Tests sind für Entwicklung geeignet.
Leistung Tests messen die Leistung im Zeitverlauf.
Resilience -Tests helfen Fehler vorwegzunehmen.
Cover ist der primäre Zielindikator für die Testqualität.
Die Codeabdeckung der Tests ist eine gute Metrik der Codequalität.
Dies ist eine notwendige Bedingung, aber nicht ausreichend , die Abdeckung einer schlechten Teststrategie kann hoch sein, ohne die gute Qualität des Codes zu garantieren.
Sicherheit ist ein Prozess , sollte nicht als Reaktion auf Probleme behandelt werden.
Sicherheitsexperten können bei Bedarf direkt in Feature-Teams integriert ** werden.
Sicherheitsexperten sind in der Organisation für Audit , Awareness und Forward verfügbar.