Déployez simplement vos projets Symfony2 avec Capifony !


Technique

Vous souhaitez améliorer la qualité de vos déploiements sans pour autant passer des heures à configurer rsync via des scripts bash ?

Capistrano vous permet de simplifier tout ce processus en offrant la possibilité de déployer vos applications via de simples fichiers de configuration, mais aussi en ajoutant quelques solutions supplémentaires.
À savoir par exemple la possibilité de faire un “rollback” après un déploiement qui s’est mal produit, de déployer vers un cluster, ou encore définir plusieurs environnements de destination (utile si vous avez un serveur de dev, de preprod, et de prod).

La communauté Symfony a eu la bonne idée de vouloir faciliter le “push” en production des projets Symfony1 et Symfony2 en s’appuyant sur une base Capistrano.
C’est ainsi que Capifony est né…

disko capifony Déployez simplement vos projets Symfony2 avec Capifony !

Création d’une config de déploiement

Rendez-vous à la racine de votre projet Symfony2, puis :

bash
$ capifony .

Vous pouvez vous apercevoir que l’outil a créé deux fichiers, un nommé Capfile à la racine, qui définit la nature de votre projet (projet Symfony1 ou Symfony2), et un autre deploy.rb qui a été placé dans votre répertoire app/config/ avec le reste de votre configuration Symfony.

Prenez votre éditeur favori puis éditez le fichier selon vos besoins. Chez DISKO, nous utilisons ce modèle pour chacun de nos projets :

set :stages, %w(preprod prod)
set :default_stage, "preprod"
set :stage_dir, "app/config"
require 'capistrano/ext/multistage'

En effet, nous passons par défaut par une configuration de type “multistage”, c’est à dire que nous voulons déployer notre projet sur plusieurs environnements, car nous délivrons à chacun de nos clients une preprod ainsi qu’une production (au minimum).
La ligne stages permet d’énumérer les environnements, et donc les fichiers de configuration. Dans notre cas, un fichier preprod.rb ainsi qu’un fichier prod.rb seront requis.

Ensuite, nous allons voir le fichier preprod.rb, sachant que le fichier est quasi-similaire que celui de prod, mis à part le ssh et le répertoire de destinations qui sont différents.

set :application, "Nom de votre projet"
set :domain, "user@preprod.com" # Le SSH de destination
set :deploy_to, "/home/votresite/votreprojet" # Le répertoire de destination
set :app_path, "app" # Le dossier d’application, laissez app
set :user, "dizda" # Le nom d’utilisateur du serveur distant

set :repository, "git@host:symfony2/votreprojet.git" # L’URL de votre repository
set :branch, "prod" # La branche Git, utile si vous pushez vos releases de prod sur une branche particulière
set :scm, :git # SVN ? Haha, vous plaisantez j’espère :-)
set :deploy_via, :copy # Ils y a plusieurs méthodes de déploiements, nous utilisons la méthode de copy

set :model_manager, "doctrine" # ORM

role :web, domain
role :app, domain, :primary => true

# Nous utilisons sudo pour régler les permissions via la methode :chown
# préférez l’utilisation des ACLs si c’est disponible sur votre serveur

set :use_sudo, true
set :keep_releases, 3 # Le nombre de releases à garder après un déploiement réussi

## Symfony2
set :shared_files, ["app/config/parameters.yml"] # Les fichiers à conserver entre chaque déploiement
set :shared_children, [app_path + "/logs", "vendor"] # Idem, mais pour les dossiers
set :use_composer, true
set :update_vendors, false # Il est conseillé de laisser a false et de ne pas faire de ‘composer update’ directement sur la prod
#set :composer_options, "--verbose --prefer-dist" # Permet de spécifier des paramètres supplémentaires à composer, inutile dans notre cas
set :writable_dirs, ["app/cache", "app/logs"] # Application des droits nécessaires en écriture sur les dossiers
set :webserver_user, "www-data" # L’utilisateur de votre serveur web (Apache, nginx, etc.)
set :permission_method, :chown # Dans le cas où vous n’avez pas les ACLs, ne pas oublier de mettre :use_sudo à true
set :use_set_permissions, true
set :dump_assetic_assets, true # dumper les assets

#default_run_options[:pty] = true # Si vous avez cette erreur : no tty present and no askpass program specified, alors décommentez
#ssh_options[:forward_agent] = true # Idem que ci-dessus

# Permet d’avoir le détail des logs de capistrano, plus facile à débugger si vous rencontrer des erreurs
logger.level = Logger::MAX_LEVEL

# Et enfin, si jamais vous rencontrez des erreurs de permissions, vous pouvez rajouter ces lignes suivantes :
after "deploy:finalize_update" do
run "chown -R dizda:www-data #{latest_release}"
run "sudo chmod -R 777 #{latest_release}/#{cache_path}"
run "sudo chmod -R 777 #{latest_release}/#{log_path}"
end

Voilà vous n’avez plus qu’a tester votre déploiement, en exécutant les commandes suivantes :

$ cap preprod deploy:setup (si c’est votre première fois)
$ cap preprod deploy

Un grand nombre de lignes s’affichera avec toutes les commandes que Capifony exécute sur le SSH distant.

Si c’est votre premier déploiement, vous assisterez donc à l’installation des vendors via composer, magique

Sachez que cela reste une bonne pratique d’utiliser Capifony (ou un outil du même genre), car il supprime les fichiers inutiles qui ne sont pas censés se trouver sur une “prod”, comme par exemple le fichier app_dev.php, ainsi que quelques autres petites choses que l’on peut facilement oublier entre deux mises en prod.

Si vous avez bien suivi, dorénavant vos “mises en prod” ne prendront plus que 30 secondes !
Bravo et bon déploiement !

Laisser un commentaire

  1. Merci pour cet article qui m’a été fort utile.

    Je me posais une question : n’est-il pas possible de prendre ce qu’il y a en commun dans les fichiers preprod.rb et prod.rb pour le mettre à la place dans deploy.rb ? Cela éviterait de répéter ces informations.