[Article] Automatisez le déploiement de vos sites

[dmathieu]

Petit rappel : ce topic a été réalisé de manière bénévole par kazhar. :wink:

Je vois beaucoup de webmasters qui gèrent leur site perso en déployant celui-ci via FTP.
Je vais tenter dans cet article de démontrer pourquoi ce genre de technique est dépassée, sujette à des erreurs et fortement à proscrire.

Note : la technique de déploiement que je vais donner requiert d'avoir un accès SSH sur votre site.
Tous les hébergeurs ne le proposent pas en mutualisé. Mais les meilleurs le font, tel que OVH.
Si vous êtes en VPS, RPS ou dédié, vous avez un accès SSH. Il vous suffit de l'utiliser.

Qu'entends-t-on par déploiement ?
A l'heure actuelle, vous faites peut-être les modifications sur votre site directement en production. Lorsque vous avez une erreur, vous la corriger directement en production et vos utilisateurs peuvent suivre l'avancée de votre développement en temps réel.
Pas super cool.

L'idée est donc bien évidemment de développer en local.
Quand c'est possible, tester sur une machine de staging (qui n'a pas forcément besoin d'être distante. Une vieille machine chez vous fera très bien l'affaire).
Puis une fois que vos mises à jour sont faites et que vous n'avez aucun bug, vous pouvez passer en production.

Mais pourquoi ne pas utiliser le FTP ?
Lorsque vous mettez votre application à jour, il n'y a pas forcément que les fichiers à envoyer. Il peut y avoir la base de données à mettre à jour, des fichiers à créer.
Voir redémarrer le serveur (PHP ne le requiert pas. Mais c'est nécessaire pour des applications Python ou Ruby).
Toute action manuelle peut amener à des erreurs, des oublis et donc des bugs sur votre application. Pas cool.

Pour cette raison, utiliser un simple accès FTP en envoyant manuellement ses fichiers est à prohiber.


Ok et je fais comment ?
Haaave you met Capistrano ?
Capistrano est un outil de déploiement d'application (ce n'est pas le seul. Mais c'est le meilleur).
L'idée est simple : vous rédigez un script (en Ruby) contenant toutes les actions de déploiement de votre application.
Et lorsque vous exécutez ce script, celui-ci se connecte à votre machine de production, réalise les actions nécessaires et se déconnecte.

En soi, capistrano serait utilisable pour toute tâche un petit peu répétitive à exécuter sur une machine linux.
Une ou plusieurs d'ailleurs puisqu'il gère sans problème les machines multiples.

Tout d'abord, installons Capistrano. Pour cela, vous devez avoir auparavant installé Ruby et Rubygems.
Toutes les distributions linux les ont dans leurs paquets. Pour les windows, c'est ici et ici que ça se passe.

gem install capistrano

Ecrivons par exemple une tâche simple :

set :application, "webrankinfo"
set :user, "kazhar"
set :scm_username, user
set :repository,  "git://github.com:dmathieu/refsite-php.git"

set :deploy_to, "/home/git/refstats"
set :scm, :git

set :domain, "dmathieu.com"
role :app,  domain, :primary => true

# Si vous utilisez un port SSH différent de celui par défaut :
# ssh_options[:port] = 22

# --------
# Commands
# --------
namespace :deploy do
  desc "Update project from repository"
  task :default do
    stream "cd #{deploy_to}; git pull"
  end
end # Deploy

desc "Make sure database is in sync with models"
task :syncdb do
  stream "cd #{deploy_to}; rake db:migrate RAILS_ENV='production'"
end
after :deploy, :syncdb

desc 'Restart the application'
task :restart do
  stream "cd #{deploy_to}; touch tmp/restart.txt"
end
after :syncdb, :restart

Ici, je vous fournis l'une de mes tâches pour un projet ruby on rails. Mais il suffit de créer ses propres tâches pour faire ce que vous désirez.

Que faisons-nous ?
Tous les :set en haut du document sont des définitions de variables de configuration.
Le :role définit notre serveur. Il faut en créer un pour chacune des machines sur lesquelles déployer votre application.

Puis nous entrons dans les commandes.
La tâche "default" sera appellée automatiquement. Ici, le project est versionné avec git et hébergé sur github. Mais Capistrano fonctionne avec de multiples scm (git, mercurial et svn).

La commande dans la tâche default mets à jour le code source de l'application.
Puis vous voyez la tâche :syncdb, qui est exécutée après la tâche default (cf. "after :deploy, :syncdb").
Cette méthode permet de mettre à jour la base de données avec les modifications déjà faites (il s'agit d'un projet rails. Donc j'utilise les migrations. Mais Zend Framework et Symfony possèdent également des fonctionnalités similaires).

Enfin on vois la tâche :restart exécutée après le syncdb. Celle-ci permet de redémarrer le projet et donc de prendre en compte les modifications données.

Il n'y a plus qu'à exécuter le script pour que votre application soit mise à jour.

cap deploy -f deploy.rb

Ou deploy.rb est le nom de votre script de déploiement.

Ainsi en "perdant" un peu de temps à créer ce genre de script, vous en gagnez beaucoup en évitant de multiples erreurs de mise à jour de votre application et améliorez donc l'image professionnelle de votre site web en étant sur de ne pas afficher de message d'erreur à vos utilisateurs.

Si vous avez apprécié cet article, n'hésitez pas à cliquer sur

.
Et si vous avez des commentaires/modifications, le sujet n'est pas fermé

 

[Leonick]

Je vois beaucoup de webmasters qui gèrent leur site perso en déployant celui-ci via FTP.
Je vais tenter dans cet article de démontrer pourquoi ce genre de technique est dépassée, sujette à des erreurs et fortement à proscrire.

je n'ai pas vu à quel endroit il était démontré que la màj par ftp était dépassée pour des projets en php.
La modification de BDD pouvant être effectuée en php (pour des modifications simples) ou directement en ssh pour une création/mise à jour de grosse BDD
Et pour éviter d'afficher les erreurs aux visiteurs, tu as error_reporting() à ta disposition et set_error_handler() qui te permet de rediriger les erreurs vers ta propre gestion (ce qui est plus propre pour l'internaute et plus sécurisant pour toi, car tu peux logger toutes les erreurs et la configuration des scripts au moment de l'erreur)

 

[Robinson]

Moi je continuerai avec mon SFTP en modifiant en 3 coups de cuillères à pot directement les fichiers du serveur ^^
Pour faire des tests, je crée des fichiers test (non accessibles aux visiteurs) directement sur le serveur.

On peut faire quelques boulettes au début, mais on devient assez vite expert quand on effectue cela tous les jours

Suis un grand fainéant, mes profs d'info ont toujours dis que c'était la plus grande qualité pour être un bon informaticien ^^ (on a rien foutu pendant 2 ans tellement qu'on était doué dans le domaine )

 

[dmathieu]

Oui, mais tout ce que tu fait, tu le fait manuellement. C'est cela qui est propice à avoir des erreurs.
Limiter l'action humaine lors du passage en production évite énormément d'erreurs.
Et c'est ce à quoi capistrano sers et ce que j'explique dans cet article.

@Robinson
Quand les enseignants en informatique disent qu'il faut être fainéant, ils disent cela pour vous pousser à ne pas écrire deux fois la même ligne de code. C'est sur ce point la qu'il faut être fainéant.
Si la fainéantise cela signifie perdre tout professionnalisme et que cela se voie, c'est à renommer en idiotie

 

[Leonick]

Oui, mais tout ce que tu fait, tu le fait manuellement. C'est cela qui est propice à avoir des erreurs.

pour ftp, tu fait la màj de tout ton site et c'est ton logiciel qui se débrouille pour ne copier que les fichiers modifiés

Si la fainéantise cela signifie perdre tout professionnalisme et que cela se voie, c'est à renommer en idiotie

non, juste à ne pas vouloir factoriser à outrance.
Quelle différence entre faire une màj avec filezilla et avoir un script dans sa partie admin de site qui permette d'effectuer les modifications dans sa BDD et de le faire avec ton type d'automatisation ?
Si on oublie d'ajouter certaines modifications souhaitées dans ton script, il ne pourra pas plus les effectuer :wink:

 

[Robinson]

Quand cela ne se voit pas et ne gêne pas l'internaute, c'est en plus du professionnalisme, de l'intelligence alors (gain de temps énorme quotidiennement, je ne me vois pas travailler autrement)

Ton système est très bien pour des grosses modifications sans doute. Moi mon système me permet de travailler de n'importe où avec n'importe quel pc, pour un webmaster, ce n'est pas rien... (ps : je travaille exclusivement au bloc note, ce qui tend à me faire croire que suis bien rôdé dans le maniement des lignes de code)

Mais très bon article pour ceux n'ayant pas peur de changer/d'expérimenter de nouvelles habitudes de travail.

 

[dmathieu]

Sauf que les modifications que tu fait sont de toute façon toujours les mêmes : envoyer les fichiers; mettre à jour ta base de données et redémarrer le serveur.
Tu ne modifie pas ton script capistrano à chaque fois. C'est ton code & tes données de migration que tu modifie.
Après comme dit au départ, des tests sur un serveur de staging ne sont jamais de trop. Donc si il te manque quelque chose, tu t'en rendra compte en passant en staging.

M'enfin je me suis peut-être trompé et vous n'êtes peut-être pas suffisamment orienté code pour qu'on vous parle de déploiement automatisé, TDD et méthodes agiles.
Tant pis.

Ton système est très bien pour des grosses modifications sans doute. Moi mon système me permet de travailler de n'importe où avec n'importe quel pc, pour un webmaster, ce n'est pas rien...

Je bosse également depuis n'importe quelle machine quand je veux.

Un "git clone <adresse de mon repository>" et j'ai mon site.
Un "./deployment/deploy" et le site est poussé en production.

 

[anemone-clown]

En se limitant au cadre php + sql, perso, j'aime encore assez bien un gestionnaire de projet avec un FTP (secure éventuellement)... dès que le code PHP est validé, le transfert s'exécute. Les actions sur les bases de données (modification de structure par exemple) sur un site en production ne sont, logiquement, pas légion et peuvent se gérer ponctuellement manuellement via un phpmyadmin par exemple.

Dans d'autres configurations que php+sql, la problématique est différente.

 

[Leonick]

Sauf que les modifications que tu fait sont de toute façon toujours les mêmes : envoyer les fichiers; mettre à jour ta base de données et redémarrer le serveur.

et alors, qu'est ce qui ne permet pas de le faire avec le duo ftp/script admin en php ?
et pourquoi redémarrer le serveur php ? sauf si tu veux faire des modifs sur apache, mais là, tu ne le feras pas si fréquemment que ça

M'enfin je me suis peut-être trompé et vous n'êtes peut-être pas suffisamment orienté code pour qu'on vous parle de déploiement automatisé, TDD et méthodes agiles.

j'aime assez cet argument "ouai, mais vous n'êtes que des bricoleurs à la petite semaine, moi je vous parle de développement pro :lol:
En même temps, "méthodes agiles" ça veut dire ne plus suivre le cahier des charges initial et adapter les développements aux besoins immédiats du clients, soit du développement à court terme. Après qu'on l'habille d'une simili méthodologie, extrem programming, etc...en n'oubliant pas qu'initialement les RAD avaient été créés pour faire créer des maquettes de projet et non pour créer des délivrables.
Mais on en revient toujours à la même querelle : kikséti qu'est mieux du développement objet ou procédural ? un code objet mal défini et mal programmé est-il plus ou moins facilement maintenable qu'un code procédural bien développé ? :mrgreen:

 

[lyonist]

kaaaaazhaaaaaaaarrr !

 

[dmathieu]

et pourquoi redémarrer le serveur php ? sauf si tu veux faire des modifs sur apache, mais là, tu ne le feras pas si fréquemment que ça

En PHP tu n'a pas besoin de redémarrer le serveur. L'exemple que je donne est pour une application rails.
Chose que je mentionne dans mon article.

Voir redémarrer le serveur (PHP ne le requiert pas. Mais c'est nécessaire pour des applications Python ou Ruby

 

[Leonick]

donc en php, màj en ftp puis exécution de ton script de màj (en php) dans ta console admin et ça roule :wink:

 

[dmathieu]

Et du coup tu arrive à faire la même chose que moi : tu développe un script pour mettre automatiquement tes données à jour.
La seule différence étant que moi, j'ai une seule étape. Et toi deux

Je ne dis pas que cette méthode est la méthode miracle. Je dis que c'est une technique et j'explique comment l'utiliser.

Note : en FTP il suffit que tu modifie pour une raison x ou y ton fichier de configuration d'accès à la bdd et que tu l'envoie par mégarde pour tout casser.
Avec un outil de gestion de version et une mise à jour direct sur le serveur de production, tu ignore ton fichier de configuration qui n'est alors pas versionné.
Et tu peut le modifier comme tu le désire en local, tu es sur qu'il ne sera jamais modifié par mégarde en local.

 

[fandecine]

kazhar, I love You

Je n'utilise que PHP mais je partage ton approche. Personnellement, j'utilise des serveurs de production et un serveur de développement avec des mise à jour par rsynch sous ssh. (le serveur de développement servant aussi accessoirement de backup des données importantes des autres serveurs)

Mais je ne fait rien en local (mon rythme de vie nomade ne s'y prête pas) et surtout, j'utilise subversion (SVN) sur le serveur de développement pour gérer les différentes versions et mise à jour. J'ai pas mal galérer pour le compiler et le paramétrer, puis l'utiliser mais maintenant je ne peux plus m'en passer :wink:

Pour éditer et uploader mes fichiers sur le serveur j'utilise Winscp + putty + Scite et aucun de mes serveur n'a FTP installé (mois de mise à jour et de surveillance coté sécurité) je passe par SFTP :mrgreen:

 

[dmathieu]

@fandecine

J'ai même pas de sftp moi
Capistrano se connecte en SSH et fait un git pull (et il ferait un svn update si j'utilisais svn).

 

[fandecine]

J'ai oublié de préciser que je vie en milieu rural (à la campagne quoi :mrgreen: ) et que je ne dispose en général que de l'ADSL à 1Mo ... en descendant ce qui fait pas lourd en remontant :cry: donc les vas et vient local/distant ...

Pour Capistrano, j'avoue humblement ne pas connaitre cet outil mais je promet d'y jeter un oeil

 

[Leonick]

en FTP il suffit que tu modifie pour une raison x ou y ton fichier de configuration d'accès à la bdd et que tu l'envoie par mégarde pour tout casser.

dans mon fichier de config de BDD, j'ai bien scindé les 2 types d'accès : test local et serveur prod

 

[Bigb06]

J'utilise une approche similaire mais avec des outils différents pour mes projets PHP:
- développement sous Eclipse avec repository sous SVN
- deploiement via script ant pour concaténer/minifier les fichiers CSS et javascript

La gestion via FTP est à proscrire pour les gros projets sous peine d'erreurs de manipulation ou autre.

 

[Bellegarde-webb]

Quand les enseignants en informatique disent qu'il faut être fainéant, ils disent cela pour vous pousser à ne pas écrire deux fois la même ligne de code. C'est sur ce point la qu'il faut être fainéant.
Si la fainéantise cela signifie perdre tout professionnalisme et que cela se voie, c'est à renommer en idiotie

Je précise : la fénéantise n'en n'est pas vraiment une car ce dont il s'agit est de ne pas se précipiter
1) pour écrire du code mais de réfléchir longuement avant à l'algo. ou dans les conditions actuelles au moins à ce que l'on veut exactement etc.,
2) de ne pas se précipiter pour écrire le code mais de le commenter abondamment,
3)de ne pas ce précipiter pour exécuter le code et de bien vérifier avant la syntaxe par exemple,
4)de ne pas se précipiter pour clamer que l'on a terminé alors que l'on n'a pas fait les tests ...

Bon, je suis de la vieille école et je ne fais pas toujours ce que je prêche car je n'enseigne plus :lol: :lol: :lol:

J'oubliais +1 reco pour Kazhar et son article

 

[NoGlob]

Bon article

Perso j'ai un serveur clone (en local) sur lequel je fais tourner la mise à jour, puis lorsque c'est bon, par SSH j'active le mode maintenance sur le serveur de prod et je fais mon upload. Les droits et les chemins étant identique sur le serveur de prod et le serveur de dev ça passe nikel.

Pour le gestionnaire de version j'utilise bzr, je pense migrer vers git.

 

[lesbonsplansdesophie]

+1 avec Kazhar

Pour les projets pro sous ruby on rails, capistrano est incontournable, car il permet de directement:
- effectuer les migrations nécessaires sur la BDD (quand on veut ajouter/modifier la structure de la BDD etc.)
- pousser en prod sans erreur
- effectuer les tâches de compressions des css / js etc. automatiquement
- relancer les serveurs
- agir sur le load balancer, memcache etc.

Probablement pas d'intêrét pour un projet perso, mais pour un site pro conséquent, Kazhar a parfaitement raison... Laissez-lui le bénéfice du doute, faites un essai si vous estimez que ça peut en valoir la peine, et vous verrez que vous serez rapidement convaincus.

 

[dmathieu]

Et capistrano n'est pas exclusif a rails niveau meme ruby. Je deploie des applications django avec a merveille

 

[Lupulus]

J'ai une question:
Je fais du développement de site e-services. Mon patron vient me voir et me demande de créer un module pour tel ou tel site afin de rajouter des fonctionnalités demandées par le client mais le but est au final de faire que TOUS les sites aient intégré le module.

Du coup j'aimerai faire un script automatique permettant de mettre à jour tous les sites quand je crée une fonctionnalité sur l'un d'entre eux.

Je travaille sous Ubuntu avec l'IDE NetBeans, je fais mes modifs en local puis avec git je fais un push à la fin en ftp sur le serveur de production (bon ya plus de commandes mais c'est du git quoi).

Si dmathieu peut m'aider ou si quelqu'un sait par quoi je pourrais commencer ça serait super.

Merci d'avance

 

[spout]

@Lupulus: avec des githooks: https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks- ... ment-tasks

Sinon comme indiqué dans le topic avec Capistrano / Fabric / Dokku / ...