Re: Et donc...

J’avais oublié de revenir par ici. :( Heureusement, les commentaires ne sont pas encore clos.

Commençons par le cas simple que l’on occulte trop facilement... Quand les usagers poussent/tirent vers/depuis une forge, c’est bien par rapport à un dépôt central qui est sur un serveur ;-) Le principe demeure en l’absence de logiciel/programme de forge : les premiers dépôts que j’ai eu à mettre en place auprès d’entreprises qui n’entendaient pas encore les systèmes de version, c’était sur des dossiers partagés de serveurs (car le dépôt de référence peut être donné par un chemin du système, et pas que SSH ou HTTP... et ce n’est pas propre qu’à Git au passage.)

Mais j’imagine (mais j’en sais rien en fait) que la question est par rapport au dépôt de travail (enfin le local du point de vue des usagers de forges, car dans l’absolu rien n’empêche que les dépôts distants ne soient pas aussi des dépôts de travail —il m’est déjà arrivé de travailler ainsi en binôme ou en trinôme quand on n’a pas un serveur où archiver le travail commun.) Là aussi, il n’est pas exclu d’être sur un serveur (par opposition au poste personnel.)
J’ai travaillé dans une entreprise B...... qui a mis en place un système de CI/CD bien avant que n’apparaisse GitLab ou que la fonctionnalité soit fournie sur GitHub (où de toute façon cette entreprise ne peut pas être pour des contraintes juridiques.) Bon, le principe n’a pas beaucoup changé avec les outils/programmes actuels : il faut quand même cloner (ou rapatrier les commits) puis faire la popote indiquée. Dans le cas de cette entreprise B......, on fait juste du déploiement en recette/qualification/production. Je n’ai connu qu’un seul cas où il a fallu intervenir manuellement, ce qui nécessite de savoir utiliser la commande git pour revert sur un tag précis puis relancer manuellement le script de déploiement sur ce tag là. Habituellement, dans les rares cas de rollback, il suffisait de livrer une version corrective par dessus l’ancienne, mais sur ce coup là il a fallu rejouer une ancienne version après avoir nettoyé manuellement les serveurs concernés. Mais je m’éloigne, je voulais juste donner un exemple où il a fallu mettre les mains dans le cambouis et dans l’urgence.
Avant cela, j’ai connu deux entreprises qui utilisent etckeeper et dans la première le dépôt n’était que local au serveur. Bref, là, ça fonctionne bien comme un dépôt de travail sauf que les commits sont faits par un programme (chose que l’on peut retrouver aussi avec des applications personnelles de documentation par exemple) et qu’on est sur un serveur... Cela nous a sauvé la mise suite à certaines mises à jour (et la présence de cet outil m’a permis de faire entendre ma demande de les systématiser...) sauf qu’il faut connaitre la commande git et bien comprendre ce qu’on a configuré. Il n’y a pas que etckeeper et sa surcouche, on peut utiliser d’autres outils comme changetrack ou filemon, etc.
Je dirai que c’est un peu l’équivalent des solutions de dotfiles pour sysadmins, et on a des équivalents pour les netadmins (il y a Rancid et Oxidised que j’ai eu à mettre en œuvre, mais certainement bien d’autres que j’ignore.) Parfois ça peut comprendre ce qu’on a configuré. Il n’y a pas que etckeeper et sa surcouche, on peut utiliser d’autres outils comme changetrack ou filemon, etc.
Je dirai que c’est un peu l’équivalent des solutions de dotfiles pour sysadmins, et on a des équivalents pour les netadmins (il y a Rancid et Oxidised que j’ai eu à mettre en œuvre, mais certainement bien d’autres que j’ignore.) Parfois ça peut aller bien plus loin, comme bup...

Il y a les cas où on a du git sur le serveur mais pas pour y travailler (quoique ce soit parfois possible) ; en gros on y monte le dépôt comme on monterait un chemin réseau sauf qu’on a en prime toutes les versions en cas de besoin. Avec des collègues nous avons fait quelque chose du genre en pointant certains serveurs vers un dépôt Git et lui faire prendre sa recette par Ansible (beaucoup l’ignorent mais ça sait faire du pull, ici via un cron, et pas que du pull qui est le mode par défaut.) C’est un peu le fonctionnement que j’ai rencontré avec Puppet dans d’autres boîtes ; par contre ici, on n’est plus du tout dans le cas de dépôt où l’on commit, mais on a quand même du git sur le serveur.

Il y a certainement d’autres cas que je ne connais pas, et pour ce que je connais j’ai préférer me limiter à des choses auxquelles j’ai touchées. Il y a en tout cas plein de raisons d’avoir un dépôt Git sur un serveur.

"It is seldom that liberty of any kind is lost all at once." ― David Hume