Bonjour,
Il y a plusieurs pistes de réponses à ta question, mais l'idéal est
effectivement d'utiliser git en tirant partie des utilisateurs. Pour
simplifier les choses (droits, déploiement, issues) il vaut mieux
utiliser une forge (par exemple gitlab
https://about.gitlab.com/, qui
est libre contrairement à github).
Je fait une réponse plus détaillé dans ton mail
Le 23/01/2019 à 10:06, Nicolas Ecarnot a écrit :
> Bonjour, > > Je sollicite votre avis sur une méthode, sachant qu'il n'y a ni
panne ni problème, mais plutôt une volonté d'amélioration. > > Au
boulot, on maîtrise difficilement git, car nous sommes plutôt des
sysadmins que des codeurs. > On utilise un peu les notions de branches
et de versions, mais presque jamais de notions de concurrence et aucun
merge ne remonte d'erreur.
Un tuto sympa pour comprendre les principes git :
https://learngitbranching.js.org/
>> L'un de nos serveurs contient un ensemble de fichiers qu'on modifie,
puis des scripts les testent, les parsent, puis ils sont déployés vers
d'autres serveurs. > > Actuellement, une gestion très basique de git sur
cet ensemble de fichiers permet simplement de versionner et de garder
une trace des raisons des changements. > Mais on travaille tous en local
(et avec le même user) sur un seul répertoire, et aucune collision ne
survient (car les modifs sont peu nombreuses, quoi que quotidiennes). >
Concrètement, les collègues font des modifs, et vu que je suis le seul à
piger un peu git, c'est moi qui réalise les add/commit/push en ajoutant
les commentaires. > > J'aimerais qu'on travaille tous dans nos propres
répertoires, que chacun se mette à utiliser git. On y gagnerait de
connaître l'auteur des modifs, et chacun gagnerait en autonomie. >
Chacun pourrait travailler dans son /home/x et effectuer un push vers
origin/master. > J'ai cru comprendre (par exemple chez github) que la
philosophie habituelle était plutôt dans l'autre sens (corrigez-moi si
je me goure, mais il me semble que les gens sont encouragés à faire un
fork, modifier, puis envoyer un pull request, et le mainteneur central
de master accepte ou pas de faire un merge... ?) > Chez nous, je ne
souhaite pas que quelqu'un soit obligé de merger en central, et c'est
pourquoi je préférerais que tout le monde ait le droit de pousser
(est-ce une bonne idée ?).
En général dans git, la branche master est la principale seul les
responsables peuvent y écrire. Les différents développeurs travaillent
sur des branches par issue, fonctionnalité ou des branches personnelles,
puis font des demandes de merge sur la master.
Chez Github et Gitlab le principe est que les contributeurs externe
fork et font des demandes de Merge request.
Voici un article long détaillant ce mode de fonctionnement :
https://nvie.com/posts/a-successful-git-branching-model/
Ces derniers temps pas mal de gens remettent en question cette
organisation et proposent un travail dans l'autre sens : la master sert
au développement et on fait des banches de release. Cela simplifie un
peu l'organisation, cf cet article :
https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/
>> Enfin, ce qui manque dans ce circuit, c'est l'action de déploiement.
> Actuellement, une fois que les modifs sont réalisées, l'utilisateur
appelle un script de déploiement. > Il me faudrait trouver une idée pour
qu'un process - régulièrement - réalise un pull, puis appelle ce script
de déploiement. Je peux mettre ça dans un cron, mais j'ai la sensation
de passer à côté des méthodes basiques que j'ignore dans l'usage de git.
>> D'où ce message. >
Le déploiement continue c'est plus le boulot de la forge que de git,
Gitlab est particulièrement bon pour ça !
En très résumé dans Gitlab on peut :
+ Définir des clef ssh pour le Déploiement / intégration continue
+ Faire un fichier .yml qui organise compilation, test et déploiement du
projet
+ Restreindre certaines phase (notamment le déploiement) aux push sur
certaines branches
+ Utiliser des images docker pour l'intégration continue
Voici la documentation Gitlab sur l'intégration / Déploiement continue :
https://docs.gitlab.com/ce/ci/README.html
J'espère que cette explication n'est pas trop fouillis !
David
