Upsun est-il adapté au développement moderne de Drupal ?

Vous avez un site web Drupal et vous vous demandez si Upsun peut vous convenir. La réponse courte est : oui, bien sûr ! Mais creusons un peu plus et faisons connaissance avec la manière d'obtenir l'expérience la plus fluide possible en hébergeant vos applications Drupal chez nous.

Je ne vais pas détailler dans ce billet comment modifier votre application pour qu'elle fonctionne sur Upsun (ce que nous appelons "upsunifier" vos applications), mais seulement mettre en avant certaines fonctionnalités qui me semblent particulièrement importantes lorsqu'il s'agit de Drupal. Mais nous avons un guide de démarragetrès pratique et un guide d'intégration d'Upsunify que vous pouvez explorer - et vous pouvez toujours profiter de notre essai gratuit pour expérimenter.

Un flux de travail simple, basé sur Git

La première chose à comprendre est qu'Upsun s'appuie à la fois sur Infrastructure-as-Code (IaC) et GitOps pour gérer et déployer des applications. Plus précisément, nous utilisons des fichiers YAML pour définir les besoins en infrastructure de votre application : version d'exécution, besoins en mémoire et en stockage, et services supplémentaires tels que les bases de données.

Avec Git comme source unique de vérité, toute modification de l'application et de l'infrastructure est à portée de main, et le déploiement devient une simple question de fusion avec la branche principale. Ce flux de travail est idéal pour suivre les modifications, faciliter les tests mais aussi revenir en arrière si nécessaire - après tout, il suffit d'un simple git revert.

Vous vous dites peut-être : "Oh oh, est-ce qu'ils sont en train de dire que je dois tout valider, même mes fournisseurs ?" Laissez-moi vous rassurer tout de suite : non, nous ne sommes pas des monstres ! Notre travail est de vous rendre la vie facile, c'est pourquoi Upsun suppose que votre mode de construction sera Composer, alors livrez simplement vos fichiers composer.json et composer.lock et laissez-nous nous occuper du reste.

Une fois votre application construite, le système de fichiers sera en lecture seule, garantissant que la seule chose qui modifiera votre code sera votre prochain commit. "Mais attendez, comment suis-je censé gérer les médias téléchargés par l'utilisateur si je ne peux pas écrire sur le système de fichiers ? Ne vous inquiétez pas mon ami, nous vous couvrons, définissezsimplement des montages pour les dossiers auxquels vous avez besoin d'un accès en écriture, et vous êtes prêt à partir. Par exemple, avec Drupal, vous pourriez vouloir définir plusieurs montages pour les médias, le cache, les journaux, etc.

Jetez un coup d'œil à cet extrait du fichier .upsun/config.yaml pour un exemple des montages dont Drupal a besoin :

applications : drupal-app : mounts : # Le répertoire de fichiers par défaut de Drupal. '/web/sites/default/files' : source : "storage" source_path : 'files' # Drupal a son propre répertoire tmp dédié. '/tmp' : source : tmp source_path : 'tmp' # Les téléchargements de fichiers privés sont stockés en dehors de la racine du site web.
      '/private' : source : "storage" source_path : 'private' # Drush a besoin d'un espace de stockage pour ses propres caches. '/.drush' : source : "storage" source_path : 'drush' # Drush essaiera de sauvegarder les sauvegardes dans ce répertoire, il doit donc être # accessible en écriture même si vous n'aurez presque jamais besoin de l'utiliser. '/drush-backups' : source : "storage" source_path : 'drush-backups'

Comment faire un commit en production

A ce stade, vous êtes peut-être inquiet au sujet de vos fichiers de configuration Drupal. Après tout, il se peut que vous fassiez des changements en production et que vous souhaitiez les valider. Le processus standard est assez simple :

1. Créez un nouvel environnement à partir de l'environnement que vous avez modifié, par exemple, votre environnement de production. C'est facile avec notre CLI Upsun:

upsun environment:branch [new-branch-name]

Note : upsun branch est un alias que vous pouvez utiliser pour upsun environment:branch

Upsun va alors opérer sa magie et vous fournir un nouvel environnement de prévisualisation, avec une copie octet par octet des données du parent. Cela signifie que tout code que vous modifiez maintenant sera appliqué au même contexte que le parent, donc si vos tests CI/CD sont verts, vous pouvez déployer.

2. Tirez votre environnement nouvellement créé localement et faites ce que vous avez à faire

Pour travailler localement, nous vous suggérons d'utiliser DDEV, car c'est l 'option préférée pour Drupal, et parce que nous sommes fiers d'avoir Randy Fay, le mainteneur de DDEV, dans notre équipe. Pour plus d'informations à ce sujet, vous pouvez suivre nos docs d'installation ou les docs d'installation de DDEV.

Pour faire court, une fois que DDEV est installé et configuré, vous pouvez passer à la nouvelle branche et extraire les données en deux commandes comme indiqué ci-dessous :

upsun checkout [nouveau-nom-de-branche] ddev pull upsun

Et c'est tout ! Vous avez maintenant un environnement local identique qui fonctionne et vous pouvez faire tout ce dont vous avez besoin en utilisant ddev drush (oui, vous aurez probablement besoin de commencer avec ddev drush cr de toute façon). Il est temps d'exporter, de commiter, de pousser et d'ouvrir une pull request (PR).

3. Un nouvel environnement de prévisualisation sera créé pour votre PR, vous permettant de revoir le résultat avant de fusionner - ou devrais-je dire, de déployer !

Dans l'ensemble, il s'agit d'un flux standard pour notre approche GitOps, car tout ce qui n'est pas versionné serait perdu lors du prochain déploiement - surtout si vous utilisez nos hooks de construction et de déploiement pour automatiser des tâches ennuyeuses, comme l'importation de configurations ou le vidage du cache.

Jetez un coup d'œil à cet extrait du fichier .upsun/config.yaml, en particulier dans la section deploy, qui contient des commentaires et des exemples d'actions que vous pouvez effectuer en utilisant notre hook deploy :

# Les hooks vous permettent de personnaliser votre code/environnement lorsque le projet passe par les étapes de construction et de déploiement # Plus d'informations : https://docs.upsun.com/create-apps/app-reference.html#hooks hooks : deploy : | set -eux cd web bash $PLATFORM_APP_DIR/drush/platformsh_deploy_drupal.sh

Ci-dessous vous pouvez voir le contenu du fichier drush/platformsh_deploy_drupal.sh qui a été appelé dans la section de code précédente :

   #!/usr/bin/env bash # # Nous ne voulons pas exécuter les commandes drush si drupal n'est pas installé.
# De même, nous ne voulons pas essayer d'exécuter config-import s'il n'y a pas de fichiers de configuration à importer. @todo étendre encore pour passer --uri pour tous les sites, avec un œil sur le multisite if [ -n "$(drush status --field=bootstrap)" ] ; then drush -y cache-rebuild drush -y updatedb if [ -n "$(ls $(drush php :eval "echo realpath(Drupal\Core\Site\Settings::get('config_sync_directory')) ;")/*.yml 2>/dev/null)" ] ; then drush -y config-import else echo "No config to import. Skipping." fi else echo "Drupal n'est pas installé. Sauter les étapes standards de déploiement de Drupal" fi

Une petite astuce supplémentaire pour vous : vous pouvez utiliser drush sur vos environnements Upsun très facilement si vous en avez besoin (drush uli, quelqu'un ?), grâce à notre commande CLI upsun drush. Vous voyez ? Nous avons toujours pensé aux sites Drupal.

Dans mon prochain billet, nous irons un peu plus loin et verrons comment exporter du contenu Drupal et surtout comment automatiser ces exportations. Vous pouvez consulter notre modèlePlatform.sh Drupal 10 ou parcourir le repo awesome-platformsh pour vous inspirer. Enfin, n'hésitez pas à poser des questions ou à partager vos astuces Drupal sur notre site communautaire