Freigeben über


Lernprogramm: Branch-basierter Entwicklungsarbeitsablauf

Von Bedeutung

Lakebase Autoscaling ist die neueste Version von Lakebase mit automatischer Berechnung, Skalierung bis Null, Verzweigung und sofortiger Wiederherstellung. Unterstützte Regionen finden Sie unter "Verfügbarkeit der Region". Wenn Sie ein Lakebase Provisioned-Benutzer sind, lesen Sie Lakebase Provisioned.

Erfahren Sie, wie Sie Verzweigungen wie Git-Branches verwenden, jedem Entwickler einen isolierten Branch für unabhängige Arbeit geben und zurücksetzen, um synchron zu bleiben.

Voraussetzungen

  • Ein Lakebase-Projekt mit einer production Verzweigung (Standardeinstellung)
  • Ein von development erstellter production Branch für gemeinsame Entwicklungsarbeit
  • Grundlegende Vertrautheit mit SQL und Postgres

Richten Sie Ihr Startschema ein

Bevor Sie Ihren Entwicklerzweig erstellen, richten Sie ein einfaches Schema für den Entwicklungszweig ein. Dies dient als gemeinsamer Ausgangspunkt, von dem alle Entwickler abzweigen. Wenn Sie Ihren persönlichen Branch erstellen, erbt er dieses Schema sofort durch Copy-on-Write.

  1. Navigieren Sie in der Lakebase-Benutzeroberfläche zu Ihrem Entwicklungszweig .
  2. Der SQL-Editor wird geöffnet.
  3. Erstellen einer einfachen Benutzertabelle mit Beispieldaten:
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email TEXT NOT NULL UNIQUE,
    created_at TIMESTAMP DEFAULT NOW()
);

INSERT INTO users (email) VALUES
    ('alice@example.com'),
    ('bob@example.com'),
    ('charlie@example.com');

Erstellen Sie einen Entwicklerzweig

Jeder Entwickler in Ihrem Team kann einen langlebigen Zweig für die laufende Arbeit haben. Setzen Sie es regelmäßig zurück, um mit dem übergeordneten Element synchronisiert zu bleiben.

Wählen Sie in der Verzweigungsliste Ihres Projekts den Entwicklungszweig aus, und klicken Sie dann auf "Untergeordnete Verzweigung erstellen". Geben Sie einen Verzweigungsnamen (erforderlich) ein, z dev/alex . B. (nach dem Muster dev/<your-name>), und klicken Sie auf "Erstellen".

Die Branch wird sofort erstellt und umfasst alle Schemas und Daten aus der Entwicklung durch Copy-on-Write.

Ihre Zweighierarchie:

production (root)
  └── development (has users table + data)
        └── dev/alex (instantly inherits users table + data)

Entwickeln Ihres Features

Zeigen Sie Ihre Anwendung auf Ihren Dev Branch, indem Sie die Verbindungszeichenfolge in Ihrer .env Datei aktualisieren und dann Ihr Feature mithilfe Ihres normalen Workflows entwickeln.

Beispielsweise würde das Hinzufügen der Benutzereinstellungsnachverfolgung zu Ihrer Anwendung das Aktualisieren Ihres Benutzermodells, das Generieren einer Migration mit Ihrem Framework (Prisma, Alembic, Django usw.) und die Ausführung auf Ihrer dev/alex Verzweigung umfassen. Ihre Migrationsdatei kann Folgendes enthalten:

ALTER TABLE users ADD COLUMN preferences JSONB DEFAULT '{}';
CREATE INDEX idx_users_preferences ON users USING GIN (preferences);

Entwickeln Sie nach dem Ausführen der Migration das Einstellungsfeature in Ihrem Anwendungscode, und testen Sie den vollständigen Ablauf lokal. Ihre Zweigstelle ist vollständig isoliert. Änderungen wirken sich nicht auf die Produktion oder andere Entwickler aus.

Änderungen überprüfen

Bevor Sie für andere Umgebungen werben, verwenden Sie schema diff, um genau zu überprüfen, was sich geändert hat. Gehen Sie zu Ihrer dev/alex Branch-Übersicht, klicken Sie auf Schema diff und vergleichen Sie mit development.

Der parallele Vergleich zeigt Ihre neue Spalte und den neuen preferences Index in Grün an:

Schema-Diff zeigt Preferences-Spalte und Index, die zum dev/alex-Branch hinzugefügt wurden

Dieser Überprüfungsschritt hilft, unbeabsichtigte Änderungen abzufangen, bevor sie die Produktion erreichen. Vollständige Dokumentation zu Schema-Diff-Dateien finden Sie unter Compare branch schemas.

Bewerben Ihrer Änderungen

Beförderungen erfolgen nicht automatisch. Führen Sie, um Ihre Änderungen voranzutreiben, dieselbe Migration gegen Ihre development-Verzweigung aus, die Sie bereits auf dev/alex durchgeführt haben. Es gibt keinen Lakebase-spezifischen Schritt. Ihre Migrationsdatei befindet sich bereits in Ihrer Codebasis, sodass dies ihrem normalen Bereitstellungsprozess folgt.

  1. Aktualisieren Sie die Verbindungszeichenfolge so, dass sie auf Ihre development Verzweigung verweist.
  2. Führen Sie Ihre Migration mit development mit demselben Befehl aus, den Sie auch für dev/alex verwendet haben.
  3. Stellen Sie den aktualisierten Anwendungscode bereit.

Da die Migration bereits auf Ihrem persönlichen Branch validiert wurde, sollte sie sauber angewendet werden. Sobald es höhergestuft wurde, sehen andere Entwickler das aktualisierte Schema, wenn sie ihre Branches von development zurücksetzen.

Zurücksetzen und Neu starten

Wenn Sie bereit sind, mit einer neuen Aufgabe zu beginnen, setzen Sie Ihren persönlichen Branch zurück, um development wieder zu synchronisieren, das möglicherweise von anderen Entwicklern geändert wurde. Dadurch erhalten Sie einen neuen Start von der aktuellen freigegebenen Basislinie.

Navigieren Sie zu Ihrem dev/alex Branch und klicken Sie auf Von übergeordnetem zurücksetzen. Das modale Zurücksetzen bestätigt, dass alle Datenbanken und Rollen durch die neuesten Daten ersetzt werden.development Diese Aktion ist nicht umkehrbar. Stellen Sie daher sicher, dass Sie alle Änderungen übernommen haben, die Sie beibehalten möchten, bevor Sie dies bestätigen.

Modales Zurücksetzen der Datenbestätigung

Ihr Branch stimmt jetzt genau mit development überein und ist bereit für Ihre nächste Aufgabe.

Bewährte Methoden

  • Verwenden Sie eine konsistente Benennung: Folgen Sie dem dev/<name> Muster für Entwicklerzweige.
  • Regelmäßig zurücksetzen: Halten Sie Ihren Zweig synchron mit development, um Drift zu vermeiden.
  • Produktion schützen: Verwenden Sie geschützte Verzweigungen, um versehentliche Änderungen zu verhindern.