Workflow für Deployment ohne Composer

Ä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.

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).

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:

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.

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...

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.

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.

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.

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.

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.

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

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-...