Eine Git-native Plattform für Feature-Flags und A/B-Tests, die Markdown-Dateien und eine CLI nutzt, um Experimente direkt innerhalb der Codebasis zu verwalten.
Funktion und offizielle Positionierung des Produkts
dif.sh ist eine entwicklerorientierte Experimentierplattform, die Feature-Flags, A/B-Tests und Rollouts als Markdown-Dateien im Repository eines Projekts speichert. Dieser Ansatz ermöglicht es Teams, den gesamten Lebenszyklus eines Feature-Flags mit Standard-Versionskontrollwerkzeugen zu verwalten.
Das System lässt sich in bestehende Git-Workflows integrieren, was die Nutzung von Pull-Requests für Experiment-Freigaben ermöglicht und eine permanente, versionierte Historie aller Änderungen beibehält. Es enthält eine CLI, die das Erstellen, Validieren und Abschließen von Tests automatisiert und gleichzeitig einen typisierten Client für den Produktionseinsatz generiert.
Durch die Nutzung eines lokalen Build-Prozesses erkennt das Tool potenzielle Experiment-Kollisionen, bevor sie die Produktion erreichen. Zudem generiert es Kontextdateien, die speziell darauf ausgelegt sind, KI-Codierungsagenten den aktuellen experimentellen Status der Codebasis zu vermitteln.
Durch offizielle Quellen belegte Anwendungsfälle
Teams können Varianten, Hypothesen und Metriken in Markdown-Dateien definieren, um Experimente direkt neben ihrem Code auszuführen und zu verfolgen.
Bereitstellung einer generierten Kontextdatei für Codierungsagenten, damit diese aktive Experimente und frühere Erkenntnisse während der Entwicklung verstehen.
Der dokumentierte Ablauf, sofern verfügbar
Führen Sie den init-Befehl aus, um die lokale Ordnerstruktur einzurichten, einschließlich der Verzeichnisse für Experimente und Oberflächen innerhalb des Repositories.
Nutzen Sie die CLI, um einen neuen Test zu entwerfen, wobei automatisch historischer Kontext aus dem relevanten Oberflächenprotokoll gezogen wird.
Führen Sie Validierungsprüfungen durch, um korrekte Konfigurationen sicherzustellen, und nutzen Sie den QA-Befehl für lokale Vorschauen spezifischer Varianten.
Führen Sie den Build-Befehl aus, um einen typisierten Client zu generieren und Konflikte in Ausschlussgruppen zu lösen, bevor der Code in die Produktion geht.
Beenden Sie einen Test, indem Sie die Datei archivieren, einen Entscheidungsblock entwerfen und das Lernprotokoll der Oberfläche für zukünftige Referenzen aktualisieren.
Die Plattform behandelt Feature-Flags und Experimente als Code-Artefakte und nutzt Markdown-Dateien für die Konfiguration sowie Git für die Versionskontrolle. Dieser Ansatz ist so konzipiert, dass das Audit-Log und der Genehmigungsprozess innerhalb bestehender Entwickler-Workflows wie Pull-Requests verbleiben, wodurch eine separate Datenbank oder ein externes Dashboard für das Konfigurationsmanagement überflüssig wird.
Während des Build-Prozesses löst das Tool den Ausschlussgraphen auf, um sicherzustellen, dass kein Benutzer gleichzeitig in zwei kollidierende Experimente eingeteilt wird. Wenn ein Konflikt erkannt wird, schlägt der Build in der CI-Umgebung fehl, was hilft, Logikkonflikte in der Produktionsanwendung zu vermeiden.
Prüfungen mit eigenen Inhalten und Arbeitsabläufen
Welche Quellen wann geprüft wurden
Antworten auf Basis des quellengeprüften Produkteintrags
Das System verwendet in den Datei-Frontmattern definierte Ausschlussgruppen und prüft während des Build-Schritts auf Kollisionen, wobei der Build abgebrochen wird, falls ein Nutzer in zwei widersprüchliche Tests fallen würde.
Kundendaten werden nicht im Repository gespeichert oder übertragen; stattdessen werden Zielgruppenattribute in der Konfiguration deklariert und Werte zur Laufzeit aus dem Benutzerkontext der Anwendung bereitgestellt.
Oberflächen fungieren als Speicher für das institutionelle Gedächtnis und enthalten Markdown-Dateien, die frühere Erkenntnisse und potenzielle Fallstricke für spezifische Bildschirme oder Funktionen protokollieren.
Jeder Build generiert eine Kontextdatei neu, die aktive Flags und aktuelle Erkenntnisse enthält, welche Codierungsagenten zu Beginn einer Sitzung lesen können, um den aktuellen Status zu verstehen.
Nein, die Kernfunktionalität läuft über die CLI und lokale Dateien, wobei eine optionale Cloud-Ebene für Teams verfügbar ist, die zentralisierte Analysen und Visualisierungen von Konfidenzintervallen wünschen.
