Verwendung mehrerer Versionen eines Pakets in einem einzigen Projekt: Warum und wie

Moderne Softwareentwicklung erfordert häufig innovative Ansätze zur Verwaltung von Abhängigkeiten, insbesondere in großen JavaScript-Projekten. Ein solcher Ansatz besteht darin, mehrere Versionen desselben Pakets in einem einzigen Projekt zu verwenden. Obwohl diese Methode scheinbar unkonventionell ist, erfüllt sie verschiedene Anforderungen, z. B. die Sicherstellung der Unterstützung älterer Systeme, die Durchführung von Funktionsumschaltungen oder die Erleichterung von A/B-Tests.

In diesem Blogbeitrag befassen wir uns mit den Gründen für die Verwendung mehrerer Versionen eines Pakets, wobei der Schwerpunkt auf Funktionsumschaltung und A/B-Tests liegt, und untersuchen, wie Bit diesen komplexen Prozess vereinfachen kann.

Warum mehrere Versionen desselben Pakets verwenden?

1. Legacy-Code und schrittweise Aktualisierungen

Legacy-Systeme basieren oft auf älteren Versionen von Abhängigkeiten. Die Einführung einer neuen Version kann zu Inkompatibilitäten führen. Durch die Verwendung mehrerer Versionen wird sichergestellt, dass neue Funktionen aktualisierte Bibliotheken nutzen können, während ältere Systeme stabil bleiben.

1. Funktionsumschaltung

Durch das Umschalten von Funktionen können Entwickler die Verfügbarkeit bestimmter Funktionen steuern, ohne die Codebasis zu ändern. Dieser Ansatz ist besonders nützlich, wenn Sie Funktionen inkrementell veröffentlichen oder ihre Auswirkungen testen.

• Release Toggles: Verzögern Sie die öffentliche Veröffentlichung eines Features und stellen Sie gleichzeitig sicher, dass sein Code im Hauptzweig zusammengeführt und getestet wird.

• Experiment-Schalter:(A/B-Tests): Ermöglicht das Testen von Funktionen mit verschiedenen Benutzersegmenten, um die optimale Implementierung zu ermitteln.

• Ops Toggles: Geben Sie Betriebsteams die Möglichkeit, Funktionen zu aktivieren oder zu deaktivieren, ohne neuen Code bereitzustellen.

Das Umschalten von Funktionen erfordert möglicherweise mehrere Versionen eines Pakets oder einer Komponente, wenn das Umschalten erhebliche Änderungen mit sich bringt, wie z. B. das Aktualisieren einer Bibliothek oder das Ändern einer Kernkomponente.

Markieren von Bit-Komponenten mit Vorabversionen

Bit bietet den Bit-Snap-Befehl an, um Ihre Komponente mit einem Hash anstelle einer semantischen Version zu versionieren, um anzuzeigen, dass die Version nicht zur Veröffentlichung bereit ist (der Befehl führt dementsprechend auch eine etwas andere Build-Pipeline aus).

Zum Beispiel:

'bit snap' => package-name@5475049d02fafa0eaf6885a06d36e42e0ffdc4a3
'bit tag' => package-name@1.2.3 

Ein Hash als Version der Komponente gibt jedoch keine Auskunft über ihren Zweck, ihre übergeordnete Release-Version oder ob dieser „Zweig“ des Komponentenverlaufs weitere Iterationen aufweist.

Ein Bit-Snap ist als Bit-Analogie für Git-Commit nützlich, aber nicht für experimentelle Release-Versionen, die in die Produktion integriert werden sollen.

Um weitere Informationen bereitzustellen, wird empfohlen, die Vorabversionsoption zu verwenden. Zum Beispiel:

'bit snap' => package-name@5475049d02fafa0eaf6885a06d36e42e0ffdc4a3
'bit tag' => package-name@1.2.3 

Verwalten mehrerer Versionen eines Pakets

Bei der Verwendung mehrerer Versionen eines Pakets/einer Bit-Komponente ist das Abhängigkeits-Aliasing der Schlüssel. Dieser Ansatz ermöglicht es Teams, mehrere Paketversionen innerhalb desselben Projekts zu verwalten.

bit tag forms/sign-in -m "add SSO option" --increment prerelease --prerelease-id beta

Aliasnamen erleichtern die Unterscheidung zwischen Versionen:

{
 "dependencies": {
  "@my-org/my-scope.forms.sign-in": "0.0.1",
  "@my-org/my-scope.forms.sign-in-sso": "npm:@my-org/my-scope.forms/sign-in@0.0.2-beta.0",
}

Erfahren Sie mehr

• Bit-Dokumentation
• Bit-Plattform

Das obige ist der detaillierte Inhalt vonVerwendung mehrerer Versionen eines Pakets in einem einzigen Projekt: Warum und wie. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!