Ein Monorepository für verteilte Aufträge ändern und mit echten Diensten testen

## Befehle vom Stammverzeichnis aus starten und Prüfungen nach Paketart wählen Führe Arbeitsbereichsbefehle über das festgelegte Hilfsprogramm des Paketmanagers vom Stammverzeichnis des Repositorys aus. Erstelle die erforderlichen Abhängigkeiten, bevor du eine Anwendung oder ein Befehlszeilenwerkzeug startest, und beschränke die Arbeit mit Arbeitsbereichsfiltern auf den betroffenen Paketabhängigkeitsgraphen. Befolge die Richtlinie des Repositorys zur Installation von Abhängigkeiten genau. Wenn sie verlangt, vor der Installation die Paketdeklarationen zu bearbeiten, tue dies, statt einen Hinzufügebefehl aufzurufen, der die überprüfbare Versionsauswahl umgeht. Wähle die Prüfung entsprechend der Rolle des Pakets: - Anwendungen und private Pakete verwenden statische Typprüfung, wenn ihr Erstellungsvorgang die Korrektheit nicht nachweist. - Veröffentlichte Pakete verwenden ihre tatsächliche Paketerstellung, damit Exporte und erzeugte Artefakte geprüft werden. - Größere Änderungen, neue Dateien, Schemaarbeiten und umfangreiche Umstrukturierungen erhalten eine lokale Typ- oder Erstellungsprüfung. - Winzige Bearbeitungen dürfen sich auf gezielte Prüfungen und kontinuierliche Integration stützen, wenn das Projekt dies ausdrücklich erlaubt. Führe keine umfassende Erstellung aus, nur weil sie dir vertraut ist. Verwende die Prüfung, die in der geänderten Schicht tatsächlich fehlschlagen kann. ## Warteschlangen und Datenbanken mit echten Dienstcontainern statt Mocks testen Lege Tests neben dem Quelltext ab und verwende den einzigen vom Repository unterstützten Testausführer. Beginne mit dem betroffenen Paket oder einer einzelnen Testdatei und erstelle dessen Abhängigkeiten nur dann zuerst, wenn der Arbeitsbereich dies verlangt. Ersetze Datenbanken, Warteschlangen oder Zwischenspeicher nicht durch Testdoppel, wenn das Projekt wegwerfbare Dienstcontainer bereitstellt. Verwende isolierte Testhilfen, die echte Verbindungsoptionen und einen bereinigten Zustand bereitstellen, für: - Das Verhalten von Warteschlangen und Zwischenspeichern. - Relationale Transaktionen und Migrationen. - Kombinierte Arbeitsabläufe, die Speichergrenzen überschreiten. Behalte für reine Funktionen eine leichtgewichtige Einheitentestgrenze bei. Bevorzuge für Infrastrukturverhalten einen kontrollierten echten Dienst, damit Serialisierung, Zeitverhalten, Wiederholungsversuche und Transaktionssemantik sichtbar bleiben. Führe Formatierung und automatische Korrekturen der Codeprüfung vor der abschließenden schreibgeschützten Codeprüfung aus. Bevorzuge statische Importe; verwende dynamisches Laden nur bei einem unvermeidbaren Zyklus, einem gemessenen Vorteil durch Codeaufteilung oder einer echten Laufzeitbedingung. ## Änderungen veröffentlichter Pakete erfassen und gemeinsame Abhängigkeiten auf eine Version festlegen Füge immer einen versionierten Änderungseintrag hinzu, wenn sich ein veröffentlichtes Paket oder eine Integration ändert. Verwende für Fehlerbehebungen und kleine kompatible Änderungen standardmäßig eine Patchversion, stimme eine Nebenversion mit den Verantwortlichen ab und wähle niemals ohne ausdrückliche Genehmigung eine Hauptversion. Verwende für reines Serververhalten ohne Änderung an einem veröffentlichten Paket den Mechanismus für Serveränderungsnotizen statt eines Paketversionseintrags. Verfasse Veröffentlichungsbeschreibungen für Benutzer: - Beginne mit dem geänderten Verhalten. - Verwende möglichst einen einzigen verständlichen Satz. - Lasse interne Namen von Werkzeugen, Warteschlangen, Speichern und Bereitstellungen weg. - Beschreibe die Umsetzung nicht als den Nutzen. Halte bewusst gemeinsam genutzte Abhängigkeiten im gesamten Arbeitsbereich auf genau einer identischen Version, wenn die Identität von Laufzeittypen davon abhängt. Suche vor dem Hinzufügen einer solchen Abhängigkeit die vorhandene feste Version und übernimm sie exakt; Versionsbereiche oder parallele Versionen können Schemas aus einem Paket mit Verbrauchern in einem anderen unvereinbar machen. ## Den Weg einer Anfrage verfolgen, bevor Arbeit zwischen Schichten verschoben wird Verstehe vor der Bearbeitung den Anfragepfad: 1. Eine externe Anfrage gelangt in die API und die Dashboardanwendung. 2. Dienste prüfen die Absicht und rufen die Ablaufsteuerung für Ausführungen auf. 3. Die Ablaufsteuerung speichert den Zustand dauerhaft und stellt die Arbeit in eine Warteschlange. 4. Eine Aufsichtskomponente übernimmt die Arbeit und verwaltet die isolierte Ausführung. 5. Ergebnisse kehren über die Ablaufsteuerung zurück. 6. Transaktionszustand und Analyseereignisse fließen in ihre getrennten Speicher. Belasse öffentliche SDKs, Befehlszeilenwerkzeuge, gemeinsam genutzte Typen, Erstellungserweiterungen, Client-Anbindungen, Warteschlangenprozesse, Datenbanken, Analysen, Zeitplanung und Ausführungsmaschinen in den dafür vorgesehenen Paketen. Importiere öffentliche gemeinsame Typen über unterstützte Unterpfade statt über allgemeine Paketstämme, wenn der Exportvertrag dies verlangt. Verschiebe Zuständigkeiten nicht der Bequemlichkeit halber zwischen diesen Schichten. Eine Änderung an Zeitplanung, Warteschlangensteuerung, Ausführung oder dauerhafter Speicherung muss den vollständigen Zustandsübergang und Fehlerpfad berücksichtigen. ## Die stillgelegte Ausführungs-Engine nicht zurückholen und alte Clients sauber mit Fehler abweisen Wenn eine alte Ausführungsmaschine entfernt wurde, belegen historische Verzeichnisnamen oder Kompatibilitätsaufzählungen nicht, dass sie noch läuft. Behandle die aktuelle Architekturdokumentation und den aktiven Paketabhängigkeitsgraphen als maßgeblich. Führe den außer Betrieb genommenen Pfad niemals wieder ein, um einen alten Zweig oder eine alte Anfrage zu erfüllen. Die Kompatibilitätsbehandlung darf eine überholte Version nur erkennen, um sie zurückzuweisen oder geordnet mit einem Clientfehler abzuschließen; sie darf Arbeit weder an nicht vorhandenen Ausführungscode leiten noch eine erwartete Zurückweisung in einen Serverfehler verwandeln. Vor einer Änderung des Kompatibilitätsverhaltens: - Verfolge die Auswahl der aktiven Ausführungsmaschine. - Bestätige, wie überholte Clients erkannt werden. - Bewahre eine eindeutige Fehlersemantik. - Ergänze Tests sowohl für den aktuellen Pfad als auch für die Zurückweisung der außer Betrieb genommenen Version. Behandle versionierte SDK-Anleitungen und erzeugte Agentenregeln jeweils in ihrem eigenen Wartungsdurchgang. Aktualisiere verteilte Anweisungspakete nur, wenn die Aufgabe sie ausdrücklich einschließt. ## Aufgaben mit dem aktuellen öffentlichen SDK schreiben und bei Änderungen die Dokumentation anpassen Definiere dauerhafte Aufgaben über den aktuellen Einstiegspunkt des öffentlichen SDK. Importiere keine Unterpfade veralteter Versionen und belebe keine als veraltet gekennzeichnete API zur Auftragsdefinition wieder. Eine Aufgabendefinition sollte Folgendes enthalten: - Eine stabile Kennung. - Einen typisierten Eingabevertrag. - Eine asynchrone Ausführungsfunktion. - Ausdrückliche Fehler für ungültige Eingaben. - Idempotentes Verhalten oder eine dokumentierte Wiederholungsgrenze für Nebenwirkungen. Behandle Code, der in Ausführungsabbilder für Kunden gebündelt wird, als öffentlichen Laufzeitcode, auch wenn er aus dem Befehlszeilenpaket stammt. Prüfe Paketexporte, gebündelte Abhängigkeiten und Containerverhalten gemeinsam. Aktualisiere öffentliche Dokumentation und Beispiele, wenn sich der SDK-Vertrag ändert. Bewahre die Produktdokumentation auf der dafür vorgesehenen Website auf und befolge deren örtliche Formatierungs- und Navigationsregeln. ## Eine echte Aufgabe mit einem lokalen Build vollständig durchlaufen lassen Verwende ein gepflegtes Referenzprojekt, um SDK- und Plattformänderungen an einer lokalen Erstellung zu testen. Verknüpfe das Referenzprojekt mit den Arbeitsbereichspaketen, statt versehentlich ein veröffentlichtes Paket zu testen. Führe den Ablauf in dieser Reihenfolge aus: 1. Starte die erforderlichen Speicher- und Warteschlangendienste. 2. Wende Datenbankmigrationen an und bestücke die Referenzorganisation und das Referenzprojekt mit Ausgangsdaten. 3. Erstelle das SDK, das Befehlszeilenwerkzeug und die betroffenen Pakete. 4. Starte die API-Anwendung im Hintergrund und prüfe ihren Zustandsendpunkt. 5. Starte den lokalen Aufgabenprozess aus dem verknüpften Referenzprojekt. 6. Warte auf ein ausdrückliches Bereitschaftssignal des Prozesses. 7. Löse über die unterstützte Steuerschnittstelle eine repräsentative Aufgabe aus. 8. Frage Ausführungen regelmäßig ab oder liste sie auf, bis der erwartete Endzustand erscheint. 9. Prüfe das zurückgegebene Ergebnis und den dauerhaft gespeicherten Ausführungszustand. Melde nicht allein aufgrund der Kompilierung einen durchgängigen Erfolg. Bewahre Befehlsausgaben oder Ausführungskennungen als Nachweis auf und beende Hintergrundprozesse nach Abschluss der Prüfung. ## Multiplattform-Container-Images festlegen und Debug-Markierungen vor dem Merge entfernen Fixiere Containerabbilder auf Hashwerte von Mehrplattformindizes, nicht auf architekturspezifische Abbildhashwerte. Wähle den Hashwert auf der plattformneutralen Veröffentlichungsseite des Abbilds, damit Entwicklung und kontinuierliche Integration die richtige Architektur auflösen. Verwende bei der Entwicklung verteilter Abläufe strukturierte Fehlersuchmarken: - Füge Markierungen an Zustandsübergängen, Warteschlangengrenzen und externen Aufrufen hinzu. - Verwende nur registrierte Anwendungsnamensräume; erfinde ohne Genehmigung keinen neuen Namensraum. - Lösche vorhandene Ablaufspuren, bevor du einen Fehler reproduzierst. - Frage mit Begrenzungen und cursorbasierter Seitennavigation ab. - Belasse vorübergehende Markierungen während der laufenden Untersuchung im Entwicklungszweig. - Entferne Markierungen und Importe vor dem Zusammenführen. Prüfende sollten anerkannte vorübergehende Instrumentierung nicht allein deshalb beanstanden, weil sie im Zweig vorhanden ist. Sie sollten prüfen, dass sie die Produktion nicht erreichen kann und dass der Entfernungsschritt Teil des Abschlusses ist. ## Nur die passenden Prüfungen ausführen und berichten, was ausgelassen wurde Prüfe vor der Übergabe den vollständigen Satz geänderter Dateien und führe nur die zutreffenden Prüfschritte aus: - Formatierprogramm, Korrekturen der Codeprüfung und schreibgeschützte Codeprüfung. - Typprüfung für Anwendungen und private Pakete. - Tatsächliche Erstellung veröffentlichter Pakete. - Gezielte Tests mit wegwerfbaren Dienstcontainern. - Einen Paketänderungseintrag oder eine Servernotiz an der richtigen Grenze. - Exakt fixierte Versionen gemeinsam genutzter Abhängigkeiten. - Tests der aktuellen Ausführungsmaschine und der außer Betrieb genommenen Version, wenn sich die Weiterleitung geändert hat. - Einen Hashwert eines Mehrplattformabbilds, wenn sich Abbildverweise geändert haben. - Einen Lauf mit dem verknüpften Referenzprojekt, wenn sich das SDK oder das Ausführungsverhalten geändert hat. - Entfernung vorübergehender Fehlersuchinstrumentierung vor dem Zusammenführen. Berichte, was ausgeführt wurde, was bestanden hat und welcher Prüfschritt aus welchem Grund absichtlich ausgelassen wurde. Behaupte keine Korrektheit von Laufzeit, Paket oder Container aufgrund einer schwächeren Prüfung, die sie nicht beobachten kann.