Git-Bereitstellung in Plesk: Repositorys verwalten, Code bereitstellen

Wer seine Website aus einem Repository ausrollt, sucht in der Verwaltung zuerst nach der passenden Stelle. Es gibt sie. Plesk bringt nämlich eine Anbindung an Git mit, und die kann mehr, als Dateien zu kopieren. Die Git-Bereitstellung in Plesk holt Ihren Code aus einem Repository. Danach legt sie ihn dort ab, wo Ihre Website liegt.

Inhaltsverzeichnis

• Was die Git-Bereitstellung in Plesk leistet
• Ein Git-Repository in Plesk anbinden
• Bereitstellungsmodus und Zielverzeichnis
• Zusätzliche Befehle nach jeder Bereitstellung
• Git oder FTP: was sich für Ihre Website lohnt
• Wenn die Bereitstellung nicht klappt
• Was Git nicht ersetzt

Was die Git-Bereitstellung in Plesk leistet

Git ist eine Versionsverwaltung. Sie hält jede Änderung an Ihrem Code fest. Also kommen Sie jederzeit zu einem früheren Stand zurück. Dazu kennt Git die Verzweigung, also eine parallele Entwicklungslinie, in der Sie etwas ausprobieren, ohne die Hauptlinie anzufassen.

Plesk setzt darauf auf. Statt Dateien von Hand hochzuladen, holt die Verwaltung sie aus einem Repository. Damit kann sie den neuen Stand auf Ihrer Website bereitstellen. Sie können Ihre Repositorys dort verwalten, und auf Wunsch geschieht das Bereitstellen automatisch. So kommen Updates auf die Website, ohne dass Sie ein FTP-Programm öffnen.

Sie finden die Funktion auf dem Dashboard Ihrer Domain in der Gruppe Entwicklertools unter Git. Die Seite dahinter heißt Git-Repositorys in und trägt den Namen Ihrer Domain.

Ein Git-Repository in Plesk anbinden

Beim Anlegen wählen Sie zuerst den Code-Speicherort, also den Ort, an dem Ihr Code liegt. Zwei Betriebsarten stehen zur Wahl, und sie unterscheiden sich in der Richtung, in die die Dateien fließen.

Liegt der Code remote, trägt Plesk die Arbeit. Es liest das Repository aus und holt sich damit den neuen Stand. Das passt, wenn Sie ohnehin mit github.com oder bitbucket.org arbeiten und Ihr Hosting nur das fertige Ergebnis bekommen soll. Die zweite Variante dreht die Richtung um. Dann senden Sie den Stand aus Ihrem lokalen Repository selbst an den Server. Plesk nennt dafür einen guten Grund. Ein Laptop ist von außen meist nicht erreichbar. Also kann der Server ihn gar nicht erst abfragen.

Die Repository-URL ist ein Pflichtfeld. Als Adresse werden sowohl HTTP(S) als auch SSH unterstützt. Dazu vergeben Sie einen Repository-Namen. Mehrere Git-Repositories je Domain sind vorgesehen, deshalb muss der Name innerhalb einer Domain eindeutig sein. Ist Ihr Repository nicht öffentlich, braucht Plesk einen hinterlegten Zugang, sonst kommt es nicht daran.

Bereitstellungsmodus und Zielverzeichnis

Unter dem Speicherort stehen die Deployment-Einstellungen. Der wichtigste Punkt darin ist der Bereitstellungsmodus mit drei Möglichkeiten.

Für den Anfang ist die manuelle Bereitstellung die sichere Wahl. Sie sehen dann erst, was ankommt, und schalten später auf automatisch um. Darunter steht der Serverpfad. Er legt das Zielverzeichnis fest, in das die Dateien gehen, meistens httpdocs. Wer mehrere Domains in einem Paket betreibt, achtet hier vor allem auf das richtige Verzeichnis.

Zusätzliche Befehle nach jeder Bereitstellung

Im selben Fenster gibt es das Kästchen Zusätzliche Bereitstellungsaktionen aktivieren. Plesk erklärt es so: „Geben Sie Shell-Befehle an, die bei jeder Bereitstellung ausgeführt werden sollen.“

Damit lassen sich die üblichen Schritte nach einem Deployment erledigen, etwa Abhängigkeiten nachziehen oder einen Zwischenspeicher leeren.

⚠️ Gehen Sie damit sorgsam um. Was hier steht, läuft bei jeder Bereitstellung. Ein fehlerhafter Befehl wirkt sich sofort auf die laufende Website aus. Das gilt auch dann, wenn Ihr Paket sonst keine Kommandozeile mitbringt. Ob es das tut, klärt übrigens SSH Zugang im Webhosting Paket.

Git oder FTP: was sich für Ihre Website lohnt

Für Websites, die aus Dateien bestehen und die Sie selbst entwickeln, ist die Antwort deutlich. Der Vergleich zeigt, woran das liegt.

Bei einem Content-Management-System fällt die Antwort weniger eindeutig aus. In WordPress liegen die Inhalte in der Datenbank, und das Hochgeladene liegt in wp-content/uploads. Beides steht nicht im Repository, Git ersetzt dort also keine Sicherung.

Pflegen Sie Ihre Seite über eine Oberfläche und programmieren nicht selbst, brauchen Sie Git nicht. Der Dateimanager und ein FTP-Programm reichen dafür völlig. Wie das geht, zeigt schließlich Dateien in Plesk hochladen.

Wenn die Bereitstellung nicht klappt

Vier Ursachen kommen im Alltag am häufigsten vor. Sie erkennen sie daran, an welcher Stelle Plesk aufhört bereitzustellen.

#Das Repository lässt sich nicht verbinden

Prüfen Sie zuerst die Repository-URL Zeichen für Zeichen. Danach klären Sie, ob das Repository von außen erreichbar ist. Ist es privat, braucht Plesk einen hinterlegten Zugang. Ein Tippfehler in der Adresse sieht dabei genauso aus wie eine fehlende Berechtigung.

#Es wird nichts bereitgestellt

Sehen Sie im Bereitstellungsmodus nach. Steht er auf Deaktiviert, passiert nichts. Daher hilft auch ein Push mit neuem Code nicht weiter. Auf Manuell müssen Sie den Vorgang selbst anstoßen.

#Die Dateien landen im falschen Ordner

Daran ist meistens der Serverpfad schuld. Zeigt er nicht auf das Zielverzeichnis Ihrer Domain, liegt der Code zwar auf dem Server. Die Website sieht ihn jedoch nicht.

#Nach der Bereitstellung ist die Seite kaputt

Sind zusätzliche Befehle eingetragen, prüfen Sie diese zuerst. Andernfalls hilft der Blick in die letzte Änderung. In Git ist sie festgehalten. Also kommen Sie zum vorherigen Stand zurück. Wie Sie eine Fassung zum Ausprobieren daneben stellen, zeigt WordPress Testumgebung in Plesk anlegen.

Was Git nicht ersetzt

Nehmen Sie Git nicht für Ihre Sicherung. Es sichert Ihren Code, nicht Ihre Datenbank und nicht die Dateien, die Ihre Besucher hochladen. Der Weg dorthin steht in Backup in Plesk erstellen.

Halten Sie Zugangsdaten aus dem Repository heraus. Konfigurationsdateien mit Datenbankpasswörtern gehören nicht in ein Repository. In ein öffentliches schon gar nicht. Denn wer sie einmal eingecheckt hat, bekommt sie aus der Historie nur mit Mühe wieder heraus.

Und wenn eine Verbindung gar nicht zustande kommt, liegt es manchmal nicht am Repository, sondern am Zugang selbst. Die häufigsten Fälle sammelt FTP-Verbindung klappt nicht.