Deployer un site avec Git

Attention, prudence : sur ce coup, j'en parle au fur et à mesure que je découvre…

Update: cet article est imprécis, et depuis la technologie a évolué. Les principes sont toujours valides mais il y a de meilleures manières de s'y prendre.

Pourquoi pas avec FTP ?

FTP fonctionne toujours aussi bien qu’avant. Je continue personnellement de l’utiliser pour de nombreux projets.

Mais le déploiement avec Git offre d’excellentes options, est moins sujet aux mauvaises manipulations, et permet de garder une cohérence globale dans le workflow d’un projet suivi avec Git.

Au lieu de choisir à la main (à la souris) les fichiers/dossiers à transférer dans le serveur et de les faire glisser dans la fenêtre du client FTP pour les uploader, avec toutes les pertes de temps et les risques de mauvaise manipulation que cela engendre, sans compter la lenteur fréquente des échanges FTP, nous allons déployer le site vers le serveur avec Git.

Principe

Un projet versionné avec Git contient tous les fichiers ET tous les changement qu’ils ont subis. C’est la fonction de base du versionning.

Une fonction de Git très pratique pour nous est le branchement.

Disons que le projet est développé dans la branche MASTER.

Nous y créerons une branche nommée par exemple PRODUCTION dans laquelle nous apporterons les corrections necessaires au portage du projet en ligne, comme par exemple remplacer les logins, mots de passe ou URL codées « en dur » par les variables ou fichiers qui conviennent, la transformation des fichiers SASS en CSS, etc.

Nous pousserons cette branche vers le serveur distant, puis en se connectant en SSH à ce serveur nous effectuerons un merge vers le dossier du site accessible par le Web.

La manipulation en deux temps permet de ne pas déployer vers le site « live » une branche MASTER qui aurait été modifiée entre temps ou par erreur.

Déployer vers un serveur classique de type OVH, 1&1, etc.

Il faut tout d’abord créer un repository vide sur le serveur dans le dossier qui accueillera le site LIVE.

    local$ ssh login@serveur.com
    serveur$ cd dossier/du/projet
    serveur$ git init
    serveur$ exit

Ensuite, si ce n’est pas déjà fait, initialiser le projet local et faire un commit.

    local$ cd dossier/du/projet
    local$ git init && git add . && git commit -m ‘premier commit’

C’est à ce moment-là que nous créons la nouvelle branche destinée à partir sur le serveur.

    local$ git branch deploy

On active la branche :

    local$ git checkout deploy

On déclare le serveur distant comme destination (‘origin’ dans la logique de Git) :

    local$ git remote add origin login@serveur.com:dossier/du/projet

On ‘push’ le contenu du projet (en fait, sa branche nommée ‘deploy’) vers le serveur :

    local$ git push origin deploy

Ensuite on se connecte au serveur et on y merge la branche ‘deploy’ dans la branche ‘master’ (qui était vide jusqu’à présent) :

    local$ ssh login@serveur.com && cd dossier/du/projet
    serveur$ git merge deploy

Et voilà !

Il faut bien entendu que le prestataire de service (l’hébergeur) ait prévu de vous laisser l’accès au serveur en SSH et que vous puissiez y installer Git si ce n’est déjà fait.

N’oubliez pas ensuite de revenir localement à la branche MASTER et de détruire la branche deploy :

    git checkout master
    git branch delete deploy

Par la suite, au fur et à mesure que la branche MASTER du projet avance, à tout instant vous pouvez déployer la version actuelle par cette séquence :

    local$ git add . && git commit -m ‘message’ && git checkout deploy && git push origin deploy
    serveur$ git merge deploy

Vous bénéficiez alors de toute la puissance de Git pour gérer vos versions et vos fichiers et décider de ce qui part en live ou de ce qui reste en local.

Déployer vers HEROKU

Il y a un prestataire d’hébergement dans le ‘cloud’ américain très efficace et qui commence à devenir franchement hype et recommandé par les plus expérimentés : HEROKU.

Le service est payant mais propose une formule gratuite.

Dans cette formule l’espace de stockage est limité et nous n’avons le droit d’utiliser qu’un seul projet mais c’est déjà bien suffisant pour commencer.

Comme c’est un hébergeur spécialisé dans le ‘cloud’ son fonctionnement est différent d’un hébergeur classique.

La principale différence étant qu’on ne peut y déployer qu’une App et pas un simple site statique.

Sur HEROKU, on déploie son App (Ruby et donc Sinatra, Rails, etc, et bien d’autres langages et frameworks supportés) avec l’outil maison en ligne de commande, qui se couple avec Git (qui en est donc obligatoire).

    sudo gem install heroku

Créer une clé SSH dédiée avec votre email si ce n’est pas déjà fait :

    ssh-keygen -t rsa C ‘votremail@votremail.com’

Et déclarer cette clé à Heroku (cette manipulation ne doit être faite que la 1ère fois) :

    heroku keys:add

Un message vous demandera votre email et votre mot de passe Heroku puis l’outil va uploader la clé vers votre compte chez eux.

Ensuite il faut déclarer son application dans un fichier ‘config.ru’. Exemple pour du Ruby/Sinatra :

    require nomdevotreapp
    run Sinatra::Application

On crée un process dans le cloud du nom de l’app :

    heroku create nomdelapp

Et on y déploie notre repository :

    git push heroku master

C’est tout ! Votre app est disponible à l’adresse http://nomdelapp.heroku.com

Par la suite, au fur et à mesure de l’avancée du projet, si vous voulez pousser la version actuelle vers le site live, il suffit de faire :

    git push heroku master

Plutôt cool, non ? Bienvenue dans le monde moderne. ;-)

Auteur: Eric Dejonckheere