Bonjour,

j'aurais besoin de renseignement. Je dois trouver un moyen de déployer une appli sur un serveur de production. Pour versionner tout cela, je compte utiliser GIT, cependant j'ai un gros problème à cause des dépendances SQL (trigger, vue, etc...). J'ai entendu parler des hooks qui me permettraient de gérer ces dépendances cependant je me pose des questions au niveau du déploiement.
Pour déployer, j'utiliserais soit Rsync, soit GIT, je ne sais pas quelle solution serait la meilleure.
Est-ce que l'ordre des pré commit est conservé une fois le commit terminé ?
Est-ce que GIT garde la trace de l'ordre des commits ?

Pouvez-vous m'aider s'il vous plaît ?

Git garde la trace des commits, c'est-à-dire que tu peux revenir à l'état actuel de n'importe quel commit par la suite. Mais qu'entends-tu par "ordre des pré commit" ? Git, basiquement, stocke les fichiers et permet de les retélécharger. Tout ça automatisé bien sûr mais à la base c'est ce qui est fait. Donc je vois pas trop ce que tu veux que ça fasse d'autre.

Je dois gérer des dépendances SQL et c'est ça qui pose problème. Je ne sais pas si en déployant les modifications de la bdd, je garderais les dépendances (trigger, vues, etc).
Je sais que pour garder ces dépendances, je dois d'abord déployer la structure de la table puis ensuite les données et ça me permettrait d'éviter les conflit cependant je ne sais pas si cela est faisable.

personnellement, je suis toujours un peu inquiet lorsque les procedure de mises a jours sont automatise. Garder le code dasn git et s'en servir sur la machine de prod pour recuperer la derniere vesion de production, pourquoi pas. Mais lancer automatiquement des scripts de mise a jour qui change les structures d'une base de donnee, ca me semble fou.

Je sais pas comment se présente un fichier de base de données mais je pense que les conflits vont vite devenir un enfer à gérer (git rajoute des lignes dans les fichiers ou il y a des conflits).

Probablement il ne faut pas mettre la base de donnee dans le repository git. eventuellement en annexe, mais pas dans le repository en lui meme.

Pour répondre à cette problématique, nous nous appuyons sur un ORM avec un mapping en XML/Yaml de la base de données. Quand on déploie une version, que soit un upgrade ou un downgrade, nous avons une commande migration qui compare la base de donnée courante et le mapping du projet. Cette commande de migration génère un diff sous forme de requêtes SQL (alter table, create table, etc.) que nous exécutons par la suite.