Quellcodeverwaltung
Verbinden Sie das GitHub- oder GitLab-Konto, in dem Sie arbeiten, und deployen Sie direkt aus einem Branch: auf Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps oder AWS Amplify — oder auf unser eigenes Managed Hosting, wo das Repository und die Dateien der Website in beiden Richtungen synchron bleiben. Jede Verbindung zeigt die erforderlichen Berechtigungen an, wird vor dem Speichern anhand der API des Anbieters überprüft und in Vault abgelegt. Sie können sich auch mit GitHub oder GitLab anmelden.
Eine Verbindung ist ein Zugangsdaten-Satz, den Sie an eine andere Person übergeben. Unsere Lösung teilt Ihnen vor der Erstellung mit, was sie benötigt, weist vor dem Speichern nach, dass sie funktioniert, und kann von beiden Seiten wieder entzogen werden.
Bevor Sie ein Token erstellen, teilen wir Ihnen mit, was es können muss und warum. Kein pauschaler Geltungsbereich, nur weil es einfacher zu beantragen war, und kein nachträgliches Feststellen, dass wir mehr wollten, als für die Aufgabe erforderlich war.
Wir rufen die eigene API des Anbieters mit Ihrem Token auf, bevor wir ihn speichern. Ein falscher, abgelaufener oder unzureichend berechtigter Token wird direkt im Formular abgelehnt, anstatt akzeptiert, als fehlerfrei angezeigt und erst beim ersten tatsächlichen Deployment fehlschlagen zu werden.
Nicht in unserem Code, nicht in einer Umgebungsdatei, nicht in einem Protokoll und nicht in einer Befehlszeile. Aufgelöst in dem Moment, in dem es verwendet wird, durch die Arbeitslast, die es verwendet.
Verknüpfen Sie ein persönliches Konto mit dem einer Organisation oder zwei Unternehmenskonten miteinander. Jede Website wählt aus, von welchem Konto aus sie bereitgestellt wird, sodass das Repository eines Kunden und Ihr eigenes niemals dieselben Zugangsdaten nutzen.
Acht verwaltete Edge-Hosts und unsere eigene Flotte. Das Ziel ist eine Eigenschaft der Website, nicht der Verbindung, sodass dasselbe Repository einen Branch auf einem Pages-Host veröffentlichen und eine andere Website auf unserer Hardware betrieben werden kann.
Unbegrenzte Bandbreite, kommerzielle Nutzung gestattet und Apex-Domains werden über denselben Anbieter abgewickelt, der üblicherweise Ihre DNS-Zone verwaltet. Aus diesen Gründen ist es die erste Anlaufstelle, auf die wir zurückgreifen.
Cloudflare Pages-Hosting →Veröffentlichen Sie direkt aus dem Repository, in dem sich der Code bereits befindet. In der Footprint-Free-Zeile markiert, da die gemeinsam genutzte github.io-Infrastruktur selbst ein Footprint ist.
GitHub Pages-Hosting →GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps und AWS Amplify sind allesamt Ziele, auf die Sie eine Website mit derselben Verbindung und demselben Bereitstellungsverlauf verweisen können.
Hosting für statische Websites →Eine vollständige Anwendung statt eines erstellten Bundles – WordPress, PHP, Node. Dies ist das Ziel, das eine bidirektionale Synchronisierung erhält, sodass die Dateien auf der Box und im Branch synchron bleiben.
Managed Hosting →Eine Website, die auf einem Host veröffentlicht wird, der nicht uns gehört, verbraucht dennoch ein Kontingent und wird weiterhin in Ihrem Dashboard mit ihren Bereitstellungen, ihrer Betriebszeit und ihren SEO-Daten neben allem anderen angezeigt, was Sie betreiben.
Zulässige externe Websites →Der browserinterne Editor arbeitet mit denselben Dateien, die durch die bidirektionale Synchronisierung zurückgespielt werden, sodass eine schnelle Korrektur über das Dashboard zu einem Commit in Ihrem Branch wird, anstatt zu einer Änderung, die später niemand mehr wiederfinden kann.
Der Web-Editor →Bidirektionale Synchronisierung
Schalten Sie es ein, und die eigenen Dateien der Website werden wieder in Ihren Branch übertragen, während Commits auf diesem Branch wieder auf die Website zurückgeführt werden. Es funktioniert auf jeder von uns gehosteten Website, auf jeder Zeile — die einzige Voraussetzung ist, dass die darunterliegende Maschine Git für ihre Dateien ausführen kann, was vom Server abgefragt und nicht anhand des Tarifs angenommen wird.
Sie wählen aus, welches Verzeichnis synchronisiert wird, da ein WordPress-Kunde möchte, dass sein Theme nachverfolgt wird und nicht vierzigtausend Core-Dateien. Und sie ist deaktiviert, bis Sie sie aktivieren: Das Aktivieren einer Synchronisierung ist eine Entscheidung über das Repository eines anderen, und eine Migration darf Ihnen diese niemals abnehmen.
Zwei Modi, und der Unterschied besteht darin, wo der Build ausgeführt wird. Beide enden an derselben Stelle: einer Ref, die wir abrufen und veröffentlichen, wobei der Commit für das Deployment erfasst wird.
GitHub oder GitLab, unter Verbindungen. Die Berechtigungen werden aufgelistet, bevor Sie das Token erstellen, und es wird vor dem Speichern beim Anbieter überprüft.
Eigentümer, Repository, Branch und ob wir ein Verzeichnis veröffentlichen oder das abrufen, was Ihre CI erstellt hat. Als Teil davon registrieren wir den Push-Webhook.
Ein Push in den angegebenen Branch startet eine Bereitstellung, oder Sie können über den Bereitstellungs-Tab der Website bedarfsgesteuert bereitstellen. Builds werden im Hintergrund ausgeführt.
Der Bereitstellungsverlauf zeigt an, was wann veröffentlicht wurde. Aktivieren Sie die bidirektionale Synchronisierung, und die Änderungen, die Sie hier vornehmen, werden als Commits in Ihrem Branch übernommen.
Wenn etwas nicht stimmt
Eine Repository-Verbindung, die fehlerfrei aussieht und nichts empfängt, ist der klassische stille Fehler — ein Token mit dem falschen Geltungsbereich, eine beim Anbieter blockierte Zustellung, ein manuell entfernter Hook. Auf jedem anderen Bildschirm ist dies unsichtbar, daher zeigt die Repository-Karte es direkt an: wann der Anbieter zuletzt an uns zugestellt hat und was gemeldet wurde.
Zustellungen werden vor der Verarbeitung anhand der Signatur geprüft, und zwar nach dem jeweiligen Schema des Anbieters und nicht nach einem, von dem wir angenommen haben, dass es für alle gilt. Eine Zustellung, die nicht verifiziert werden kann, wird abgelehnt und protokolliert, anstatt stillschweigend ignoriert zu werden.
Identität
Neben einer E-Mail-Adresse und einem Passwort können Sie sich auch mit GitHub, GitLab, Google oder Microsoft bei Ihrem Zinn Digital®-Konto anmelden. Die Identitätsebene führt den Handshake durch; wir sehen Ihr Anbieter-Passwort zu keinem Zeitpunkt, und die Verknüpfung eines Social-Media-Kontos mit einem bestehenden Zinn®-Konto muss weiterhin per E-Mail bestätigt werden.
Die Anmeldung mit GitHub und das Verbinden von GitHub für Bereitstellungen sind separate Entscheidungen und separate Anmeldedaten. Das Ausführen des einen bewirkt nicht das andere, und das Entfernen des einen entfernt nicht das andere.
GitHub und GitLab. Verknüpfen Sie das Konto, in dem Sie bereits arbeiten, und wir können aus dessen Repositories bereitstellen, einen Push-Webhook darauf registrieren und — falls Sie dies wünschen — die Dateien Ihrer Website in die andere Richtung zurücksynchronisieren. Beide laufen über dieselbe Schnittstelle für verknüpfte Konten, sodass alles Folgende für beide gilt.
Ja, und mit Google oder Microsoft. Neben einer E-Mail-Adresse und einem Passwort können Sie sich mit jeder der vier Optionen bei Ihrem Zinn Digital®-Konto anmelden. Die Identitätsebene übernimmt den Handshake und wir sehen Ihr Anbieter-Passwort zu keinem Zeitpunkt. Das Anmelden mit GitHub ist unabhängig vom Verbinden von GitHub für Deployments — Sie können eines von beiden, beides oder keines von beiden tun.
Zu Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps oder AWS Amplify für eine statische oder erstellte Website – oder auf unser eigenes Managed Hosting, bei dem das Repository und die Dateien der Website in beiden Richtungen synchron bleiben. Sie wählen das Ziel für die Website; die Repository-Verbindung ist in beiden Fällen dieselbe.
Beides ist möglich. Im Veröffentlichungsmodus übernehmen wir den Branch so, wie er ist, und veröffentlichen das von Ihnen angegebene Verzeichnis. Im CI-Modus führt die Pipeline Ihres Anbieters Ihren Build-Befehl aus und committet die Ausgabe in einen separaten Veröffentlichungs-Branch, den wir dann wie jede andere Referenz abrufen. Die zweite Option belässt Ihren Build in Ihrer eigenen CI, wo sich Ihre Secrets und Ihr Caching bereits befinden.
Standardmäßig ja — wir registrieren einen Webhook im Repository, und ein Push in den von Ihnen festgelegten Branch startet ein Deployment. Sie können dies deaktivieren und den Webhook beibehalten, was nützlicher ist, als es klingt: Die Übermittlung wird weiterhin protokolliert, sodass Sie das Eintreffen Ihrer Pushes beobachten können, bevor Sie uns darauf reagieren lassen.
Änderungen, die auf unserer Hardware vorgenommen werden, werden zu Commits auf Ihrem Branch, und Commits auf Ihrem Branch gelangen zurück auf die Website. Sie ist ausgeschaltet, bis Sie sie einschalten, denn das Einschalten ist eine Entscheidung über das Repository einer anderen Person, und diese Entscheidung treffen wir nicht für Sie. Sie wählen aus, welches Verzeichnis synchronisiert wird — normalerweise ein Theme oder ein Plugin, nicht vierzigtausend WordPress-Core-Dateien.
Es wird nichts überschrieben und nichts gepusht. Die Synchronisierung stoppt, teilt Ihnen mit, dass der Branch über den Commit hinausgegangen ist, auf dem wir aufgebaut haben, und fragt, welche Seite Sie wünschen — das Repository behalten oder die Website behalten. Eine Website, die noch nie synchronisiert wurde und auf einen Branch verweist, der bereits Commits enthält, ist ebenfalls ein eigener Zustand, und das System fragt nach, anstatt zu raten, was der Wahrheit entspricht.
Wir zeigen Ihnen die Berechtigungen an, die die Verbindung benötigt, bevor Sie diese erstellen, überprüfen das Token bei der Eingabe über die eigene API des Anbieters – so wird ein ungültiges oder falsch dimensioniertes Token gar nicht erst gespeichert – und schreiben es erst dann in Vault. Es berührt zu keinem Zeitpunkt unseren Code, ein Protokoll, eine Umgebungsdatei oder eine Befehlszeile. Sie können es beim Anbieter widerrufen oder die Verbindung hier entfernen, wann immer Sie möchten.
Die Repository-Karte zeigt an, wann der Anbieter zuletzt an uns zugestellt hat und was übermittelt wurde. „Nie zugestellt“ ist die nützlichste Diagnose auf diesem Bildschirm, da „verbunden, aber nie zugestellt“ genau dem Erscheinungsbild eines Tokens mit falschem Geltungsbereich oder einer blockierten Zustellung entspricht – und dies sonst nirgends sichtbar ist. Jede Zustellung wird signaturgeprüft, bevor wir darauf reagieren.
Es wird angeboten und ist gekennzeichnet. GitHub Pages und GitLab Pages teilen sich die Infrastruktur des Anbieters sowie die öffentlichen Hostnamen github.io und gitlab.io, was einen SEO-Footprint darstellt – genau das, was durch diese Linie vermieden werden soll. Für ein Netzwerk ohne Footprint sollten Sie stattdessen auf einem isolierten Hosting bereitstellen. Überall sonst ist Pages erstklassig.
Weil dessen kostenloser Tarif nur für die nicht-kommerzielle Nutzung lizenziert ist. Wir leiten ein Ziel von den Konten ab, die Sie verbunden haben, sofern dies sicher ist, und Vercel ist von dieser Ableitung bewusst ausgeschlossen — das Verbinden eines Kontos darf niemals stillschweigend eine kommerzielle Website an einem Ort platzieren, an dem die Lizenz dies nicht gestattet. Wählen Sie es aus, und es funktioniert genau wie die anderen.
Ja. Bei jedem Deploy werden der veröffentlichte Commit, der Ausführungszeitpunkt und das Ergebnis aufgezeichnet, und der Deploy-Reiter der Website zeigt den Verlauf mit der Live-URL daneben an. Deploys werden im Hintergrund ausgeführt, sodass die Seite aktualisiert wird, sobald der Build abgeschlossen ist, anstatt Sie vor einem Laderädchen warten zu lassen.
Starten Sie eine 14-tägige Testversion ohne Kreditkarte, verbinden Sie GitHub oder GitLab und verweisen Sie eine Website auf einen Branch. Veröffentlichen Sie auf einem Edge-Host oder auf unserem eigenen Hosting mit beidseitiger Dateisynchronisierung.
Kostenlos starten