Le document décrit l'évolution des méthodes de déploiement des applications PHP, de l'utilisation de FTP dans les débuts jusqu'à l'intégration continue et l'automatisation moderne. Il souligne l'importance des outils comme Deployer et Jenkins pour la gestion efficace et sécurisée des déploiements. Le texte conclut sur les perspectives d'avenir et les innovations possibles dans le domaine.

1. Déploiement
d’applications PHP
Déploiement PHP : de l'âge de pierre à
nos jours.

2. Amélie DUVERNET
 Ingénieur DéveloppementWeb
 PHP-Addict depuis 2003
 Certifiée ZPCE en 2016
 Membre de l’AFUP
 Mon dada : Frameworks / DevOps
 Site : amelieonline.net
 Twitter : @bonjouramel.fr

3. Pourquoi une bonne méthode de
déploiement ?
Parce que.

4. Le déploiement
« mode bisounours »
 Plusieurs environnements :
 Développement « dev »
 Test « preprod »
 Production « prod »
 Code propre et sans bug
 Flexibilité des transferts de données
 Partage des sources entre développeurs

5. CHAPITRE 1 : L’âge de pierre

6. Age d’or de FTP
 Envoi des fichiers avec un client FTP
 Modification directe des bases avec scripts SQL
 Partage du code entre développeurs via FTP

7. Inconvénients du FTP
●
Pas très sécurisé
●
Possibilité de multiples attaques (Spoofing, force brute,
sniffing, …
●
Pas de cryptage de données
●
Lourd (possibilité d’oubli de fichiers …)
●
Partage des serveurs ???

8. CHAPITRE 2 : Le Moyen-âge

9. Exit FTP
 On se rend compte des désavantages de FTP
 Commit direct avec CVS/SVN
 RSYNC (obligation d’avoir un serveur SSH)
 Création de Batchs

10. Déploiement via RSYNC
 La configuration n’est pas centralisée sur le
seul serveur de sauvegardes.
 Sécurité : oblige à faire des autorisations SSH
dans les deux sens.
 Partage du code ???
 Partage des environnements ???
 Portabilité ???

11. Quid de la qualité du code ???

12. CHAPITRE 3 : La renaissance

13. Principe de l’IC
 Automatisation des compilations
 Cycle de compilation court

14. L’intégration continue
 Première fois mentionné par Grady Booch et se
réfère généralement à la pratique de l'extreme
programming.

15. Buts de l’IC
 Récupérer les dépendances
 Compiler
 Exécuter les tests
 Vérifier la qualité du code
 Packager
 Déployer
 Documenter

16. Avantages de l’IC
 Le code-source est partagé
 Les développeurs intègrent (commit)
quotidiennement (au moins) leurs modifications
 Des tests d'intégration sont développés pour valider
l'application
 Tests dans un environnement de production cloné
sont assurés
 Le déploiement est automatisé

17. Applications IC
 Jenkins (fork de Hudson, outil pour JAVA)
 ContinuousPHP
 Travis CI (Projets Open Source)
 SonarQube, supervision qualité code
 Tinderbox (Mozilla Fundation)
 Apache Continuum
 Team Foundation Server

18. Build de tests sous Jenkins

19. CHAPITRE 4 : Temps modernes

20. Outils de déploiement
 Deployer (PHP)
 PHP Capistrano (Ruby)
 Magallanes (PHP)
 Rocketeer
 Docker (Go)

21. Deployer
 Site web : www.deployer.org
 GitHub : deployphp / deployer
 Open-source
 Installation :
composer require deployer/deployer:~3.0
Ou wget, ou curl, tout ce qu’on veut …

22. Définition de multiples
environnements
server('prod_1', 'domain.com')
->user('user')
->password('pass')
->env('deploy_path', '/home/web1')
->stage('production');
server('prod_2', 'domain.com')
->user('user')
->password('pass')
->env('deploy_path', '/home/web2')
->env('extra_stuff', '...')
->stage('production');

23. Fichier de conf YAML
servers.yml
prod_1:
host : domain.com
user: www
identify_file: ~
stage: production
deploy_path : /home/www/
prod_2:
host: a.domain.com
user: www
identity_file:
public_key: /path/to/public.key
private_key: /path/to/private.key
password: mypass
stage: production
deploy_path: /home/www/
Dans deploy.php : serverList('servers.yml');

24. Cas de figure
 Ingrédients :
 Un projet ZF2 (ou autre)
 Un repository GIT
 Deux branches GIT : « Master » & « Jenkins »
 Un environnement Jenkins installé
 Un build configuré qui teste le code
 Un serveur de prod

25. Projet de preparation
 Branche “Master” : clone
de “Jenkins” sans :
– deployer
– SQL
– Utils
– Composer

26. Exécution
 Création d’un fichier deploy.php
<?php
require 'recipe/common.php';
server('prod', '10.61.110.116', 22)
->user('administrateur')
->password(‘xxxx’)
->stage('production')
->env('deploy_path', '/var/www/intranet')
->env('branch', 'master');
set('repository', '/opt/git/intranetv2.git');

27. Incidences sur environnement
« production »
 dep deploy:prepare production
 Arborescence de base

/releases

/shared
 dep deploy:release production
 /releases/20160321134855
 Lien symbolique /release
 dep deploy:update_code production
 Rapatrie tout le code du GIT

28. Jenkins : Post Build Task

29. deployshell.sh
 Dans le dossier de déploiement :
#!/bin/bash
cd ./deployer
dep deploy:prepare production
dep deploy:release production
dep deploy:update_code production
...
php ../SQL/autoupdate.php
grunt run:server ...
Puis GIT Push et Build.

30. Et donc …

31. Résultat du build

32. Notre environnement de prod !
… et c’est cool !

33. Futur du déploiement ...
 Ouverture vers des protocoles plus
portables ?
 Simplification du système CI ?
 Votre avis ?Vous déployez comment ?