Aujourd'hui, le terme "déploiement" est un incontournable dans le métier des devOps. Comment en sommes-nous arrivés à intégrer au mieux les mises en prod ? Faisons un bref historique pour ensuite terminer sur les nouvelles techniques de déploiement de nos applications PHP et leur mise en place dans l'intégration continue.
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
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 ???
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é ???
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
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 …
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
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
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.