Startseite
  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche
Startseite › Forum › Drupalcenter.de › Anfängerfragen ›

Workflow für Deployment ohne Composer

Eingetragen von johny (95)
am 29.11.2016 - 18:14 Uhr in
  • Anfängerfragen
  • Drupal 8.x

Kennt jemand vielleicht einen guten Workflow, wenn ich D8 lokal mit Composer update, das auf dem Produktionsserver aber nicht zur Verfügung steht? Ich weiß, es gibt Methoden, das auch auf Shared Hosting Accounts zu installieren, aber vielleicht gibt es auch alternative Deployment-Möglichkeiten? Ich müsste ja irgendwie den Vendor-Ordner auch ins Git-Repository pushen, oder?

‹ Host Europe: Shared Hosting, Managed Webserver oder Virtual Server Probleme mit fehlenden Artikeln/ Inhalten in Drupal ›
  • Anmelden oder Registrieren um Kommentare zu schreiben

Änderungen und Updates führt

Eingetragen von glycid (915)
am 01.12.2016 - 09:50 Uhr

Änderungen und Updates führt man grundsätzlich an der lokalen dev- Version von Drupal durch. Insofern ist es überhaupt nicht nötig, Composer, drush oder auch drupal console auf dem Production Host zu installieren. Ideal ist natürlich git. Aber für kleine Ein- Mann Projekte geht es auch ohne.

Ohne Git: local das Update durchführen, alles noch mal testen, und die Verzeichnisse Core und Vendor gegen die aktualisierten Versionen ersetzen, bzw. überschreiben. Es gibt auch Core- Updates, wo sich files wie index.php, settings.php u.s.w. ändern. Diese müssen dann natürlich auch aktualisiert werden. In den release Infos findest du Informationen dazu. Bei contrib- Modul updates musst du die entsprechenden Verzeichnisse ebenfalls überschreiben.

Mit Git: nach dem Update sagt dir "git status" ja, welche Files geändert wurden. Nach dem commit dann in das Remote bare Repo pushen. Hier musst du wieder drauf achten, dass die settings.php im Falle einer Änderung von Git berücksichtigt wird. Die Standard .gitignore von drupal schließt die settings.php und das sites/default/files- Verzeichnis aus.

Jondos Digital

  • Anmelden oder Registrieren um Kommentare zu schreiben

Na ja, aber in diversen Blogs

Eingetragen von johny (95)
am 01.12.2016 - 14:28 Uhr

Na ja, aber in diversen Blogs wird ja der Vorteil von Composer ja auch damit beworben, dass man nur noch die Composer-Dateien, das Theme und je nach Workflow den Konfigurationsexport von git versionieren lassen muss. Alles andere wird automatisch von Composer installiert (http://www.brightsolutions.de/blog/drupal-8-deployment-der-bright-soluti...). Deshalb habe ich angenommen, dass das inzwischen das Standard-Vorgehen ist.

Und um sich die Datenbank und das files-Verzeichnis vom Production Server zu ziehen, brauche ich ja immer noch Drush (https://www.youtube.com/watch?v=pmfLMAlDG0Y).

  • Anmelden oder Registrieren um Kommentare zu schreiben

Composer ist ein Dependency

Eingetragen von glycid (915)
am 01.12.2016 - 18:36 Uhr

Composer ist ein Dependency Manager für php. Mit dem Deployment Prozess hat dies eigentlich gar nix zu tun. Natürlich kann ich in der composer.json eintragen, welche Module oder welche Core Version beim Aufruf von composer update inklusive Abhängigkeiten updated werden sollen und das dann via Git auf Production pushen und dort die Installation mit einem composer Befehl updaten lassen. Aber das ist nicht Sinn der Sache. Da kann immer was schiefgehen.

Der Workflow, der im BS Blog beschrieben wird, ist der allgemein gängige, nur das BS auch noch Jenkins zur Automatisierung benutzt. Zitat:

Zitat:

Git: für die Verwaltung von Code und YAML-Konfigurationsdateien

Lokal hast du Git, drush, ggf. drupal console und composer. Auf dev, stage und production reicht Git. Deine Production und deine lokale Version sind zu einem bestimmten Zeitpunkt identisch. Jetzt willst du updaten, erweitern, ändern....

Das machst du lokal. Änderungen in der Konfiguration kommen in die .yaml config Files. Via Git versionierst du alle Änderungen des File Systems ( am besten in einem extra Branch) und pusht in dein remote (dev, stage, production) Repo. Hast du auch Änderungen in der Konfiguration vorgenommen, muss dies remote noch in Drupal selbst synchronisiert werden. Fertig ist das Deployment.

Nur um vom Production Server gelegentlich die DB und das File System zu ziehen, brauchst du da ja kein drush. Für DB Dumps gibts zig Möglichkeiten und Tools. Sehr komfortabel ist https://www.drupal.org/project/backup_migrate, geht aber genauso via SSH und SCP, (S)FTP u.s.w.

Jondos Digital

  • Anmelden oder Registrieren um Kommentare zu schreiben

Aber wieso wird dann bei der

Eingetragen von johny (95)
am 01.12.2016 - 19:58 Uhr

Aber wieso wird dann bei der Installation mit Composer eine gitignore-Datei mitgeliefert, die unter anderem diese Verzeichnisse ausschließt?

vendor
web/core
web/modules/contrib
web/themes/contrib
web/profiles/contrib

Auch habe ich bisher in ausnahmslos jedem Artikel über Drupal und git gelesen, dass der File-Ordner nicht versioniert werden soll...

  • Anmelden oder Registrieren um Kommentare zu schreiben

johny schrieb Aber wieso wird

Eingetragen von glycid (915)
am 02.12.2016 - 08:59 Uhr
johny schrieb

Aber wieso wird dann bei der Installation mit Composer eine gitignore-Datei mitgeliefert, die unter anderem diese Verzeichnisse ausschließt?

vendor
web/core
web/modules/contrib
web/themes/contrib
web/profiles/contrib

Tut sie das per default, ja? Bei mir nicht. In meiner example.gitignore sind per default nur diese ausgeschlossen:
# Ignore configuration files that may contain sensitive information.

sites/*/settings*.php
sites/*/services*.yml

# Ignore paths that contain user-generated content.
sites/*/files
sites/*/private

# Ignore SimpleTest multi-site environment.
sites/simpletest

Davon abgesehen gibt es kein "web" Verzeichnis.
Nochmal: Wenn core und vendor ausgeschlossen sind, kannst du Änderungen / Updates nicht via git deployen, sondern musst diese dann via composer auf den einzelnen Instanzen updaten. Auch wenn man das automatisieren kann. Dann kannst du dir das ganze Szenario gleich sparen und an der Online Version arbeiten.

johny schrieb

Auch habe ich bisher in ausnahmslos jedem Artikel über Drupal und git gelesen, dass der File-Ordner nicht versioniert werden soll...

Weil files und ggf. private in der Regel nur User generated Content enthält. Und hast du den lokal? Nein.

Noch eine abschließende Anmerkung: Composer ist eine tolle Sache, hat im Moment aber noch so seine Tücken. Insbesondere bei späteren Modul updates oder deinstallationen. Das kann ziemlich unangenehm und aufwändig werden, weil composer Konflikte produziert, die dann letztlich nur manuell aufgelöst werden können. Ich kann im Nachhinein, d.h. nach zwei Kunden Projekten die komplett mit composer installiert wurden, eigentlich im Moment nur davon abraten. Ich würde nur noch die contrib Module via composer installieren, die dies ausdrücklich verlangen. In einem Jahr wird die ganze Sache weitaus besser funktionieren.

Jondos Digital

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ich glaube ihr sprecht von

Eingetragen von Zman (185)
am 02.12.2016 - 22:26 Uhr

Ich glaube ihr sprecht von zwei verschiedenen Dingen. Einmal das Drupal Composer Projekt und einmal der Core, wie man ihn auf Drupal.org herunterladen kann.

https://github.com/drupal-composer/drupal-project ist schon sehr weit verbreitet, nicht zuletzt weil es von Drupal console beim Erstellen eines neuen Projektes genutzt wird. Ist denn mittlerweile ohne dieses Projekt überhaupt ein sauberer Composer-Workflow möglich; beispielsweise Core-Update?

Das drupal-project ist definitiv good-practice. Ob es das Zeug zur best practice hat weiß ich nicht. Wir nutzen es in unserer Agentur auch für alle D8 Installationen. Befehle wie `composer update` dürfen natürlich im Produktivsystem nicht ausgeführt werden. Maximal `composer install`auf Basis der bereits im Test- und oder Stagingsystem getesteten composer.lock Datei.

Aber zurück zum Thema:
Nichts hindert dich die .gitignore zu verändern, so dass die Contrib-Projekte auch versioniert sind. Würde ich persönlich aber eher von abraten.

Wenn du jedoch das drupal-project als Startpunkt nutzt, dann würde ich es lokal genau mit dieser .gitignore auch nutzen und die Änderungen mit dem Production-Server synchronisieren. Wenn das Shared-Hosting jedoch nicht einmal SFTP oder SSH mit rsync Zugriff anbietet, dann wird das "Deployment" natürlich sehr aufwendig – jedoch nicht unmöglich. Das ist dann eben der Nachteil den das günstige Shared-Hosting mit "nur FTP-Zugriff" hat.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Zman schriebIch glaube ihr

Eingetragen von johny (95)
am 03.12.2016 - 02:18 Uhr
Zman schrieb

Ich glaube ihr sprecht von zwei verschiedenen Dingen. Einmal das Drupal Composer Projekt und einmal der Core, wie man ihn auf Drupal.org herunterladen kann.

Ja, das wollte ich auch schon schreiben, die Ordnerstruktur ist abhängig davon, welches Composer-Template man nutzt (https://www.drupal.org/node/2718229). Ich verwende das empfohlene drupal-composer/drupal-project, darum habe ich auch den web-Ordner und die genannte gitignore.

Zman schrieb

Nichts hindert dich die .gitignore zu verändern, so dass die Contrib-Projekte auch versioniert sind. Würde ich persönlich aber eher von abraten.

Wenn du jedoch das drupal-project als Startpunkt nutzt, dann würde ich es lokal genau mit dieser .gitignore auch nutzen und die Änderungen mit dem Production-Server synchronisieren.

Ok, meinst du jetzt ich soll sie NICHT versionieren? Wie soll ich denn die Änderungen synchronisieren, wenn sie nicht versioniert werden?

Zman schrieb

Wenn das Shared-Hosting jedoch nicht einmal SFTP oder SSH mit rsync Zugriff anbietet, dann wird das "Deployment" natürlich sehr aufwendig – jedoch nicht unmöglich. Das ist dann eben der Nachteil den das günstige Shared-Hosting mit "nur FTP-Zugriff" hat.

Ich habe inzwischen mehrere Hoster angeschrieben und es ist überall kein Problem. SSH, Drush, git, rsync, mysqldump ;).

Dann habe ich noch einen Artikel gefunden, wo auch davon abgeraten wird Composer auf Production zu verwenden und statt dessen Continuous Integration anzuwenden. Ich hab leider nicht wirklich verstanden, wie da der genaue Ablauf ist.
http://nuvole.org/blog/2016/aug/19/optimal-deployment-workflow-composer-...

  • Anmelden oder Registrieren um Kommentare zu schreiben

Benutzeranmeldung

  • Registrieren
  • Neues Passwort anfordern

Aktive Forenthemen

  • benutzerdefinierte Felder vom Userprofil tauchen ungewollt oberhalb des Bodys jedes Forumtopics auf...
  • [gelöst] Mass contact Empfängerliste nach Taxonomy Term statt Rolle
  • Update V. 9.3.12 auf V. 9.4 mit Fehler: Modul mySQL fehlt. Bitte Hilfe.
  • Sprachpfad, in Drupal Korrekt einstellen, auch bei den Meta-Tags
  • Update von Drupal 9.3 auf 9.4 oder bei 9.3 bleiben
  • Terminverwaltung
  • Views in Seite einbetten
  • Hilfe! Nach Update auf 7.90 zeigt User reference (Kontrollkästchen/Auswahlknöpfe) nicht mehr vollständig an
  • ("Gelöst,...") Das Deinstallieren eines Content typen, der keinen Content hat, ist nicht möglich.
  • Drupal Website gestalten
  • DrupalCamping 2022 in Wolfsburg, 25. - 28. August
  • Entity Reference - Title Felder werden als Link angezeigt
Weiter

Neue Kommentare

  • Nein, das war es nicht. S. o.
    vor 1 Tag 23 Stunden
  • Eventuell hier ein Hinweis?
    vor 2 Tagen 22 Minuten
  • Lösung gefunden
    vor 10 Stunden 47 Minuten
  • Kalender und webform
    vor 4 Tagen 5 Stunden
  • Alle Funktionen sind in views schon enthalten
    vor 4 Tagen 5 Stunden
  • Danke, Werner. Composer läuft
    vor 5 Tagen 15 Stunden
  • Wenn eine neue Drupal
    vor 5 Tagen 15 Stunden
  • Nein. Mittlerweile denke ich,
    vor 5 Tagen 16 Stunden
  • Wurde der Update mit composer
    vor 5 Tagen 17 Stunden
  • Maik Petran schrieb und zwar
    vor 1 Woche 1 Tag

Statistik

Beiträge im Forum: 247845
Registrierte User: 19585

Neue User:

  • Tkakah
  • JeraldFub
  • andycrestodina

» Alle User anzeigen

User nach Punkten sortiert:
wla9212
stBorchert6003
quiptime4972
Tobias Bähr4019
bv3924
ronald3845
md3717
Thoor3678
Alexander Langer3416
Exterior2903
» User nach Punkten
Zur Zeit sind 0 User und 6 Gäste online.

Hauptmenü

  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche

Quicklinks I

  • Infos
  • Drupal Showcase
  • Installation
  • Update
  • Forum
  • Team
  • Verhaltensregeln

Quicklinks II

  • Drupal Jobs
  • FAQ
  • Drupal-Kochbuch
  • Best Practice - Drupal Sites - Guidelines
  • Drupal How To's

Quicklinks III

  • Tipps & Tricks
  • Drupal Theme System
  • Theme Handbuch
  • Leitfaden zur Entwicklung von Modulen

RSS & Twitter

  • Drupal Planet deutsch
  • RSS Feed News
  • RSS Feed Planet
  • Twitter Drupalcenter
Drupalcenter Team | Impressum & Datenschutz | Kontakt
Angetrieben von Drupal | Drupal is a registered trademark of Dries Buytaert.
Drupal Initiative - Drupal Association