Bonjour,
je sais bien que git n'est pas un outil de déploiement, mais c'est déjà compliqué pour un développeur de comprendre et maitriser un outil comme celui-ci que je ne souhaite pas ajouter une surcouche pour déployer le code sur des environnements de prod. Même très compliqué pour certains...
Je souhaite donc utiliser git et surtout ses hooks pour construire un moyen de déploiement.
Pour l'instant, j'ai fais quelque test à coup de post-receive hook contenant un simple "git checkout", et ça marche bien, pour mettre en prod le développeur n'a qu'a "git push prod".
Je vais essayer de résumer les besoins : - pas de script maison, mais un hook git me convient parfaitement - j'utilise gitolite comme dépôt central (le débat d'avoir un dépôt central ou pas n'est pas le sujet ;) ) - 3 environnements: dev, preprod et prod - donc potentiellement 3 branches (minimum)
c'est là que ça se complique : - on ne peut push en prod que depuis la preprod, ou que si le code de preprod a été testé - on ne peut push en preprod ou prod que "depuis" master
Les questions que je me/vous pose : - est-ce que les branches sont les solutions à cette problématique ? - quels autres moyens existent ils pour déployer en prod via git ?
je ne souhaite pas configurer du multi remote, il y a trop de serveurs et ils "bougent" régulièrement, donc il faudrait reconfigurer chaque "remotes" de chaque développeur ...
Bref comment vous faite ?
Jette un oeil du côté des tags (qui peuvent, par exemple, être signés par le responsable de prod). Point le temps de détailler, mais promis ça fonctionne :)
On 05/15/2013 06:07 PM, Greg wrote:
Bonjour,
je sais bien que git n'est pas un outil de déploiement, mais c'est déjà compliqué pour un développeur de comprendre et maitriser un outil comme celui-ci que je ne souhaite pas ajouter une surcouche pour déployer le code sur des environnements de prod. Même très compliqué pour certains...
Je souhaite donc utiliser git et surtout ses hooks pour construire un moyen de déploiement.
Pour l'instant, j'ai fais quelque test à coup de post-receive hook contenant un simple "git checkout", et ça marche bien, pour mettre en prod le développeur n'a qu'a "git push prod".
Je vais essayer de résumer les besoins :
- pas de script maison, mais un hook git me convient parfaitement
- j'utilise gitolite comme dépôt central (le débat d'avoir un dépôt
central ou pas n'est pas le sujet ;) )
- 3 environnements: dev, preprod et prod
- donc potentiellement 3 branches (minimum)
c'est là que ça se complique :
- on ne peut push en prod que depuis la preprod, ou que si le code de
preprod a été testé
- on ne peut push en preprod ou prod que "depuis" master
Les questions que je me/vous pose :
- est-ce que les branches sont les solutions à cette problématique ?
- quels autres moyens existent ils pour déployer en prod via git ?
je ne souhaite pas configurer du multi remote, il y a trop de serveurs et ils "bougent" régulièrement, donc il faudrait reconfigurer chaque "remotes" de chaque développeur ...
Bref comment vous faite ?
Greg
Liste de diffusion du FRsAG http://www.frsag.org/
Le 15/05/2013 18:13, Pierre Jaury a écrit :
Jette un oeil du côté des tags (qui peuvent, par exemple, être signés par le responsable de prod). Point le temps de détailler, mais promis ça fonctionne :)
Salut Greg,
J'allais répondre pareil, on export pas une branche mais un tag qui correspond à une release de ton logiciel. Je faisais cela à partir d'un svn, je passais par un script que les dev lançait avec le tag svn qui doit être livré, rollback au tag précédent en cas de soucis et surtout plein d'actions annexe comme re minifier / combiner les js et css, faire des actions en bases, ...
Et Gitolite un retour dessus?
Perso je suis pas passé à Git à cause de la non centralisation inhérente à Git (pratique pour des trucs open source, juste impensable pour du closed source), du coup le fait que tu centralises à Git m'intéresse si tu pouvais en parle plus.
++
Bonjour,
Le 15 mai 2013 à 19:21, Wallace wallace@morkitu.org a écrit :
Perso je suis pas passé à Git à cause de la non centralisation inhérente à Git (pratique pour des trucs open source, juste impensable pour du closed source), du coup le fait que tu centralises à Git m'intéresse si tu pouvais en parle plus.
De ce point de vue git fait ce qu'on lui demande. Si tu demandes à tes devs de n'utiliser qu'un seul upstream tu as une architecture centralisée avec git. Par contre empêcher des développeurs d'avoir des branches locales par pure doctrine c'est juste les empêcher de travailler. Derrière ils vont contourner le problème pour pouvoir garder un environnement local qui leur correspond, ou encore régler les problèmes causés par subversion lui-même (qui est un outil de versioning antédiluvien), et ils vont perdre du temps à faire tout ça au lieu de faire des choses utiles.
Je ne comprends pas en quoi du closed source impose la centralisation. Que tu fasses du closed-source ou de l'open-source tu seras obligé en tant que développeur: * de tester tes modifs avant de les pousser sur le dépôt central * de maintenir des modifications non-terminées en local parce que tu dois pipeliner entre plusieurs tâches (oh ! une demande de bugfix ultra-prioritaire qui arrive !) * de te préserver un environnement custom en local pour le déboggage de ta partie du code Tout ce que tu ne peux pas faire (facilement) avec svn.
Cordialement. Emmanuel Thierry
Le 15/05/2013 19:38, Emmanuel Thierry a écrit :
De ce point de vue git fait ce qu'on lui demande. Si tu demandes à tes devs de n'utiliser qu'un seul upstream tu as une architecture centralisée avec git. Par contre empêcher des développeurs d'avoir des branches locales par pure doctrine c'est juste les empêcher de travailler. Derrière ils vont contourner le problème pour pouvoir garder un environnement local qui leur correspond, ou encore régler les problèmes causés par subversion lui-même (qui est un outil de versioning antédiluvien), et ils vont perdre du temps à faire tout ça au lieu de faire des choses utiles.
Je ne comprends pas en quoi du closed source impose la centralisation. Que tu fasses du closed-source ou de l'open-source tu seras obligé en tant que développeur:
- de tester tes modifs avant de les pousser sur le dépôt central
- de maintenir des modifications non-terminées en local parce que tu dois pipeliner entre plusieurs tâches (oh ! une demande de bugfix ultra-prioritaire qui arrive !)
- de te préserver un environnement custom en local pour le déboggage de ta partie du code
Tout ce que tu ne peux pas faire (facilement) avec svn.
Je comprend ce point de vue en tant que développeur, mais le côté sysadm fait qu'au contraire tu n'as pas à tester sur ton poste en local mais tu dois utiliser un environnement de dev / recette / preprod conforme à la prod. Après que tu passes par de la virtualisation ou du vhost par développeur pour être suffisament isolé et pas être impacté par les modifs en cours des voisins, c'est à voir mais c'est pas au dev de faire des environnements de test. J'ai suffisamment donné depuis 10 ans à entendre c'est pas ma faute ça marche sur mon poste, c'est la prod qui est pas bien réglé. Sauf que les contraintes de sécurités entre la prod et son poste perso sont pas les même.
Bref la centralisation vient de là principalement. Svn n'est pas si obsolète que cela, au quotidien il n'y a pas de différence à mon sens et niveau.
Par contre le cas de devoir faire plusieurs branches et devoir les resynchroniser j'ai pas vu un seul client qui se dit pourtant Agile ne pas perdre un temps fou là dessus. Alors que structurer les demandes release par release et que tout le monde se concentre sur les points définis c'est tellement plus stable dans le temps. Enfin c'est mon ressenti dans l'encadrement, l'hébergement et l'infogérance de clients type Agile. J'en ait deux qui font des releases plusieurs fois par jour, chaque release contient les tâches nécessaires à l'obtention d'un élément urgent ou évolution. Tous les dev bossent ensemble en même temps sur les tâches à faire (découper en des éléments super simples). Et avec eux j'ai aucun souci, stabilité de l'application à toute épreuve, aucun rollback fait.
A voir donc, autant Git pour kernel je comprend même si j'aimerais voir comment les mainteneurs arrivent à récupérer et merger autant de branches différentes tout en maintenant une stabilité et la gestion des dépendances. Mais là c'est un autre niveau de dev et puis l'outils a été codé pour eux et ils ont pas de commerciaux ou marketeux pour les perturber dans leur travaux, ça compte énormément aussi.
Le 16 mai 2013 à 00:56, Wallace wallace@morkitu.org a écrit :
Le 15/05/2013 19:38, Emmanuel Thierry a écrit :
De ce point de vue git fait ce qu'on lui demande. Si tu demandes à tes devs de n'utiliser qu'un seul upstream tu as une architecture centralisée avec git. Par contre empêcher des développeurs d'avoir des branches locales par pure doctrine c'est juste les empêcher de travailler. Derrière ils vont contourner le problème pour pouvoir garder un environnement local qui leur correspond, ou encore régler les problèmes causés par subversion lui-même (qui est un outil de versioning antédiluvien), et ils vont perdre du temps à faire tout ça au lieu de faire des choses utiles.
Je ne comprends pas en quoi du closed source impose la centralisation. Que tu fasses du closed-source ou de l'open-source tu seras obligé en tant que développeur:
- de tester tes modifs avant de les pousser sur le dépôt central
- de maintenir des modifications non-terminées en local parce que tu dois pipeliner entre plusieurs tâches (oh ! une demande de bugfix ultra-prioritaire qui arrive !)
- de te préserver un environnement custom en local pour le déboggage de ta partie du code
Tout ce que tu ne peux pas faire (facilement) avec svn.
Je comprend ce point de vue en tant que développeur, mais le côté sysadm fait qu'au contraire tu n'as pas à tester sur ton poste en local mais tu dois utiliser un environnement de dev / recette / preprod conforme à la prod. Après que tu passes par de la virtualisation ou du vhost par développeur pour être suffisament isolé et pas être impacté par les modifs en cours des voisins, c'est à voir mais c'est pas au dev de faire des environnements de test. J'ai suffisamment donné depuis 10 ans à entendre c'est pas ma faute ça marche sur mon poste, c'est la prod qui est pas bien réglé. Sauf que les contraintes de sécurités entre la prod et son poste perso sont pas les même.
Alors si je suis un développeur ça te dérangera pas que je déploie un gdb sur le kernel de l'environnement de test pour faire du pas à pas sur la pile IPv6 ? :P (bon, j'admets en plus que tu as déjà répondu à ce point plus bas ! ;)) Bon, ceci dit, même pour du code plus courant, par exemple du code PHP, tu veux pouvoir lancer des outils de debug pour dumper/modifier facilement les variables sans avoir à ajouter un var_dump(), commiter, attendre que le serveur récupère le code, et voir le résultat. En tant que développeur, je considère qu'il faut de la souplesse pour pouvoir travailler, quitte à perdre un peu de temps à se resynchroniser avec tout le monde avant de faire une release.
Bref la centralisation vient de là principalement. Svn n'est pas si obsolète que cela, au quotidien il n'y a pas de différence à mon sens et niveau.
Disons que une fois que tu as touché à git, tu ne peux plus t'en passer… :)
Par contre le cas de devoir faire plusieurs branches et devoir les resynchroniser j'ai pas vu un seul client qui se dit pourtant Agile ne pas perdre un temps fou là dessus. Alors que structurer les demandes release par release et que tout le monde se concentre sur les points définis c'est tellement plus stable dans le temps. Enfin c'est mon ressenti dans l'encadrement, l'hébergement et l'infogérance de clients type Agile. J'en ait deux qui font des releases plusieurs fois par jour, chaque release contient les tâches nécessaires à l'obtention d'un élément urgent ou évolution. Tous les dev bossent ensemble en même temps sur les tâches à faire (découper en des éléments super simples). Et avec eux j'ai aucun souci, stabilité de l'application à toute épreuve, aucun rollback fait.
J'admets que cela dépend de beaucoup de paramètres: * Le type de développements (custom pour un client, ou bien produit sur étagère) * La durée des échéances (quelques heures à plusieurs mois) * La méthodologie de gestion de projet (agile ou "classique") * L'architecture du projet (monolithique ou modulaire)
A voir donc, autant Git pour kernel je comprend même si j'aimerais voir comment les mainteneurs arrivent à récupérer et merger autant de branches différentes tout en maintenant une stabilité et la gestion des dépendances. Mais là c'est un autre niveau de dev et puis l'outils a été codé pour eux et ils ont pas de commerciaux ou marketeux pour les perturber dans leur travaux, ça compte énormément aussi.
Disons que à ce que je comprends git est *très* utile pour des projets qui durent dans le temps, où il faudra gérer de front la situation courante (bugfixes à apporter dans différentes versions), et les développements à venir (améliorations). Egalement sur des projets modulaires où un module est délégué à une personne ou un groupe de personnes, avec quelqu'un qui sera considéré comme responsable de cette brique et rapportera toutes les modifications sur cette brique à l'entité centrale, etc.
Ceci dit, comme je le disais, tu peux décider de l'utiliser de manière totalement centralisée et synchrone (en passant la consigne aux développeurs), il gardera son intérêt (taille du dépôt, capacités d'historique et de recherche, possibilités de rebase, …)
Cordialement Emmanuel Thierry
Le 16/05/2013 01:41, Emmanuel Thierry a écrit :
Alors si je suis un développeur ça te dérangera pas que je déploie un gdb sur le kernel de l'environnement de test pour faire du pas à pas sur la pile IPv6 ? :P (bon, j'admets en plus que tu as déjà répondu à ce point plus bas ! ;)) Bon, ceci dit, même pour du code plus courant, par exemple du code PHP, tu veux pouvoir lancer des outils de debug pour dumper/modifier facilement les variables sans avoir à ajouter un var_dump(), commiter, attendre que le serveur récupère le code, et voir le résultat. En tant que développeur, je considère qu'il faut de la souplesse pour pouvoir travailler, quitte à perdre un peu de temps à se resynchroniser avec tout le monde avant de faire une release.
Si tu en viens à debuger du kernel on sort quand même des usages de 90% voir plus des développements de tous les jours dans les entreprises qui vont faire du php, du java pour leurs intérêts. Dans le cas du kernel ou de module ou éléments qui doivent le cotoyer en symbiose là au contraire c'est plutôt testez sur les machines que vous voulez il faut que cela marche à tous les coups.
A voir donc, autant Git pour kernel je comprend même si j'aimerais voir comment les mainteneurs arrivent à récupérer et merger autant de branches différentes tout en maintenant une stabilité et la gestion des dépendances. Mais là c'est un autre niveau de dev et puis l'outils a été codé pour eux et ils ont pas de commerciaux ou marketeux pour les perturber dans leur travaux, ça compte énormément aussi.
Disons que à ce que je comprends git est *très* utile pour des projets qui durent dans le temps, où il faudra gérer de front la situation courante (bugfixes à apporter dans différentes versions), et les développements à venir (améliorations). Egalement sur des projets modulaires où un module est délégué à une personne ou un groupe de personnes, avec quelqu'un qui sera considéré comme responsable de cette brique et rapportera toutes les modifications sur cette brique à l'entité centrale, etc.
Ceci dit, comme je le disais, tu peux décider de l'utiliser de manière totalement centralisée et synchrone (en passant la consigne aux développeurs), il gardera son intérêt (taille du dépôt, capacités d'historique et de recherche, possibilités de rebase, …)
A voir de toute façon il faudra bien que j'y passe pour remplacer subversion qui est de plus en plus abandonné, l'informatique évolue et il faut suivre les tendances c'est comme ça. Par contre si vous avez des urls à passer sur une exploitation de git centralisé ou même des retours d'expériences ça m'intéresse de voir comment ça fonctionne dans la logique.
Wallace wallace@morkitu.org writes:
[...]
A voir de toute façon il faudra bien que j'y passe pour remplacer subversion qui est de plus en plus abandonné, l'informatique évolue et il faut suivre les tendances c'est comme ça.
Y'a des tendances qui ont la vie dure. La plupart de mes collègues encore étudiants ou fraîchement diplômés n'ont utilisé que svn, soit de leur propre chef, soit parce que c'est le seul vcs qu'on les a forcé à utiliser dans leurs formations (et encore, ça c'est quand ils en ont vu un).
D'un autre côté svn n'est pas mort au niveau développement, la version 1.8 sort (normalement) dans un mois et y'a une -rc2 dispo.
Par contre si vous avez des urls à passer sur une exploitation de git centralisé ou même des retours d'expériences ça m'intéresse de voir comment ça fonctionne dans la logique.
Pas au niveau "pro", mais chez Faimaison[1] on utilise Git conjointement à gitolite, dans une architecture centralisée donc. Ça va de l'utilisateur avancé qui va utiliser des branches locales et remote, à d'autres qui ne travaillent que sur la branche master.
Au niveau gitolite, quelques éléments à propos de notre utilisation : - pas besoin de compte unix par utilisateur, un seul compte utilisé uniquement par gitolite - groupes d'utilisateurs (pour déterminer qui accède à quel dépôt ; la granularité peut descendre au niveau des tags et / ou des branches. - clés SSH multiples pour certains utilisateurs - réplication 1 master -> 2 slave : - un push sur un slave redirige de manière transparente sur le master - si le master tombe on a toujours accès en lecture sur les slave ; un changement dans la conf gitoite + entrée dns et les utilisateurs ne voient (presque rien) - hooks pour des mails automatiques (non spécifique gitolite) - on envisage aussi d'utiliser ces hooks pour déployer automatiquement (site web, etc - non spécifique gitolite) - on utilise des versions stables de gitolite, directement depuis l'upstream, pour parer à d'éventuelles incompatibilités entre les versions de gitolite packagées sur les distros supports.
C'est pas grand chose, mais ça va déjà plus loin que ce que j'ai pu voir jusqu'à présent dans un contexte "pro" avec du svn.
Le 17/05/2013 18:30, Jérémie Courrèges-Anglas a écrit :
Wallace wallace@morkitu.org writes:
[...]
A voir de toute façon il faudra bien que j'y passe pour remplacer subversion qui est de plus en plus abandonné, l'informatique évolue et il faut suivre les tendances c'est comme ça.
Y'a des tendances qui ont la vie dure. La plupart de mes collègues encore étudiants ou fraîchement diplômés n'ont utilisé que svn, soit de leur propre chef, soit parce que c'est le seul vcs qu'on les a forcé à utiliser dans leurs formations (et encore, ça c'est quand ils en ont vu un).
J'avais appris csv en 2000 c'était déjà pas mal de migrer sur subversion le gap de fonctionnalité me suffisait en fait :) Va falloir se remettre en question (même si c'est proche). C'est vrai que le côté centralisé rassure en fait, le côté éclaté (même si je sais que cela marche) me laisse l'idée que potentiellement un boulot peut être sur un ordi qui va crasher son disque quand son backup est pas synchro ou qu'il n'y en a pas. J'ai dans ma vie en tant que salarié avant d'être patron jamais vu de sauvegarde de poste des employés. Ca aide pas à vouloir proposer un repo décentralisé.
D'un autre côté svn n'est pas mort au niveau développement, la version 1.8 sort (normalement) dans un mois et y'a une -rc2 dispo.
Oui c'est vrai mais l'effet de mode et l'utilisation en masse va faire que git va prendre le dessus. SVN est utilisé en entreprise car ils migrent pas de dépôt tous les 4 matins. Il faut donc bien le faire évoluer pour qu'il colle aux distros modernes et corrige des bugs.
Par contre si vous avez des urls à passer sur une exploitation de git centralisé ou même des retours d'expériences ça m'intéresse de voir comment ça fonctionne dans la logique.
Pas au niveau "pro", mais chez Faimaison[1] on utilise Git conjointement à gitolite, dans une architecture centralisée donc. Ça va de l'utilisateur avancé qui va utiliser des branches locales et remote, à d'autres qui ne travaillent que sur la branche master.
Au niveau gitolite, quelques éléments à propos de notre utilisation :
- pas besoin de compte unix par utilisateur, un seul compte utilisé uniquement par gitolite
- groupes d'utilisateurs (pour déterminer qui accède à quel dépôt ; la granularité peut descendre au niveau des tags et / ou des branches.
- clés SSH multiples pour certains utilisateurs
- réplication 1 master -> 2 slave :
- un push sur un slave redirige de manière transparente sur le master
- si le master tombe on a toujours accès en lecture sur les slave ; un changement dans la conf gitoite + entrée dns et les utilisateurs ne voient (presque rien)
- hooks pour des mails automatiques (non spécifique gitolite)
- on envisage aussi d'utiliser ces hooks pour déployer automatiquement (site web, etc - non spécifique gitolite)
- on utilise des versions stables de gitolite, directement depuis l'upstream, pour parer à d'éventuelles incompatibilités entre les versions de gitolite packagées sur les distros supports.
C'est pas grand chose, mais ça va déjà plus loin que ce que j'ai pu voir jusqu'à présent dans un contexte "pro" avec du svn.
Intéressant, le coup du compte ssh unique me soulage car il me semble avoir vu que des implémentations avec compte / user ce qui peu être long à gérer à force. La réplication par contre faut que je regarde ce qu'on peut faire, je n'étais pas encore arrivé à ce niveau là dans la réflexion. Une VPS bien sauvegardée capable d'être restaurée intégralement rapidement c'est pas mal aussi dans un premier temps.
Wallace wallace@morkitu.org : [...]
C'est vrai que le côté centralisé rassure en fait, le côté éclaté (même si je sais que cela marche) me laisse l'idée que potentiellement un boulot peut être sur un ordi qui va crasher son disque quand son backup est pas synchro ou qu'il n'y en a pas. J'ai dans ma vie en tant que salarié avant d'être patron jamais vu de sauvegarde de poste des employés. Ca aide pas à vouloir proposer un repo décentralisé.
On peut dire "duplication" plutôt que "décentralisation" si ça doit rassurer :o)
[...]
La réplication par contre faut que je regarde ce qu'on peut faire, je n'étais pas encore arrivé à ce niveau là dans la réflexion.
La réplication est littéralement native dans git: dès qu'on clone un dépôt (central ou non), on dispose d'une copie intégrale de son contenu et de toute son histoire.
A la limite, si le serveur du dépôt central explose, rien n'interdit de pivoter vers le dépôt d'un développeur ou de le cloner en guise de restauration.
Le 16 mai 2013 00:56, "Wallace" wallace@morkitu.org a écrit :
Je comprend ce point de vue en tant que développeur, mais le côté sysadm fait qu'au contraire tu n'as pas à tester sur ton poste en local mais tu dois utiliser un environnement de dev / recette / preprod conforme à la prod.
Mais ça existe vraiment ça ?
J'ai suffisamment donné depuis 10 ans à entendre c'est pas ma faute ça marche sur mon poste, c'est la prod qui est pas bien réglé. Sauf que les contraintes de sécurités entre la prod et son poste perso sont pas les
même.
Certes, parfois c'est le code, parfois c'est l'infra.
Par contre le cas de devoir faire plusieurs branches et devoir les resynchroniser j'ai pas vu un seul client qui se dit pourtant Agile ne pas perdre un temps fou là dessus.
Bah agile et cloud, même combat ? Y a ceux qui disent l'être et ceux qui le sont...
Alors que structurer les demandes release par release et que tout le monde se concentre sur les points définis c'est tellement plus stable dans le temps.
Les deux ne sont pas incompatibles.
Le 16/05/2013 02:04, seb astien a écrit :
Le 16 mai 2013 00:56, "Wallace" <wallace@morkitu.org mailto:wallace@morkitu.org> a écrit :
Je comprend ce point de vue en tant que développeur, mais le côté sysadm fait qu'au contraire tu n'as pas à tester sur ton poste en local mais tu dois utiliser un environnement de dev / recette / preprod conforme à la prod.
Mais ça existe vraiment ça ?
Oui et heureusement, soit le client a des environnements étanches (plate-formes séparées) pour les gros projets soit on met sur le même serveur (celui de prod) les versions dev et preprod avec une limitation drastiques des ressources disponibles à l'instance dev pour éviter de saturer le serveur de prod à cause d'une erreur. Ca je le fais pour mes petits clients.
Quand je dis que c'est un environnement de dev, j'impose pas qu'il y ait des livraisons pour intégrer en dev, les dev se connectent à une url commune ou à une url par développeur (ça dépend des projets) et peuvent éditer et commiter sur place (vim / emacs / branchement de leurs ide en sftp) et tester en temps réel comme si c'était sur leur poste.
J'ai suffisamment donné depuis 10 ans à entendre c'est pas ma faute ça
marche sur mon poste, c'est la prod qui est pas bien réglé. Sauf que les contraintes de sécurités entre la prod et son poste perso sont pas
les même.
Certes, parfois c'est le code, parfois c'est l'infra.
Pour nos clients, je n'ai jamais entendu parlé d'un souci lié à l'infra, même les webagency qui ont commencé à bosser de leur côté on les force à venir dev sur le serveur du client et tout le monde est ravi.
Par contre le cas de devoir faire plusieurs branches et devoir les resynchroniser j'ai pas vu un seul client qui se dit pourtant Agile ne pas perdre un temps fou là dessus.
Bah agile et cloud, même combat ? Y a ceux qui disent l'être et ceux qui le sont...
Ben là ils sont totalement aglie mais ils perdent un nombre de jour homme halucinant pour merger les branches, alors ils perdent ce qu'ils gagnent avec agile à mon sens.
Gitolite est un outil comme je les aime : un mixe de scripts Perl utilisant la commande Git et les hooks, SSH pour l'authentification... C'est tellement simple et à la fois permet tant de configuration ! Perso j'adore. Comparé au serveur subversion + apache2/webdav y'a un monde...
Cerise sur le gateau, ça oblige les développeurs à se mettre à SSH, configurer leur agent correctement. Ils montent en compétence et en souplesse, et du coup se mettent d'eux-même à se faire des scripts perso.
Bon là je suis en train de former un... intégrateur ? Bref un dev qui fait du HTML/CSS sous Dreamweaver (oui il y en a encore...) et pousse en FTP. Y'a du boulot, mais ça à l'air de lui plaire.
Il faut forcément passer par des restrictions techniques, sinon on en a forcément un qui va un jour pousser en prod directement et foutre le bordel. Même s'il se fait gronder ce sera à moi de récupérer.
La mise en place de tags implique des releases, ce que notre gestion de projet ne permet pas actuellement. Déjà que je ne sais pas comment ça va se passer concrètement... Même si aujourd'hui Git a les outils pour gérer cette situation, les devs vont devoir quand même vachement jongler entre les branches.
Pour illustrer, actuellement un sprint dure 2 semaines. Mais il y a tellement de bugs et de demandes de features urgentes, que le sprint finit par durer 1 mois ... Aujourd'hui avec SVN, ils modifient 3 fichiers et les poussent en prod directement, mais ils peuvent pousser que ces 3 fichiers. Pas besoin de branches, tags, etc... Donc ça va leur faire tout drôle ! Avec Git on ne peut pas pousser 1 fichier, on pousse un snapshot !
Bref on va bien se marrer :)
Le 15 mai 2013 19:21, Wallace wallace@morkitu.org a écrit :
Le 15/05/2013 18:13, Pierre Jaury a écrit :
Jette un oeil du côté des tags (qui peuvent, par exemple, être signés par le responsable de prod). Point le temps de détailler, mais promis ça fonctionne :)
Salut Greg,
J'allais répondre pareil, on export pas une branche mais un tag qui correspond à une release de ton logiciel. Je faisais cela à partir d'un svn, je passais par un script que les dev lançait avec le tag svn qui doit être livré, rollback au tag précédent en cas de soucis et surtout plein d'actions annexe comme re minifier / combiner les js et css, faire des actions en bases, ...
Et Gitolite un retour dessus?
Perso je suis pas passé à Git à cause de la non centralisation inhérente à Git (pratique pour des trucs open source, juste impensable pour du closed source), du coup le fait que tu centralises à Git m'intéresse si tu pouvais en parle plus.
++
Liste de diffusion du FRsAG http://www.frsag.org/
La mise en place de tags implique des releases
Absolument pas : un tag est une simple référence interne pour Git et l'opération de création de tag est d'une simplicité enfantine. Les tags peuvent donc être utilisés pour marquer les releases majeures d'un logiciel aussi bien que les mises en production d'un outil interne. Ils ne sont au fond pas si différent des branches (c'est au final juste un label ajouté sur un changeset), mais sont sémantiquement beaucoup plus adaptés à ton problème (signature du tag validée dans le process de mise en prod pour gérer les permissions, etc.)
Salut,
Les devs ont des branches qu'ils mergent régulièrement avec master, on tag lorsqu'on souhaite déployer et que ça passe les tests.
Je faisais cela à partir d'un svn, je passais par un script que les dev lançait avec le tag svn qui doit être livré, rollback au tag précédent en cas de soucis et surtout plein d'actions annexe comme re minifier / combiner les js et css, faire des actions en bases, ...
On déploie avec un fabric qui git checkout du tag sur plusieurs vms, migrate, css... Hook new relic
Facile de revert, et garantie que le code déployé est le même partout.
Salut,
Ici le comportement est similaire : on a des branches dev/recette-XXX/master qui sont buildées et testées à chaque commit par jenkins et déployées par fabric à chaque build+tests OK.
La branche master se déploie sur la preprod toute seul donc ; et pour certains projets même (pas les plus critiques) en prod dans la foulée si le deploy s'est bien passé.
Depuis qu'on a ce fonctionnement on est plutôt robuste sans être contraignant : les devs savent que X minutes après le commit sur un projet et une branche donnée, ça sera déployé sur l'environnement d'intégration correspondant.
Pour résumer on ne déploie pas directement en post-hook git mais après build+test sur jenkins qui lui est post-hooké au git.
Les reverts sont aussi possibles immédiatement car tout nos builds fabriquent un livrable .tgz qui est archivé sur le serveur qui gère les déploiements.
A+ Valentin
On 16/05/2013 00:55, seb astien wrote:
Salut,
Les devs ont des branches qu'ils mergent régulièrement avec master, on tag lorsqu'on souhaite déployer et que ça passe les tests.
Je faisais cela à partir d'un svn, je passais par un script que les dev lançait avec le tag svn qui doit être livré, rollback au tag précédent en cas de soucis et surtout plein d'actions annexe comme re minifier / combiner les js et css, faire des actions en bases, ...
On déploie avec un fabric qui git checkout du tag sur plusieurs vms, migrate, css... Hook new relic
Facile de revert, et garantie que le code déployé est le même partout.
Liste de diffusion du FRsAG http://www.frsag.org/
Le 16/05/2013 10:57, Valentin Surrel a écrit :
Salut,
Ici le comportement est similaire : on a des branches dev/recette-XXX/master qui sont buildées et testées à chaque commit par jenkins et déployées par fabric à chaque build+tests OK.
La branche master se déploie sur la preprod toute seul donc ; et pour certains projets même (pas les plus critiques) en prod dans la foulée si le deploy s'est bien passé.
Depuis qu'on a ce fonctionnement on est plutôt robuste sans être contraignant : les devs savent que X minutes après le commit sur un projet et une branche donnée, ça sera déployé sur l'environnement d'intégration correspondant.
Pour résumer on ne déploie pas directement en post-hook git mais après build+test sur jenkins qui lui est post-hooké au git.
Les reverts sont aussi possibles immédiatement car tout nos builds fabriquent un livrable .tgz qui est archivé sur le serveur qui gère les déploiements.
C'est clairement la meilleure solution mais ce n'est malheureusement pas déployé sur tous les projets et c'est dommage.
Bonsoir,
Greg greg-frsag@duchatelet.net : [...]
Bref comment vous faite ?
Plutôt le contraire: - des tags (immuables) et non des branches (éphémères) pour identifier le code - des remotes (dev, preprod, prod) - des différences d'environnement explicitées dans des fichiers différents - du script maison derrière le hook - du pull (--ff-only, en local) pour le déploiement (+ reset --hard)
-
Emmanuel Thierry -
Francois Romieu -
Greg -
jca+frsag＠wxcvbn.org -
Pierre Jaury -
seb astien -
Valentin Surrel -
Wallace