Deployment Local - Dev - Stage - Live

Die Basics

• Git: 
  Code + Drupal-Konfiguration (config) werden in Git verwaltet und übertragen.
• Composer:
  Composer-Abhängigkeiten werden mit composer install installiert. 
  Immer nötig, wenn Core oder Contrib Updates gemacht wurden, oder neue Module dazu kommen, oder auch nicht mehr gebraucht werden.
• Die Live-Datenbank wird nie ersetzt
• SSH:
  Das Handling auf dem Server läuft via SSH übers Terminal. Je nach Serverkonfiguration müssen dort noch .ssh/config und .bash_profile erstellt und angepasst werden. Z.B. Prompt rot, als optische Hilfe und Aliase z.B. für drush oder rsync oder PHP Umschalter, wenn andere Versionen nötig sind.

LOCAL – Aktueller Stand sauber sichern

• Dev-Module:
  prüfen, ob alle dev-Module in settings.development.php ausgeschlossen sind. So vermeide ich Konflikte von in local aktivierten Modulen die auf stage und live nicht installiert sind. 
  Bsp: $settings['config_exclude_modules'] = ['upgrade_status', 'devel', 'kint'];
  Dadurch werden diese Module nicht mittels drushh cex exportiert und somit Konflikte mit installierten Modulen verhindert, die auf stage und live nicht installiert sind.
• Drupal-Konfiguration exportieren

  •  drushh cex

• Git-Status prüfen

  • git status

• Diff-Check in vs Code (git Bereich)
• Git-Stand comitten und pushen

  • git add -A
    git commit -m "Beschreibung der Änderungen"
    git push
    
    git status

  • Erwartet: nothing to commit, working tree clean
• Datenbank sichern
  Mit gleichem Kommentar versehen wie git commit

DEV, STAGE, LIVE – neues Projekt

• DB-Dump 
  von local auf dev, stage oder live einspielen
• Code kopieren
  Kompletter Code mit rsync auf dev, stage oder live spielen.
  Ausnahme: /tools/ und die lokalen --pernet-Ordner dabei mit --exclude weglassen.
• Vendor Ordner bereinigen (nur stage und live):
  Der kopierte vendor-Ordner enthält die lokalen Entwickler-Pakete (dev). Ein Durchlauf entfernt sie. composer install checkt nur was in composer.json und composer.lock steht und tut genau das. Wenn --no-dev ergänzt ist, entfernt er die Dev-Module (require-dev) und den entsprechenden Code aus dem vendor-Verzeichnis.

  • composer install --no-dev

• Rechte ändern
  von default/settings.php schreibbar machen
• settings.stage.php
  settings.local.php löschen und durch settings.dev.php, settings.stage.php oder settings.live.php ersetzen
• Rechte ändern
  von default/settings.php schützen

• drushh cr

DEV – bestehendes Projekt

• Datenbank von live oder local einspielen
  Bei dev ist es möglich, dass der lokale Stand relevant ist und nicht live.
• default und settings.php beschreibbar machen (siehe stage)
• git pull
• composer install
• drushh updb (vor cim, siehe LIVE)
• drushh cim
• drushh cr
• default und settings.php schützen (siehe stage)

• rsync nicht versionierte Dateien von live oder local holen
  Auch hier ist es möglich, dass local Basis für Dateien sein kann

   

STAGE – bestehendes Projekt

Stage ist die Testumgebung auf dem Liveserver und zur Kontrolle und Freigabe für den Kunden, vor dem Golive. Hier wird nicht mehr entwickelt, nur getestet und eventuelle Bugs gefixt.

• Datenbank von live einspielen. 
• default und settings.php beschreibbar machen

  • chmod 755 web/sites/default 
    chmod 644 web/sites/default/settings.php

• Daten von gitlab holen

  • git status
    git fetch
    git pull

• Composer-Abhängigkeiten auf den Stand von composer.lock bringen

  • composer install --no-dev

• Datenbank-Updates ausführen:

  • drushh updb

• Drupal-Konfiguration importieren:

  • drushh cim
    drushh cr

• default und settings.php schützen

  • chmod 555 web/sites/default
    chmod 444 web/sites/default/settings.php
    chmod 444 web/sites/default/settings.stage.php

• Website und Backend sauber durchtesten.

LIVE – Deployment

Auf Live wird die Datenbank nie überschrieben. Änderungen im Inhalt würden sonst überschrieben. Anpassungen werden mittels Config-Dateien in die Datenbank übernommen (drushh cim). Vor einem Update auf LIVE immer die Datenbank sichern, bei grösseren Updates auch den Code im Webroot unter backups_website/ duplizieren.

• Datenbank sichern:
  • DB-Dump manuell in Backup and Migrate (53_db_dump_live).
• Sicherheitskopie von httpdocs:
  Für den Fall der Fälle den aktuellen Code (kompletter httpdocs Ordner) in backups_website/AKTUELLES DATUM/ kopieren.
• Externe Cronläufe deaktivieren (z.B. in Plesk) 
• Wartungsmodus einschalten

  • drushh maint:set 1				ACHTUNG: MAINT mit T und nicht MAIN
    drushh cr

• default und settings.php beschreibbar machen

  • chmod 755 web/sites/default
    chmod 644 web/sites/default/settings.php

• GitLab-Stand abrufen und Zustand kontrollieren
  git status sollte vor dem pull auf jeden Fall sauber sein, aber zur Sicherheit erst prüfen:

  • git status
    git fetch
    git status

• Bei sauberem Working Tree:

  • git pull

• Composer-Abhängigkeiten installieren/aktualisieren
  WICHTIG: Auf live die --dev Module nicht installieren

  • composer install --no-dev

• default und settings.php schützen

  • chmod 555 web/sites/default
    chmod 444 web/sites/default/settings.php
    chmod 444 web/sites/default/settings.live.php

• Datenbank-Updates ausführen
  WICHTIG: vor Config Import muss immer erst das Datenbank-Update ausgeführt werden.
  Warum: Die Konfiguration in config/sync wurde lokal nach  drush updb exportiert. Sie passt also zu einer Datenbank, die bereits auf dem neuen Stand ist. Auf live muss die Datenbank erst mit drush updb auf denselben Stand gebracht werden, damit die importierte Konfiguration dazu passt. Umgekehrt würde drush cim neue Konfiguration in eine noch alte Struktur schreiben, und das kann Fehler geben.

  • drushh updb
    drushh cr

• Drupal-Konfiguration importieren

  • drushh cim

• Wartungsmodus ausschalten

  • drushh maint:set 0				ACHTUNG: MAINT mit T und nicht MAIN
    drushh cr

• Externe Cronläufe wieder einschalten
• TESTEN!!!!
  Website und Backend kontrollieren.
• git prüfen
  git muss sauber sein

  • git status

• Datenbank Dump vom aktuellen Stand machen.