Lernprogramm: Branch-basierter Entwicklungsarbeitsablauf

Von Bedeutung

Lakebase Autoscaling ist in Beta in den folgenden Regionen: eastus2, westeurope, westus.

Lakebase Autoscaling ist die neueste Version von Lakebase mit automatischer Berechnung, Skalierung bis Null, Verzweigung und sofortiger Wiederherstellung. Einen Featurevergleich mit Lakebase Provisioned finden Sie unter Auswahl zwischen Versionen.

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 production erstellter development 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 Verzweigung 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:

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

Wenn Sie sich Ihrer Änderungen sicher sind, fördern Sie sie in die Upstream-Branchs. Wenden Sie dieselben validierten Schemaänderungen, die Sie auf dev/alex überprüft haben, auf Ihre development-Branch an und stellen Sie anschließend den Anwendungscode bereit. Dieser Workflow stellt sicher, dass Ihre Schemaänderungen isoliert getestet werden, bevor sie freigegebene Umgebungen erreichen.

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.

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.