Mise en place déploiement via Git

[YannPl]

EN PRATIQUE

Init déploiement step by step

• Se connecter au serveur en ssh
• se placer dans l'équivalent du "www"
  • (Facultatif) Créer un dossier pour le projet
• se placer dans le dossier du projet (ou à la racine du www)
• Cloner la branche voulue du projet parking :
  • "git clone -b mybranch --single-branch https://github.com/Elipce-Informatique/parking.git ."
• Sur le PC de développement, modifier le fichier deploy.sh pour effectuer le pull sur la bonne branche
• Commit la modif de ce fichier et le récupérer sur le serveur via la commande git pull --ff-only origin branch en changeant branch par la bonne branche
• Ajouter le fichier deploy.sh au gitignore via le PC de dev.
• Commit cette modif et la récupérer sur le serveur via la commande git pull --ff-only origin branch
• Passer le fichier deploy.sh en chmod +x sur le serveur

Voilà, normalement tout est prêt pour les mises en prod des updates !

Procédure de développement des mises à jour

• Toujours développer les dev génériques dans le master
• Effectuer des pullRequest sur github dans les branches à mettre à jour.
  • base = branche spécifique ex: p023-annecy
  • compare = branche master
• Se connecter en SSH sur le serveur et lancer le script deploy.sh
• php artisan migrate
• php artisan db:seed

Les développements spécifiques à un parking

• Doivent être développés directement sur la branche du dit parking (Attention à ne pas se tromper dans l'éditeur PHPstorm)
• Si des conflits apparaissent lors de futures pullRequests du master vers la branche modifiée, suivre les instructions de github et régler le conflit via l'interface PHPstorm
• La procédure de déploiement reste la même

Les règles d'or du déploiement !

1. Tous les fichiers de la branche à déployer DOIVENT être copiés sur la cible en production.
2. Les fichiers qui ont été supprimés dans la branche depuis le dernier déploiement doivent être supprimés sur la cible en production.
3. Tout changement des fichiers directement sur le serveur de production depuis le dernier déploiement doivent être ignorés en appliquant les règles 1 et 2. Cependant, on peut souhaiter être prévenu de ces changement lors du prochain déploiement pour éviter de les écraser et prendre des mesures.
4. Les fichiers non suivis par git dans le dossier en production doivent restés inchangés. Encore une fois, on peut souhaiter être prévenu lors du prochain déploiement pour éviter de les écraser ou les supprimer et prendre des mesures.

Les infos en vrac

• Une branche par parking
• Il faut vérifier que toutes les configs soient extérieures au code.
• Tout ce qui touche au spécifique (configs etc...) doivent être dans le gitignore
• Les configs sont modifiées dans leurs branches respectives (Directement via l'interface Github ? ou sur les serveurs de prod une bonne fois pour toute ?)
• On développe dans la branche master tout ce qui est générique à TOUS les projets

Liens utiles

• Argumentation contre le pull to deploy : http://grimoire.ca/git/stop-using-git-pull-to-deploy
• Explication du push to deploy : https://danbarber.me/using-git-for-deployment/