Insérer Wp-deploy dans un projet wordpress

Publié le 14 Sep 2015 par Tony

La traduction, étape par étape, de l’installation et de la configuration de WP-Deploy, avec quelques points qui me paressent intéressants à développer.

Pour faire simple Wp-deploy sert à déployer via git (bitbucket) sur un/plusieurs serveurs via une simple ligne de commande :

$ cap [staging] deploy

Repo de wp-deploy -> https://github.com/Mixd/wp-deploy
ci-dessous : la traduction, étape par étape, de l’installation et de la configuration de WP-Deploy, avec quelques points qui me paressent intéressants à développer.

Note : J’ai commencé à utiliser cette méthode sur machine Vagrant (via https://github.com/roots/trellis) mais j’ai eu pas mal de problèmes au fil du temps donc pour ce tip, je me baserai sur une installation locale classique via MAMP pour expliquer la méthode.

Voici les points, positifs à l’utilisation de wp-deploy (déploiement de projets de WordPress avec Capistrano) dans un projet Wordpress :

  • Automatise les déploiements de WordPress via git / github (mais aussi bitbucket) sur un certain nombre d’environnements
  • Automatise la migration des bases de données entre les environnements (local/staging/production/...)
  • Supprime toutes les références à des URL de développement dans des environnements de production (et inversement)
  • Synchronise vos ajouts de fichier/répertoire entre les différents environnements
  • Prévient automatiquement les moteurs de recherche d’ignorer les environnements de développement
  • Notez que wp-deploy est assez stricte sur la façon dont vous travaillez avec WordPress et git, et il peut être différent de votre wordkflow habituel.

Inconvénients : Pour que wp-deploy (ou Capistrano en général) puisse fonctionner correctement, vous allez avoir besoin d’un accès SSH à la fois entre votre environnement local et votre serveur distant, mais aussi entre votre environnement local et votre compte GitHub ou Bitbucket. C’est, à vrai dire, la partie la plus sensible : la configuration local/repo/server.

Capistrano déploie votre application en un courant / répertoire lié symboliquement sur votre serveur, de sorte que vous aurez besoin de mettre votre document root pour ce dossier.

Pour démarrer, assurez-vous d’avoir une machine avec installé :

  • ruby
  • capistrano
  • Bundler
  • WP-cli

Pour commencer

Tout d’abord, vous allez avoir besoin de cloner le référentiel. Il ya un certain nombre de façons dont vous pouvez faire cela, cependant, car ce flux de travail nécessite l’utilisation de la ligne de commande, je vous recommande de le faire dans cela.

Entrer dans le répertoire de votre (futur) projet

$ cd votre/futur/projet
$ git clone --recursive https://github.com/Mixd/wp-deploy.git nom-du-project

Cela va cloner le repo wp-deploy dans un nom de dossier de votre choix et il va également télécharger les sous-modules inclus dans le repo.

Wp-deploy propose script bash pour « rebaser » le projet sur votre repo git perso (fonctionne avec github et bitbucket) , une fois que vous avez cloné le repo lancer :

$ bash config/prepare.sh
# Ensuite, un petit :
$ git remote add origin 'votre_repo_url'
# Et enfin, le bundle Ruby :
$ bundle install

Vous êtes maintenant prêt à mettre en place vos fichiers de configuration.

Configuration

Tout d’abord, vous devez définir les paramètres globaux de WordPress" rubrique dans config / deploy.rb:

set :wp_user, "aaronthomas" # The admin username
set :wp_email, "[email protected]" # The admin email address
set :wp_sitename, "WP Deploy" # The site title
set :wp_localurl, "http://localhost" # Your local environment URL

Ce sont les paramètres utilisés pour votre installation initiale de WordPress.

Vous devez également définir votre dépôt git dans le même fichier:

set :application, "wp-deploy"
set :repo_url, "[email protected]:Mixd/wp-deploy.git"

wp-deploy propose par défaut 2 environnements :

  • Le staging : Version de travail en ligne
  • La prod : Version finale

Vous devez configurer vos paramètres individuels de l’environnement dans config/deploy/staging.rb et config/deploy/production.rb:

set :stage_url, "http://www.example.com" server "XXX.XXX.XX.XXX", user: "SSHUSER", roles: %w{web app db}
set :deploy_to, "/deploy/to/path"
set :branch, "master"

C’est l’endroit où vous définissez votre accès SSH au serveur distant, et le chemin d’accès complet ou vous envisagez de déployer votre projet. La variable :stage_url est utilisé lors de la génération de votre fichier wp-config.php pendant l’installation. Le serveur peut être une adresse IP ou un nom de domaine. Le préfixe http: // est pas nécessaire. Dernière étape : Renommer le fichier database.example.yml en database.yml et le remplir avec les détails de base de données pour chaque environnement, y compris votre local. Ce fichier doit rester ignoré dans git.

Concernant le fichier .wpignore

Par défaut, Capistrano déploie chaque fichier au sein de votre pension, y compris les fichiers de configuration, DotFiles et diverses autres choses qui ne sont d’aucune utilité sur votre environnement distant. Pour contourner ce problème, wp-deploy utilise un fichier nommé .wpignore qui répertorie tous les fichiers et les répertoires que vous ne voulez pas déployer, une manière similaire à .gitginore empêche les fichiers d’être vérifié dans votre repo.

Intégration Slack

wp-deploy fait usage de Capistrano-slackify pour déclencher notifactions déploiement de Slack. Cette option est facultative, mais peut être assez pratique si vous êtes un utilisateur Slack. […] Personnellement, j’ai complètement fait sauter la fonction en retirant :

  • require 'capistrano/slackify’ -> de capfile
  • require './config/slack’ -> de config/deploy.rb
  • et suppression du fichier slack.rb dans config

Mise en place des environnements

Pour configurer WordPress sur votre serveur de production à distance, exécutez la commande suivante:

$ bundle exec cap production wp:setup:remote
Cela permet d’installer WordPress en utilisant les détails dans vos fichiers de configuration, et de faire votre premier déploiement sur votre serveur de production. wp-deploy va générer un mot de passe aléatoire et vous le donner à la fin de la tâche.
Vous pouvez également automatiser la mise en place de votre environnement local aussi, en utilisant
$ wp:setup:local
ou (encore mieux) vous pouvez gagner du temps et mettre en place les environnements locaux et distants « on the same time »
$ wp:setup:both

Déploiement

Pour déployer votre projet sur le serveur distant (par exemple ici la prod) :

$ bundle exec cap production deploy

Cela déploiera tout vote repo et ses sous-modules, à l’exclusion des fichiers et des répertoires inscrits dans votre fichier .wpignore.

Migrations de bases de données

AVERTISSEMENT : Soyez toujours prudent lors de la migration des bases de données sur les environnements de production en direct - Ce ne peut pas être défait et peut causer quelques problèmes assez graves si vous n’êtes pas pleinement conscient de ce que vous faites.

Les migrations des bases de données seront remplaceront également les URL en fonction de leur environnement (local/staging/prod/..).

Pour pousser votre base de données de votre environnent locale vers votre environnent distant :
$ bundle exec cap production db:push
Pour tirer la base de données de votre environnent distant vers votre evironment locale:
$ bundle exec cap production db:pull
Exécuter une sauvegarde de la base de données à distance (sans importer à votre env locale.):
$ bundle exec cap production db:backup

Cela va enregistrer un fichier .sql dans un db_backups / répertoire local au sein de votre projet. Tous les fichiers .sql sont - et doivent rester - git ignorée.

Synchronisation du dossier Upload Vous pouvez synchroniser de dossier d’upload de WordPress de la même manière que pour la base de données.

Pour pousser votre base de données de votre environnent locale vers votre environnent distant :
$ bundle exec cap production uploads:pull
$ bundle exec cap production uploads:push

Bonus : pour mettre à jour le sous-module WordPress à la dernière version, exécutez:

Pour pousser votre base de données de votre environnent locale vers votre environnent distant :
$ bundle exec cap production wp:core:update

Tony.

comments powered by Disqus