Dans cette article je vais expliquer rapidement comment configurer le déploiement d’un projet Symfony 3 via Capistrano.

Capistrano est un outils de déploiement développer en ruby pour plus détails de vous conseille d’aller ici :

Je me suis également beaucoup inspiré de cette article pour mettre en place mon outils de déploiement :

Pour commencer nous installons les paquets nécessaires à l’interprétation du Ruby :

sudo apt install ruby

Créez un dossier par projet a déployer :

ex : /capistrano/monprojet1

Créer un fichier gemfile à la racine de ce dossier et ajoutons ces lignes :

# File : Gemfile
source 'https://rubygems.org'
gem 'capistrano',  '~> 3.4'
gem 'capistrano-file-permissions'
gem 'capistrano-composer'
gem 'capistrano-symfony', '~> 1.0.0.rc1'

Installation des librairies nécessaires au fonctionnement de Capistrano :

sudo gem install bundler
bundle install

Installation des fichiers de configurations de base de Capistrano :

bundle exec cap install

Pour ce qui est du déploiement on va partir sur un cas assez classique ou nous avons un environnement de pre-production et un environnement de production.

Je pars du principe que nous avons configuré un connexion ssh pour chaques environnements avec un utilisateur qui a des droits limiter pour notre projet web.

Je considère également que nous avons fait un alias ssh (optionnel ceci evitera de taper votre mot de passe à chaque déploiement) pour nous connecter à chaque environnement si ce n’est pas le cas aidez-vous de cette article

Quand tout ceci est ok, on va commence par mettre à jour notre fichier deploy.rb

set :application, 'nomdevotreprojet'
set :repo_url, 'git@bitbucket.org:UtilisateurGit/repositoryGit.git'

set :scm, :git

set :composer_install_flags, '--no-interaction --optimize-autoloader'

# Symfony console commands will use this environment for execution
set :symfony_env,  "prod"

# Set this to 2 for the old directory structure
set :symfony_directory_structure, 3
# Set this to 4 if using the older SensioDistributionBundle
set :sensio_distribution_version, 5

# symfony-standard edition directories
set :app_path, "app"
set :web_path, "web"
set :var_path, "var"
set :bin_path, "app"

# The next 3 settings are lazily evaluated from the above values, so take care
# when modifying them
set :app_config_path, "app/config"
set :log_path, "app/logs"
set :cache_path, "app/cache"

set :symfony_console_path, "app/console"
set :symfony_console_flags, "--no-debug"

# Remove app_dev.php during deployment, other files in web/ can be specified here
set :controllers_to_clear, ["app_*.php"]

# asset management
set :assets_install_path, "web"
set :assets_install_flags,  '--symlink'

# Share files/directories between releases
set :linked_files, []
set :linked_dirs, ["app/logs"]

# Set correct permissions between releases, this is turned off by default
set :file_permissions_paths, ["app"]
set :permission_method, false

# Share files/directories between releases
set :linked_files, %w{app/config/parameters.yml}
set :linked_dirs, %w{app/logs web/uploads}

after 'deploy:starting', 'composer:install_executable'
after 'deploy:updated', 'symfony:assets:install'
after "deploy", "symfony:clear_apc"

Je n’ai jamais fait de Ruby mais on peux assez facilement lire les actions qui sont effectuées.

Dans le dossier config on a un fichier :

• production.rb
• staging.rb

Personnellement je les ai renommé en preproduction et production

Dans ces deux fichiers nous allons spécifier les accès aux différents environnements, exemple de fichier de production.rb mais pour la pre-production ce sera le même :

set :stage, :prod

set :ssh_user, 'nomdevotreutilisateur'
server 'IPDELAMACHINEDEPRODUCTION', user: fetch(:ssh_user), roles: %w{web app db}

set :branch, 'master'
#path for the deploy
set :deploy_to, '/home/nomdevotreutilisateur/public_html/prod'

Les 3 dernières lignes sont des actions que l’on lance après certain événements :

after EVENT -> 'deploy:starting', ACTION -> 'composer:install_executable'

Capistrano contient tout une liste d’évènements tout le long de son déploiement.

Et il est également possible de définir ces propres événements personnalisés, ce que j’ai dut faire pour effectuer certaines opérations lors du déploiement (dans /lib/capistrano/tasks/symfony.rake –> fichiers .rake automatiquement reconnu et interpréter ) :

namespace :assetic do
  desc 'Assetic dump'
  task :dump do
       on roles(:app) do
            symfony_console "assetic:dump", "--env=prod"
       end
  end

  after 'symfony:assets:install', 'assetic:dump'
end
namespace :db do
  desc 'Force database update'
  task :database_force do
       on roles(:app) do
            symfony_console "doctrine:schema:update", "--force"
       end
  end

  desc 'Database validate'
  task :database_validate do
       on roles(:app) do
            symfony_console "doctrine:schema:validate"
       end
  end
  after 'deploy:updated', 'db:database_force'
  after 'db:database_force', 'db:database_validate'
end
namespace :symfony do
  desc "Clear apc cache"
  task :clear_apc do
     on roles(:app) do
            symfony_console "cache:accelerator:clear"
 end
 end
end

Ici 3 actions :

• La première gère les assets de votre projet et notamment la commande assetic:dump –env=prod
• La deuxième mets à jour le schema de base de données via un doctrine:schema:update –force (Attention si vous supprimer des champs et des données dans votre release il faudra penser à remettre ces données lors du revert)
• La troisième permet de vider le cache APC sur votre projet par l’intermédiaire de ce bundle qui permet de forcer l’application à vider le cache. Si APC est activé et que vous ne voulez pas utiliser ce bundle vous devrez redémarrer Apache2 mais vous permet le coté automtisation car votre utilisateur n’est pas censé avoir le droit soir vous vous débrouillez pour effectuer cette action en php apc_clear_cache

Il est possible que lors déploiement l’action de vider le cache ne fonctionne pas (dossier récalcitrant) exécutez à nouveau le déploiement afin que cela fonctionne.

Et enfin pour déployer votre projet :

bundle exec cap preproduction deploy
bundle exec cap production deploy

Selon l’environnement que vous souhaitez déployer, Capistrano est assez verbeux sur ses actions et il possible de le rendre encore plus verbeux via l’option –verbose.