salut a tous,

la question est dans le titre : comment gérez vous les release des vos applications PHP ?

bien entendu je sais faire une archive de mon poste et modifier un numéro dans une page mais ce qui m'intéresse c'est une "vrai" solution industrielle dans une démarche d'intégration continue. (en clair le code est sur SVN, un jenkins qui build régulièrement et déploie sur des serveurs de dev / intégration + la gestion de release).

Quelque chose similaire à ce qui existe pour java avec maven pourrait m'aller (jenkins + maven + nexus).

Merci d'avance


@+

Une solution peut être un peu ancienne, mais qui fonctionne bien et a fait ses preuves : CPOLD

"pas assez cher mon fils"

trop simple et trop d'interaction humaine.

Un chose plus proche de l'utilisation d'un repos "nexus" maven m'interesse.

le but c'est que la partie dev puisse faire sont taff avec subversion, quand ça roule et tout le monde est ok on "crée" la version x.x.x (avec jenkins) et cette version est archivée.
Celle ci est récupérable par le service qui fait les mises en prod (genre stagiaire qui ne sais pas faire un tar) le tous avec le moins d'interaction humaine sur les fichiers histoire d'éviter les emmerdes et de palier les impetances de certain .

en gros l'outils doit gérer la numérotation et la publication sur un serveur centralisé quelconque (la création de la version se fait a partir de svn).

Merci

@+

Tu t'en sortiras beaucoup mieux avec git, tu peux faire ce que tu veux avec, ce qui n'est pas le cas avec SVN.

Exemple par versions :
1/ Tu fais une (ou plusieurs) branches de dev, une branche de prod.
2/ Tu dev sur ta branche de dev, lorsque tu es satisfait, tu taggues avec un numéro de version.
3/ Une fois taggué, tu fais exécuter (automatiquement) un hook qui va prendre la version, la tester avec ton outil d'intégration continue préféré, et si c'est valider pousser sur la branche prod avec le tag utilisé.

Exemple en full CI :
1/ Tu fais une (ou plusieurs) branches de dev, une branche de pré-prod, une branche de prod.
2/ Tu dev sur ta branche de dev, lorsque tu es satisfait, tu pousses sur pré-prod
3/ Une fois sur pré-prod, tu fais exécuter (automatiquement) un hook qui va tester ton commit avec ton outil d'intégration continue préféré, et si c'est valider pousser sur la branche prod, et incrémenter un compteur de révision.

Cordialement

salut,

pour ce qui est du principe c'est un peu ce que l'on fait "à la main".
en dehors du fait que chaque commit est suivis (dans l'heure) de l’exécution de la tâche qui va bien dans le CI.

Par contre changer le gestionnaire de sources c'est exclus ....

Merci

@+

C'est dommage de ne pas vouloir travailler avec des outils efficaces !

Cordialement

ben la on parle de 10 à 15 ans d'historique d'applications (avec une cinquantaine d'appli grossomodo dont l'une d'entre avec une copie locale de 2Go environ ^^).

rien que la migration svn => git pours cela sans aucune perte d'historique je ne sais pas si c'est réalisable et cela ne se fait pas en deux minutes.

Ajoute qu'au total c'est dans 120 personnes (mini) qui utilise le svn (et il n'y a pas que les dev qui l'utilise) c'est autant de personnes a former, dont il faut migrer les copies locales, les machines physiques / virtuelles, remettre d'équerre les projets sur les ide, former les gens de l'équipes qui gère les ordi et font les installations des appli groupe, former l'équipe du support informatique pour répondre aux questions qui vont avec etc etc.

Dommage peux être mais au vu du chantier c'est clairement pas 10 applis qui ont déjà un pieds dans la tombes qui enclencherons ce genre de chose sans parler du fait que l'on a déjà une solution utilisable avec svn et tout aussi manuelle (je ne sais même pas s'il y a un l'équivalent d'un tag svn sur git et c'est quand même quelque chose de pratique ).


@+

ben la on parle de 10 à 15 ans d'historique d'applications (avec une cinquantaine d'appli grossomodo dont l'une d'entre avec une copie locale de 2Go environ ^^).

Si tu as 2Go de données sur svn je n'ose pas imaginer combien de temps prend un checkout...

rien que la migration svn => git pours cela sans aucune perte d'historique je ne sais pas si c'est réalisable et cela ne se fait pas en deux minutes.

Git_SVN, ça te crée un dépôt git à partir d'un dépôt SVN, en gardant toute l'historique. Avec le bonus du facteur 5 à 10 en performance (aussi bien temps d'exécution des opérations qu'en taille du dépôt).

Ajoute qu'au total c'est dans 120 personnes (mini) qui utilise le svn (et il n'y a pas que les dev qui l'utilise) c'est autant de personnes a former, dont il faut migrer les copies locales, les machines physiques / virtuelles, remettre d'équerre les projets sur les ide, former les gens de l'équipes qui gère les ordi et font les installations des appli groupe, former l'équipe du support informatique pour répondre aux questions qui vont avec etc etc.

Si personne ne le pousse, c'est clair que ce ne sera jamais fait. Ceci dit si vous évaluez la perte de temps que vous subissez à utiliser SVN sur des gros dépôts, le coût de la migration se justifie facilement. Mais pour ça il faut l'utiliser.

Dommage peux être mais au vu du chantier c'est clairement pas 10 applis qui ont déjà un pieds dans la tombes qui enclencherons ce genre de chose sans parler du fait que l'on a déjà une solution utilisable avec svn et tout aussi manuelle (je ne sais même pas s'il y a un l'équivalent d'un tag svn sur git et c'est quand même quelque chose de pratique ).

Si tu poses la question c'est clairement que tu n'as jamais touché à git. Non seulement c'est géré, mais c'est *beaucoup* mieux géré. A moins que cela n'ait changé, tu dupliques les données lorsque tu fais un tag ou une branche SVN, ce qui n'est pas le cas de git. Et cela a une très grosse influence en terme de performance sur des gros dépôts, en particulier lorsque tu vois que la création d'une branche git est immédiate, quelque soit ton dépôt.

Cordialement

merci pour les infos.

un tags n'est qu'une image donc coté place c'est pas grand chose une branche oui copie intégrale ...

checkout de 2Go oui c'est relativement long ....


Pour pousser faut un quelconque pouvoir et je n'en ai aucun, ici c'est pas pieds pris dans le béton, c'est jusqu'au bassin, voir plus haut pour certain

@+