Intégration continue: outils alternatifs à TFS
371 vues
Accéder directement au premier message non lu
Guillaume Collic
21 sept. 2011, 06:21:2221/09/2011
à paris...@googlegroups.com
Bonjour à tous,
je sors d'un projet de ~15 développeurs et ~18 mois. Nous utilisions TFS pour la gestion de version et l'intégration continue. Ça nous a amené des lourdeurs. Si ça ne tenait qu'à moi on aurait plutôt utilisé Git + Hudson/Jenkins + Sonar. Mais pour ce genre d'outils, c'est facile de se faire une première idée sur des petits projets comme j'ai fais, de dire que c'est mieux, et de finalement se casser les dents sur un gros projet qui montre les limitations des outils. Est ce que vous avez des retours d’expériences sur des gros projets .NET ? J'ai déjà eu des retours suffisamment positifs sur des gros projets hors .NET, c'est les spécificités .NET qui m'intéressent ;-)
Merci pour vos retours,
Guillaume (de Rennes)
MDE
21 sept. 2011, 12:42:0021/09/2011
à paris...@googlegroups.com
(désolé si double-post j'ai un pb avec mon inscription au groupe)
Salut Guillaume,
J'ai travaillé sur un projet assez important (+80 personnes) sur 18 mois, dont 15 personnes en .NET.
La solution construite est hétérogène : client lourd .NET, webapp et services d'intégration REST en java, mais nous voulions avoir une unité dans l'usine de dev, pour renforcer l'unité de la solution produite. Donc on est parti sur du SVN + hudson/jenkins pour l'ensemble de la solution.
On est ravi de cette intégration continue. Très simple à mettre en place, on a construit petit à petit des process de build très complets et très adaptés à notre projet. Les développeurs ont pu s'approprier les process de build, participer à leur évolution, etc.
Au niveau spécificité .NET, rien d'extraordinaire : plugin nAnt pour déclencher des builds MsBuild, un peu de Sonar, FxCop, StyleCop.
On a utilisé un peu de maven également (oui... en .NET) comme une 'coquille' nous permettant de bénéficier ce qui a été mis en place par les java-istes : numérotation des versions (un numéro de version unique, un tag unique pour toute la solution), et l'utilisation d'un repo Nexus pour pousser les binaires.
On a même mis en place des process de packaging ultra-custom, puisque c'est une appli java qui joue le rôle de fournisseur de l'installer .NET (un click-once en java quoi ;-) qui pousse le vice jusqu'à injecter des fichiers spécifiques (certificats) au moment d'envoyer l'archive. Bref, un build + packaging très poussé, dans un environnement hétérogène (java + .net), manipulé par les devs et les ops (qui sont ultra-linuxiens dans l'âme). Tout ça par du script largement accessible à tous. Autant te dire que je me vois pas refaire un truc pareil avec du workflow TFS ;-)
On a également du test automatisé, Nunit évidemment, mais aussi fonctionnel avec GreenPepper, le tout piloté par des bouts de script customs.
Alors, ok, out-of-the box, tes builds vont être simplistes, ça va prendre du temps (donc du jour.homme...) pour faire grandir tout ça, mais la flexibilité, et la compréhension de l'usine par tous ont une grande valeur.
Mon prochain projet .NET, je recommanderai fortement jenkins plutôt que TFS. Sans hésiter.
Salut Guillaume,
J'ai travaillé sur un projet assez important (+80 personnes) sur 18 mois, dont 15 personnes en .NET.
La solution construite est hétérogène : client lourd .NET, webapp et services d'intégration REST en java, mais nous voulions avoir une unité dans l'usine de dev, pour renforcer l'unité de la solution produite. Donc on est parti sur du SVN + hudson/jenkins pour l'ensemble de la solution.
On est ravi de cette intégration continue. Très simple à mettre en place, on a construit petit à petit des process de build très complets et très adaptés à notre projet. Les développeurs ont pu s'approprier les process de build, participer à leur évolution, etc.
Au niveau spécificité .NET, rien d'extraordinaire : plugin nAnt pour déclencher des builds MsBuild, un peu de Sonar, FxCop, StyleCop.
On a utilisé un peu de maven également (oui... en .NET) comme une 'coquille' nous permettant de bénéficier ce qui a été mis en place par les java-istes : numérotation des versions (un numéro de version unique, un tag unique pour toute la solution), et l'utilisation d'un repo Nexus pour pousser les binaires.
On a même mis en place des process de packaging ultra-custom, puisque c'est une appli java qui joue le rôle de fournisseur de l'installer .NET (un click-once en java quoi ;-) qui pousse le vice jusqu'à injecter des fichiers spécifiques (certificats) au moment d'envoyer l'archive. Bref, un build + packaging très poussé, dans un environnement hétérogène (java + .net), manipulé par les devs et les ops (qui sont ultra-linuxiens dans l'âme). Tout ça par du script largement accessible à tous. Autant te dire que je me vois pas refaire un truc pareil avec du workflow TFS ;-)
On a également du test automatisé, Nunit évidemment, mais aussi fonctionnel avec GreenPepper, le tout piloté par des bouts de script customs.
Alors, ok, out-of-the box, tes builds vont être simplistes, ça va prendre du temps (donc du jour.homme...) pour faire grandir tout ça, mais la flexibilité, et la compréhension de l'usine par tous ont une grande valeur.
Mon prochain projet .NET, je recommanderai fortement jenkins plutôt que TFS. Sans hésiter.
Mathieu DESPRIEE
Architecte
OCTO Technology
..........................................................
50, Avenue des Champs-Elysées
75008 Paris
GSM : +33 6 17 17 54 12
http://www.octo.com
...........................................................
Abonnez-vous au blog OCTO
http://blog.octo.com/
...........................................................
Architecte
OCTO Technology
..........................................................
50, Avenue des Champs-Elysées
75008 Paris
GSM : +33 6 17 17 54 12
http://www.octo.com
...........................................................
Abonnez-vous au blog OCTO
http://blog.octo.com/
...........................................................
Mathieu Despriee
21 sept. 2011, 12:18:3921/09/2011
à paris...@googlegroups.com
Alexandre Victoor
25 sept. 2011, 14:28:1825/09/2011
à paris...@googlegroups.com
Merci Mathieu pour ce retour d'expérience.
Pour ma part je travaille dans une grosse banque française, dans laquelle l'environnement technique est assez hétérogène, avec quand même surtout du java et du c#.
Je risque d'être un peu partial sur sonar :)
On l'utilise ainsi que hudson sur un gros nombre de projets, y compris de gros projets dotnet de plusieurs centaines de milliers de lignes de code. Alors oui, au départ utiliser des outils du monde java comme hudson/jenkins, ça a fait grincer quelques dents. Le manque de façon de faire "standard" pour structurer une solution VS ou réaliser le "packaging", les différents cas de figures à gérer (32bits, 64bits, silverlight) rendent la tâche assez ardue et on n'a encore pas mal de pain sur la planche.
Ceci étant dit, je n'ai pas l'impression qu'on ait rencontré encore de difficultés insurmontables. A part TeamCity, je ne vois pas vraiment d'autres solutions viables.
Hope it helps
Alex
2011/9/21 Mathieu Despriee <mdes...@octo.com>
Guillaume Collic
26 sept. 2011, 03:45:1826/09/2011
à paris...@googlegroups.com
Merci pour vos retours qui me confortent vers ces solutions !
Bonne journée,
Guillaume
Développeur Agiliste passionné
__________________________
Twitter : @gcollic
2011/9/25 Alexandre Victoor <alexv...@gmail.com>
Julien Lavigne du Cadet
26 sept. 2011, 07:28:2126/09/2011
à altnetfr
Nous utilisons le combo suivant pour tout notre système
d'information :
HG + TeamCity + Jira
- HG car quand on a gouté à un système de gestion de source distribué,
on ne peut plus faire sans.
- TeamCity car en .Net le setup est vraiment rapide et c'est bourré
d'options sympa (ex : intégration avec dotcover, fxcop, etc.). On a
commencé avec quelques projets et on est passé il y a quelques temps
en version pro pour avoir plus de projets/build agents
- Jira, faut-il encore le présenter? :-)
Jusqu'a maintenant on a toujours été très satisfait de cet
environnement.
Julien
On Sep 26, 9:45 am, Guillaume Collic <gcol...@gmail.com> wrote:
> Merci pour vos retours qui me confortent vers ces solutions !
>
> Bonne journée,
>
> Guillaume
> Développeur Agiliste passionné
> __________________________
> Twitter : @gcollic <http://twitter.com/gcollic>
>
> <http://at2011.agiletour.org/en/at2011_rennes.html>
>
> 2011/9/25 Alexandre Victoor <alexvict...@gmail.com>
> >> Le 21 septembre 2011 12:21, Guillaume Collic <gcol...@gmail.com> a écrit
d'information :
HG + TeamCity + Jira
- HG car quand on a gouté à un système de gestion de source distribué,
on ne peut plus faire sans.
- TeamCity car en .Net le setup est vraiment rapide et c'est bourré
d'options sympa (ex : intégration avec dotcover, fxcop, etc.). On a
commencé avec quelques projets et on est passé il y a quelques temps
en version pro pour avoir plus de projets/build agents
- Jira, faut-il encore le présenter? :-)
Jusqu'a maintenant on a toujours été très satisfait de cet
environnement.
Julien
On Sep 26, 9:45 am, Guillaume Collic <gcol...@gmail.com> wrote:
> Merci pour vos retours qui me confortent vers ces solutions !
>
> Bonne journée,
>
> Guillaume
> Développeur Agiliste passionné
> __________________________
>
> <http://at2011.agiletour.org/en/at2011_rennes.html>
>
> 2011/9/25 Alexandre Victoor <alexvict...@gmail.com>
>
>
>
>
>
>
>
> > Merci Mathieu pour ce retour d'expérience.
> > Pour ma part je travaille dans une grosse banque française, dans laquelle
> > l'environnement technique est assez hétérogène, avec quand même surtout du
> > java et du c#.
> > Je risque d'être un peu partial sur sonar :)
> > On l'utilise ainsi que hudson sur un gros nombre de projets, y compris de
> > gros projets dotnet de plusieurs centaines de milliers de lignes de code.
> > Alors oui, au départ utiliser des outils du monde java comme hudson/jenkins,
> > ça a fait grincer quelques dents. Le manque de façon de faire "standard"
> > pour structurer une solution VS ou réaliser le "packaging", les différents
> > cas de figures à gérer (32bits, 64bits, silverlight) rendent la tâche
> > assez ardue et on n'a encore pas mal de pain sur la planche.
> > Ceci étant dit, je n'ai pas l'impression qu'on ait rencontré encore de
> > difficultés insurmontables. A part TeamCity, je ne vois pas vraiment
> > d'autres solutions viables.
> > Hope it helps
>
> > Alex
>
> > 2011/9/21 Mathieu Despriee <mdespr...@octo.com>
>
>
>
>
>
>
> > Merci Mathieu pour ce retour d'expérience.
> > Pour ma part je travaille dans une grosse banque française, dans laquelle
> > l'environnement technique est assez hétérogène, avec quand même surtout du
> > java et du c#.
> > Je risque d'être un peu partial sur sonar :)
> > On l'utilise ainsi que hudson sur un gros nombre de projets, y compris de
> > gros projets dotnet de plusieurs centaines de milliers de lignes de code.
> > Alors oui, au départ utiliser des outils du monde java comme hudson/jenkins,
> > ça a fait grincer quelques dents. Le manque de façon de faire "standard"
> > pour structurer une solution VS ou réaliser le "packaging", les différents
> > cas de figures à gérer (32bits, 64bits, silverlight) rendent la tâche
> > assez ardue et on n'a encore pas mal de pain sur la planche.
> > Ceci étant dit, je n'ai pas l'impression qu'on ait rencontré encore de
> > difficultés insurmontables. A part TeamCity, je ne vois pas vraiment
> > d'autres solutions viables.
> > Hope it helps
>
> > Alex
>
Radwane
28 sept. 2011, 12:58:5828/09/2011
à altnetfr
J'utilises actuellement TFS et moi non plus je ne suis pas du tout
convaincu, au delà de l'intégration continue c'est surtout la gestion
de source que je trouves vraiment défaillante... Je dirais même que je
préfère SVN, sans même parler de Git ou Mercurial... Aujourd'hui y a
des projets embryonnaire autour de GitTfs, je n'ai pas eu l'occasion
de vraiment essayer.
@Alexandre c'était quoi le problème avec le packaging Silverlight ?
Je ne sais pas si vous connaissez ce post sur TFS au titre évocateur
http://www.derekhammer.com/2011/09/11/tfs-is-destroying-your-development-capacity.html
On Sep 26, 1:28 pm, Julien Lavigne du Cadet <julien.lavi...@gmail.com>
wrote:
convaincu, au delà de l'intégration continue c'est surtout la gestion
de source que je trouves vraiment défaillante... Je dirais même que je
préfère SVN, sans même parler de Git ou Mercurial... Aujourd'hui y a
des projets embryonnaire autour de GitTfs, je n'ai pas eu l'occasion
de vraiment essayer.
@Alexandre c'était quoi le problème avec le packaging Silverlight ?
Je ne sais pas si vous connaissez ce post sur TFS au titre évocateur
http://www.derekhammer.com/2011/09/11/tfs-is-destroying-your-development-capacity.html
On Sep 26, 1:28 pm, Julien Lavigne du Cadet <julien.lavi...@gmail.com>
wrote:
Alexandre Victoor
28 sept. 2011, 16:39:4928/09/2011
à paris...@googlegroups.com
Radwane, pas de soucis de packaging Silverlight en particulier. Par contre le fait que silverlight utilise une runtime différente du reste du code, fatalement ça complique les choses.
A propos du packaging, je pensais à tout ce qui tourne autour des livraisons.
Je fais un zip de ma solution, mais avec quoi dedans ?
Je mets à jour les versions de mes assemblies avant de tagger mon svn mais l'équipe A utilise nant et l'équipe B msbuild, etc...
Toutes ces petites choses, ces différentes façons de faire font que ce n'est pas toujours évident de déployer une usine de dev pour plusieurs équipes et de normaliser/homogénéiser les builds.
Alex
Clément
28 sept. 2011, 17:11:4228/09/2011
à altnetfr
Salut,
Bon, faut quand même que je défende un peu TFS...:)
Je suis 100% d'accord avec vous que si vous utilisez TFS uniquement
pour son source control et son intégration continue, c'est une ENORME
[biiiiiiiip]. Il est plus que surclassé par de nombreuses solutions
sur ces 2 points.
J'ai regardé le lien que Radwane à envoyer, il s'étend largement sur
ces 2 élements...et élude assez rapidement les Work Items & Process
Templates (en faisant référence au Bug Tracking et au process template
Agile...), preuve qu'il n'a pas du beaucoup se pencher dessus.
Et en effet, l'argument de l'intégration est un argument
récurrent...je vais tenter d'en dire plus.
Je vais tout d'abord faire un focus sur les Work Items & les Process
Templates (et notamment les comparer avec Jira/Greenhopper).
Nous avons dans notre équipe pris le template Agile MS (critiqué dans
le lien, mais sans regardé plus loin...) qu'on a modifié, c'est
réellement simple, juste un peu de XML pour définir tout ce qu'on
veut : nouveaux champs, transitions et états dans les workflows,
formulaires. De plus, l'ensemble des données des work items sont
accessibles via un datawarehouse et un cube relativement facile à
prendre en main aussi, sur lesquels on va pouvoir créer des rapports
SSRS personnalisés.
Une spécificité que nous devions gérer était l'activité de notre
équipe de 15 personnes. Elle se différencie par la prise en charge
d'une(plusieurs) application (l'ALM prend surtout son sens dans ce
cadre à mon avis, ça commence par un A) et non pas d'un projet
(abandonné au client quand il est -mal- fini...), c'est-à-dire qu'on
gère à la fois du support Niv 2 (Niv 1 réalisé par une cellule métier -
Marketing en l'occurrence), la maintenance et les multiples projets
(non pharaoniques et du coup plus nombreux pour rester agiles)...et
TFS, via son extensibilié, nous a permis de construire notre template
d'équipe adapté à un grand nombre d'activités mises en jeu dans notre
contexte (livraisons, gestion des demandes -ou "bug tracking"-, suivi
de projets, suivi d'itérations,...). Cela s'est fait principalement
avec de nouveaux work items et des rapports d'équipe personnalisés (au
revoir les post-its...désolé pour ceux que ça choque ;), mais tout le
monde a trouvé ça plus logique d'utiliser un outil...je me suis
rapidement fait rembarré avec mes post-its...bon maintenant on attend
les videoproj pour retrouver plus de management visuel...)...
Enfin, nous avons comparé notre solution à la solution proposée en
"standard" dans mon entreprise réalisée avec GreenHopper (dernière
version), et de l'aveu de ceux qui l'ont fait, GreenHopper ne permet
pas de faire quelque chose d'équivalent (je me base seulement sur leur
retour, je n'ai pas mis les mains dedans...peut-être quelqu'un de
cette liste pourra en dire plus sur Jira/GreenHopper).
Les avantages sont nombreux pour TFS (vs Jira/GreenHopper) :
extensibilité via XML (déploiement sur plusieurs projets automatisé,
attention pas dans une volonté de "standardisation"...mais plutôt de
réutilisation/homogénéisation quand une même équipe a plusieurs
projets) vs configuration manuelle, solution de reporting intégrée et
personalisable vs quelques rapports limités et figés,
Le seul gros désavantage est l'interface Web Access, qui est en effet
rétrograde, lente et orienté CRUD (souligné dans le lien), comparé à
GreenHopper qui pour des projets Agiles implémente quelques interfaces
sympas plus proches de processus quotidiens (plutôt que du CRUD). Je
ne parle pas de Jira, car je trouve l'interface pas forcément bien
meilleure que TFS Web Access...
Finalement, nos métiers sont passés de Mantis à TFS sans vraiment
trouver rien à redire...nous (IT) nous sommes passés sur une solution
beaucoup plus intégrée et personnalisables (à n'importe quelle équipe
finalement). A noter que la version 2010 de Web Access était un rachat
de MS (déjà en 2008) et que la version 2011 va changer ça a priori
(pas encore essayé...)
Concernant les 2 outils pas tops (Source Control et Intégration
Continue), on s'y est fait et on a su contourner les problèmes (par
exemple, ne surtout pas utiliser les builds en Work flow Foundation
que critique le lien -et je me joins à la critique- mais rester en
MSBuild). On pourrait très bien en sortir, mais on ne voit pas
actuellement de réel gain à le faire...
A noter aussi que je n'ai pas d'actions MS ;) et qu'on n'a pas que TFS
dans notre outillage : R# (indispensable!), Yourkit, Sonar,
NDepend...on change volontier quand on y voit un gain potentiel.
Bon, je vais m'arrêter là, je vous invite à aller voir ma présentation
sur notre transition à TFS (Agile France 2011).
http://prezi.com/86oujtunwxkn/agile-and-alm-by-example-managing-the-whole-application-lifecycle/
Je suis dispo pour la refaire lors d'une session Alt.Net si ça en
intéresse certains (mais vu le nombre de sceptiques, ça paraît mal
barré ;)).
A+
Clément
On 28 sep, 22:39, Alexandre Victoor <alexvict...@gmail.com> wrote:
> Radwane, pas de soucis de packaging Silverlight en particulier. Par contre
> le fait que silverlight utilise une runtime différente du reste du code,
> fatalement ça complique les choses.
> A propos du packaging, je pensais à tout ce qui tourne autour des
> livraisons.
> Je fais un zip de ma solution, mais avec quoi dedans ?
> Je mets à jour les versions de mes assemblies avant de tagger mon svn mais
> l'équipe A utilise nant et l'équipe B msbuild, etc...
> Toutes ces petites choses, ces différentes façons de faire font que ce n'est
> pas toujours évident de déployer une usine de dev pour plusieurs équipes et
> de normaliser/homogénéiser les builds.
>
> Alex
>
> 2011/9/28 Radwane <hassen.radw...@gmail.com>
Bon, faut quand même que je défende un peu TFS...:)
Je suis 100% d'accord avec vous que si vous utilisez TFS uniquement
pour son source control et son intégration continue, c'est une ENORME
[biiiiiiiip]. Il est plus que surclassé par de nombreuses solutions
sur ces 2 points.
J'ai regardé le lien que Radwane à envoyer, il s'étend largement sur
ces 2 élements...et élude assez rapidement les Work Items & Process
Templates (en faisant référence au Bug Tracking et au process template
Agile...), preuve qu'il n'a pas du beaucoup se pencher dessus.
Et en effet, l'argument de l'intégration est un argument
récurrent...je vais tenter d'en dire plus.
Je vais tout d'abord faire un focus sur les Work Items & les Process
Templates (et notamment les comparer avec Jira/Greenhopper).
Nous avons dans notre équipe pris le template Agile MS (critiqué dans
le lien, mais sans regardé plus loin...) qu'on a modifié, c'est
réellement simple, juste un peu de XML pour définir tout ce qu'on
veut : nouveaux champs, transitions et états dans les workflows,
formulaires. De plus, l'ensemble des données des work items sont
accessibles via un datawarehouse et un cube relativement facile à
prendre en main aussi, sur lesquels on va pouvoir créer des rapports
SSRS personnalisés.
Une spécificité que nous devions gérer était l'activité de notre
équipe de 15 personnes. Elle se différencie par la prise en charge
d'une(plusieurs) application (l'ALM prend surtout son sens dans ce
cadre à mon avis, ça commence par un A) et non pas d'un projet
(abandonné au client quand il est -mal- fini...), c'est-à-dire qu'on
gère à la fois du support Niv 2 (Niv 1 réalisé par une cellule métier -
Marketing en l'occurrence), la maintenance et les multiples projets
(non pharaoniques et du coup plus nombreux pour rester agiles)...et
TFS, via son extensibilié, nous a permis de construire notre template
d'équipe adapté à un grand nombre d'activités mises en jeu dans notre
contexte (livraisons, gestion des demandes -ou "bug tracking"-, suivi
de projets, suivi d'itérations,...). Cela s'est fait principalement
avec de nouveaux work items et des rapports d'équipe personnalisés (au
revoir les post-its...désolé pour ceux que ça choque ;), mais tout le
monde a trouvé ça plus logique d'utiliser un outil...je me suis
rapidement fait rembarré avec mes post-its...bon maintenant on attend
les videoproj pour retrouver plus de management visuel...)...
Enfin, nous avons comparé notre solution à la solution proposée en
"standard" dans mon entreprise réalisée avec GreenHopper (dernière
version), et de l'aveu de ceux qui l'ont fait, GreenHopper ne permet
pas de faire quelque chose d'équivalent (je me base seulement sur leur
retour, je n'ai pas mis les mains dedans...peut-être quelqu'un de
cette liste pourra en dire plus sur Jira/GreenHopper).
Les avantages sont nombreux pour TFS (vs Jira/GreenHopper) :
extensibilité via XML (déploiement sur plusieurs projets automatisé,
attention pas dans une volonté de "standardisation"...mais plutôt de
réutilisation/homogénéisation quand une même équipe a plusieurs
projets) vs configuration manuelle, solution de reporting intégrée et
personalisable vs quelques rapports limités et figés,
Le seul gros désavantage est l'interface Web Access, qui est en effet
rétrograde, lente et orienté CRUD (souligné dans le lien), comparé à
GreenHopper qui pour des projets Agiles implémente quelques interfaces
sympas plus proches de processus quotidiens (plutôt que du CRUD). Je
ne parle pas de Jira, car je trouve l'interface pas forcément bien
meilleure que TFS Web Access...
Finalement, nos métiers sont passés de Mantis à TFS sans vraiment
trouver rien à redire...nous (IT) nous sommes passés sur une solution
beaucoup plus intégrée et personnalisables (à n'importe quelle équipe
finalement). A noter que la version 2010 de Web Access était un rachat
de MS (déjà en 2008) et que la version 2011 va changer ça a priori
(pas encore essayé...)
Concernant les 2 outils pas tops (Source Control et Intégration
Continue), on s'y est fait et on a su contourner les problèmes (par
exemple, ne surtout pas utiliser les builds en Work flow Foundation
que critique le lien -et je me joins à la critique- mais rester en
MSBuild). On pourrait très bien en sortir, mais on ne voit pas
actuellement de réel gain à le faire...
A noter aussi que je n'ai pas d'actions MS ;) et qu'on n'a pas que TFS
dans notre outillage : R# (indispensable!), Yourkit, Sonar,
NDepend...on change volontier quand on y voit un gain potentiel.
Bon, je vais m'arrêter là, je vous invite à aller voir ma présentation
sur notre transition à TFS (Agile France 2011).
http://prezi.com/86oujtunwxkn/agile-and-alm-by-example-managing-the-whole-application-lifecycle/
Je suis dispo pour la refaire lors d'une session Alt.Net si ça en
intéresse certains (mais vu le nombre de sceptiques, ça paraît mal
barré ;)).
A+
Clément
On 28 sep, 22:39, Alexandre Victoor <alexvict...@gmail.com> wrote:
> Radwane, pas de soucis de packaging Silverlight en particulier. Par contre
> le fait que silverlight utilise une runtime différente du reste du code,
> fatalement ça complique les choses.
> A propos du packaging, je pensais à tout ce qui tourne autour des
> livraisons.
> Je fais un zip de ma solution, mais avec quoi dedans ?
> Je mets à jour les versions de mes assemblies avant de tagger mon svn mais
> l'équipe A utilise nant et l'équipe B msbuild, etc...
> Toutes ces petites choses, ces différentes façons de faire font que ce n'est
> pas toujours évident de déployer une usine de dev pour plusieurs équipes et
> de normaliser/homogénéiser les builds.
>
> Alex
>
>
>
>
>
>
>
>
> > J'utilises actuellement TFS et moi non plus je ne suis pas du tout
> > convaincu, au delà de l'intégration continue c'est surtout la gestion
> > de source que je trouves vraiment défaillante... Je dirais même que je
> > préfère SVN, sans même parler de Git ou Mercurial... Aujourd'hui y a
> > des projets embryonnaire autour de GitTfs, je n'ai pas eu l'occasion
> > de vraiment essayer.
>
> > @Alexandre c'était quoi le problème avec le packaging Silverlight ?
>
> > Je ne sais pas si vous connaissez ce post sur TFS au titre évocateur
>
> >http://www.derekhammer.com/2011/09/11/tfs-is-destroying-your-developm...
>
>
>
>
>
>
> > J'utilises actuellement TFS et moi non plus je ne suis pas du tout
> > convaincu, au delà de l'intégration continue c'est surtout la gestion
> > de source que je trouves vraiment défaillante... Je dirais même que je
> > préfère SVN, sans même parler de Git ou Mercurial... Aujourd'hui y a
> > des projets embryonnaire autour de GitTfs, je n'ai pas eu l'occasion
> > de vraiment essayer.
>
> > @Alexandre c'était quoi le problème avec le packaging Silverlight ?
>
> > Je ne sais pas si vous connaissez ce post sur TFS au titre évocateur
>
in...@softfluent.com
28 sept. 2011, 17:52:2928/09/2011
à altnetfr
Je pense que Clément a raison, TFS permet de faire ce qu'on veut tout
de même en gestion de source et intégration continue.
Sans connaitre tous les détails de la manière dont nous le mettons en
oeuvre, nous avons 48 projets et 600 000 lignes de code dans notre
produit et TFS s'en sort très bien. On gère également à peu près
l'équivalent en code source de projets clients. Et je ne crois pas une
seconde qu'on ait les plus gros projets TFS de la Terre.
Certes, nous avons aussi une personne en charge de cet aspect qui est
l'ancienne consultante en charge des offres d'industrialisation des
développements chez Microsoft Consulting, donc ça nous aide sans doute
à bien utiliser les outils, mais je crois que le point clé est que ce
n'est certainement pas l'outil le facteur limitant, mais plutôt les
compétences pour bien l'utiliser (comme quasiment toujours au
demeurant sur les projets...).
Mon point de vue en suivant de loin cette conversation...
Etre alternatif, pourquoi pas, mais l'être en disant juste que TFS ne
marche pas ou est lourd sans argumenter réellement, cela ne satisfait
pas mon esprit d'ingénieur. J'aimerais comprendre qu'est ce qui ne
marche pas précisément dans vos contextes. Même si je ne doute pas que
d'autres produits peuvent permettre aussi de gérer le code source ou
l'intégration continue.
Daniel, SoftFluent
> sur notre transition à TFS (Agile France 2011).http://prezi.com/86oujtunwxkn/agile-and-alm-by-example-managing-the-w...
> ...
>
> plus de détails »
de même en gestion de source et intégration continue.
Sans connaitre tous les détails de la manière dont nous le mettons en
oeuvre, nous avons 48 projets et 600 000 lignes de code dans notre
produit et TFS s'en sort très bien. On gère également à peu près
l'équivalent en code source de projets clients. Et je ne crois pas une
seconde qu'on ait les plus gros projets TFS de la Terre.
Certes, nous avons aussi une personne en charge de cet aspect qui est
l'ancienne consultante en charge des offres d'industrialisation des
développements chez Microsoft Consulting, donc ça nous aide sans doute
à bien utiliser les outils, mais je crois que le point clé est que ce
n'est certainement pas l'outil le facteur limitant, mais plutôt les
compétences pour bien l'utiliser (comme quasiment toujours au
demeurant sur les projets...).
Mon point de vue en suivant de loin cette conversation...
Etre alternatif, pourquoi pas, mais l'être en disant juste que TFS ne
marche pas ou est lourd sans argumenter réellement, cela ne satisfait
pas mon esprit d'ingénieur. J'aimerais comprendre qu'est ce qui ne
marche pas précisément dans vos contextes. Même si je ne doute pas que
d'autres produits peuvent permettre aussi de gérer le code source ou
l'intégration continue.
Daniel, SoftFluent
>
> plus de détails »
Guillaume Collic
29 sept. 2011, 02:23:3029/09/2011
à paris...@googlegroups.com
Bonjour,
Etre alternatif, pourquoi pas, mais l'être en disant juste que TFS ne
marche pas ou est lourd sans argumenter réellement, cela ne satisfait
pas mon esprit d'ingénieur. J'aimerais comprendre qu'est ce qui ne
marche pas précisément dans vos contextes.
Je comprends, je me suis déjà fait mon idée sur TFS et mon but était d'avoir des retours sur la solution que j'envisage, je n'ai pas expliqué ce qui m'y a amené car c'est très long. Je n'ai pas beaucoup de temps ce matin, je me contenterais de 2 exemples. Mon contexte est toujours agile désormais, c'est important pour le choix de l'alm.
Je pense que Clément a raison, TFS permet de faire ce qu'on veut tout
de même en gestion de source et intégration continue.
Ce n'est pas un gestionnaire de source distribué, on ne peut donc pas … faire de la gestion de source distribué. Hors c'est ce que je veux. Quand tu y touches, tu ne fais pas machine arrière (perso je préfère les briquets aux silex, et c'est ce que je ressens avec les DCVS). Les présentations de Sébastien Douche sont excellentes sur le sujet (http://gitfr.net/). Typiquement, la gestion de source comporte 3 types de workflow sur tous les projets, mais certains sont généralement implicites. La gestion niveau projet, le workflow bien connu : comment les développeurs doivent travailler ensemble au niveau équipe (tronc commun ? branches ? Quand passe t'on de l'une à l'autre ?). TFS est moins bon que git pour personnaliser et faire évoluer la manière de travailler, mais il sait faire des choses. Il y a ensuite le workflow personnel de chaque développeur. Perso je fais du TDD, je commit plusieurs fois par heure en local, je fais de nombreuses branches temporaires à vie très très courte (n'essayez pas avec TFS…), et j'aime nettoyer mes commits avant de les mettre sur le tronc commun (git le gère, mais pas mercurial). J'aime aussi pouvoir continuer à faire des commits locaux sans le réseau (panne du fournisseur d'accés internet d'une demi journée une fois, problème en salle machine avec le serveur TFS une autre, et tout simplement le train sinon) que je pousse sur le tronc commun lorsque je retrouve la connexion. Cette manière de travailler localement n'impacte pas mes collègues, il n'y a aucune raison que ça le fasse. Il y a ensuite les workflows pour partager du code à 2 ou +, avec TFS on peut mettre un shelveset et le récupérer de l'autre coté, mais c'est trés limité. Tant que le shelveset n'est pas commité, il n'y a pas d'historique intermédiaire.
On ne fait qu'effleurer les avantages de git sur TFS là… Pour voir ce qu'y est reprochable à TFS, il faut prendre le temps de découvrir toutes les facettes des DCVS ;-)
Pour l'intégration continue, en ayant mis en place Hudson sur un projet (mais Java), je peux confirmer le retour de Mathieu :
On est ravi de cette intégration continue. Très simple à mettre en place, on a construit petit à petit des process de build très complets et très adaptés à notre projet. Les développeurs ont pu s'approprier les process de build, participer à leur évolution, etc.
La simplicité (lire ergonomie, pas limitations) d'hudson/Jenkins permet à tous de se l'approprier et de le faire vivre. Sur mon projet TFS, il y avait un référent principal, mais même lui se débattait souvent avec, qui devait parfois se faire aider de personnes extérieures au projet. Nous n'avions pas de consultant Microsoft expert ;) et il ne devrait pas y en avoir besoin quelque part. L'expertise se joue sur l'intégration continue elle même (pipeline, management visuel, déploiement en continu, …), pas le produit (offre TFS, Hudson, …). Bref, un hudson est bien plus souple et simple, tout en étant très puissant, et pour un projet agile, ça n'a pas de prix.
Ah aussi, nous avions une fuite mémoire sur TFS (problème non isolé, rencontré par d'autres).
my quick 2 cents,
2011/9/28 danielco...@gmail.com <in...@softfluent.com>
Tomasz JASKULA
29 sept. 2011, 03:54:5629/09/2011
à paris...@googlegroups.com
Bon résumé. Pour ma part je commence de plus en plus à me désintéresser de TFS dans le contexte de projets agile que je réalise. Le gestionnaire de code sources centralisé c'est bon lorsque tout le monde est sur place ou a un accès permanent au gestionnaire de codes sources.
Ma question est, quels sont vos outils préféré pour travailler avec Git ou Mercurial sous windows bien sûr ;)? Pour le moment il n'y a rien de très pratique que la ligne de commende.
Ma question est, quels sont vos outils préféré pour travailler avec Git ou Mercurial sous windows bien sûr ;)? Pour le moment il n'y a rien de très pratique que la ligne de commende.
// Thomas
Bruno Baia
29 sept. 2011, 11:24:0729/09/2011
à paris...@googlegroups.com
Bonjour,
"Tortoise" fonctionne très bien avec Git et Mercurial.
Et si tu as déjà utilisé TortoiseSVN ou TortoiseCVS auparavant, tu seras pas perdu.
Cordialement,
Bruno Baia
Tomasz JASKULA
29 sept. 2011, 11:37:5129/09/2011
à paris...@googlegroups.com
TortoiseHg marche plutôt bien, par contre TortoiseGit c'est un peu artisanal par rapport à ce qu'on peut trouver sur Mac.
// Thomas
Le 29 septembre 2011 17:37, Tomasz JASKULA <tom...@jaskula.fr> a écrit :
TortoiseHg marche plutôt bien, par contre TortoiseGit c'est un peu artisanal par rapport à ce qu'on peut trouver sur Mac.// Thomas
Radwane
29 sept. 2011, 11:52:3929/09/2011
à altnetfr
Je suis d'accord avec ce que dis Guillaume sur TFS et puis le mode
connecté c'est assez horrible (qui utilise le mode readonly)... On
utilise également les Works Items et c'est peut être la partie la plus
intéressante de TFS, mais à quel prix...
@thomas pour les outils Git, il y a également GitExtensions et
GitSourceControl (utilisable directement avec VS)
On Sep 29, 5:24 pm, Bruno Baia <brb...@gmail.com> wrote:
> Bonjour,
>
> "Tortoise" fonctionne très bien avec Git et Mercurial.
> Et si tu as déjà utilisé TortoiseSVN ou TortoiseCVS auparavant, tu seras pas
> perdu.
>
> http://code.google.com/p/tortoisegit/http://tortoisehg.bitbucket.org/
>
> Cordialement,
> Bruno Baia
>
> Le 29 septembre 2011 09:54, Tomasz JASKULA <thomasv1...@hotmail.fr> a écrit
> >>> adaptés à notre projet.* Les développeurs ont pu s'approprier les
> >>> process de build, participer à leur évolution, etc. *
>
> >> <http://at2011.agiletour.org/en/at2011_rennes.html>
>
> >> 2011/9/28 danielcohenza...@gmail.com <i...@softfluent.com>
> ...
>
> read more »
connecté c'est assez horrible (qui utilise le mode readonly)... On
utilise également les Works Items et c'est peut être la partie la plus
intéressante de TFS, mais à quel prix...
@thomas pour les outils Git, il y a également GitExtensions et
GitSourceControl (utilisable directement avec VS)
On Sep 29, 5:24 pm, Bruno Baia <brb...@gmail.com> wrote:
> Bonjour,
>
> "Tortoise" fonctionne très bien avec Git et Mercurial.
> Et si tu as déjà utilisé TortoiseSVN ou TortoiseCVS auparavant, tu seras pas
> perdu.
>
>
> Cordialement,
> Bruno Baia
>
> Le 29 septembre 2011 09:54, Tomasz JASKULA <thomasv1...@hotmail.fr> a écrit
> :
>
>
>
>
>
>
>
> > Bon résumé. Pour ma part je commence de plus en plus à me désintéresser de
> > TFS dans le contexte de projets agile que je réalise. Le gestionnaire de
> > code sources centralisé c'est bon lorsque tout le monde est sur place ou a
> > un accès permanent au gestionnaire de codes sources.
>
> > Ma question est, quels sont vos outils préféré pour travailler avec Git ou
> > Mercurial sous windows bien sûr ;)? Pour le moment il n'y a rien de très
> > pratique que la ligne de commende.
>
> > // Thomas
>
>
>
>
>
>
>
>
> > Bon résumé. Pour ma part je commence de plus en plus à me désintéresser de
> > TFS dans le contexte de projets agile que je réalise. Le gestionnaire de
> > code sources centralisé c'est bon lorsque tout le monde est sur place ou a
> > un accès permanent au gestionnaire de codes sources.
>
> > Ma question est, quels sont vos outils préféré pour travailler avec Git ou
> > Mercurial sous windows bien sûr ;)? Pour le moment il n'y a rien de très
> > pratique que la ligne de commende.
>
> > // Thomas
>
> >>> process de build, participer à leur évolution, etc. *
>
> >> La simplicité (lire ergonomie, pas limitations) d'hudson/Jenkins permet à
> >> tous de se l'approprier et de le faire vivre. Sur mon projet TFS, il y avait
> >> un référent principal, mais même lui se débattait souvent avec, qui devait
> >> parfois se faire aider de personnes extérieures au projet. Nous n'avions pas
> >> de consultant Microsoft expert ;) et il ne devrait pas y en avoir besoin
> >> quelque part. L'expertise se joue sur l'intégration continue elle même
> >> (pipeline, management visuel, déploiement en continu, …), pas le produit
> >> (offre TFS, Hudson, …). Bref, un hudson est bien plus souple et simple, tout
> >> en étant très puissant, et pour un projet agile, ça n'a pas de prix.
> >> Ah aussi, nous avions une fuite mémoire sur TFS (problème non isolé,
> >> rencontré par d'autres).
>
> >> my quick 2 cents,
>
> >> Guillaume
> >> Développeur Agiliste passionné
> >> __________________________
> >> Twitter : @gcollic <http://twitter.com/gcollic>
> >> La simplicité (lire ergonomie, pas limitations) d'hudson/Jenkins permet à
> >> tous de se l'approprier et de le faire vivre. Sur mon projet TFS, il y avait
> >> un référent principal, mais même lui se débattait souvent avec, qui devait
> >> parfois se faire aider de personnes extérieures au projet. Nous n'avions pas
> >> de consultant Microsoft expert ;) et il ne devrait pas y en avoir besoin
> >> quelque part. L'expertise se joue sur l'intégration continue elle même
> >> (pipeline, management visuel, déploiement en continu, …), pas le produit
> >> (offre TFS, Hudson, …). Bref, un hudson est bien plus souple et simple, tout
> >> en étant très puissant, et pour un projet agile, ça n'a pas de prix.
> >> Ah aussi, nous avions une fuite mémoire sur TFS (problème non isolé,
> >> rencontré par d'autres).
>
> >> my quick 2 cents,
>
> >> Guillaume
> >> Développeur Agiliste passionné
> >> __________________________
>
> >> <http://at2011.agiletour.org/en/at2011_rennes.html>
>
> >> 2011/9/28 danielcohenza...@gmail.com <i...@softfluent.com>
>
> read more »
Simon Mourier
30 sept. 2011, 01:59:1230/09/2011
à paris...@googlegroups.com
La plupart des remarques que je lis ici sont plus orientées gestion des sources Distribuée vs non Distribuées, et n'ont rien à voir avec TFS spécifiquement. Il y a deux catégories pour ce genre de produit.
On ne peut pas comparer des choux et des carottes. Aujourd'hui le distribué est de plus en plus à la mode parce qu'il est plus facile à utiliser avec des développeurs répartis aux 4 coins du monde (genre projet open source à 25 sur codeplex/github, ...). Mais dans un contexte projet, sur un plateau, on peut très bien arriver à gérer des projets avec TFS. Ca demande en général plus d'organisation, et l'organisation, ça ne plait pas à tout le monde, car chacun préfère faire sa petite tambouille (il suffit de lire ce thread :-)
Ne choisissez pas TFS si vous voulez travailler en mode distribué, c'est assez évident.
2011/9/29 Radwane <hassen....@gmail.com>
Clément
30 sept. 2011, 03:43:1930/09/2011
à altnetfr
@radwanne tu parles du prix pour acheter TFS ? Si oui, je trouve perso
que ça ne coûte pas grand chose. Prix public (source
http://blogs.msdn.com/b/slange/archive/2010/01/26/it-s-official-vs-2010-branding-pricing.aspx)
: 499$ le serveur, les CAL sont incluses dans les versions avec MSDN
(1199$ pour une professional vs 799$ sans MSDN), il n'y a pas besoin
de CAL pour ceux qui utilisent seulement les Work Items via Web Access
(typiquement les utilisateurs/métier/MOA/client...).
Par rapport au sujet de ce thread qui partait de alternatives à TFS
sur l'intégration continue, et qui a dérivé en "TFS c'est
pourri" (raccourci certainement trop rapide), comme déjà dit, je
m'accorde avec vous que TFS est très limité concernant l'intégration
continue et la gestion de code source. Par contre, restreindre l'ALM à
l'intégration continue et au gestionnaire de code source est bien trop
limitatif (-> j'ouvre un autre thread).
Cdlt
Clément
> ...
>
> plus de détails »- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -
que ça ne coûte pas grand chose. Prix public (source
http://blogs.msdn.com/b/slange/archive/2010/01/26/it-s-official-vs-2010-branding-pricing.aspx)
: 499$ le serveur, les CAL sont incluses dans les versions avec MSDN
(1199$ pour une professional vs 799$ sans MSDN), il n'y a pas besoin
de CAL pour ceux qui utilisent seulement les Work Items via Web Access
(typiquement les utilisateurs/métier/MOA/client...).
Par rapport au sujet de ce thread qui partait de alternatives à TFS
sur l'intégration continue, et qui a dérivé en "TFS c'est
pourri" (raccourci certainement trop rapide), comme déjà dit, je
m'accorde avec vous que TFS est très limité concernant l'intégration
continue et la gestion de code source. Par contre, restreindre l'ALM à
l'intégration continue et au gestionnaire de code source est bien trop
limitatif (-> j'ouvre un autre thread).
Cdlt
Clément
>
> plus de détails »- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -
Radwane
30 sept. 2011, 06:37:5830/09/2011
à altnetfr
@clement non je parle de l'IC et SCM...
On Sep 30, 9:43 am, Clément <clement.bouill...@gmail.com> wrote:
> @radwanne tu parles du prix pour acheter TFS ? Si oui, je trouve perso
> que ça ne coûte pas grand chose. Prix public (sourcehttp://blogs.msdn.com/b/slange/archive/2010/01/26/it-s-official-vs-20...)
> ...
>
> read more »
On Sep 30, 9:43 am, Clément <clement.bouill...@gmail.com> wrote:
> @radwanne tu parles du prix pour acheter TFS ? Si oui, je trouve perso
>
> read more »
Philippe
30 sept. 2011, 06:50:2930/09/2011
à paris...@googlegroups.com
J'ai voulu m’insérer dans la conversation mais mon (long) message s'est perdu dans les méandres d'Internet et j'ai ni le temps, ni l'envie de le reproduire :(
Je vais donc m'appuyer sur une des phrases du dernier message de Simon pour exprimer l'une des idée de ce précédent message :
"Mais dans un contexte projet, sur un plateau, on peut très bien arriver à gérer des projets avec TFS."
C'est tout à fait çà, on y arrive mais il faut se forcer.
Je crois qu'avec TFS (et les autres controleurs de version pré-DVCS), apprendre à utiliser ces outils revient à se limiter et s'adapter aux "petites" contrariétés. Alors qu'avec les DVCS, apprendre à les utiliser revient à s'ouvrir le champs des possibles! (Je vous avais préparer une longue liste des contraintes de tfs et des avantages des dvcs que je ne reproduirais pas pour l'instant... bisect, late branching,...)
Et il faut bien comprendre que le controleur de code source, pour un développeur est, ce avec quoi on travaille toute la journée et un outil "usant" est inacceptable. Et c'est normal qu'on râle...
Comme je ne veux pas que mon message ne s'attaque qu'à la gestion de conf, je retranscris rapidement l'essence de mon 1er message (mais en moins nuancé, donc :( )
En ce qui concerne l'intégration continue, l'utilisation de jenkins me semble à la fois en temps de mise en place et d'administration et de fonctionnalité une largement meilleure solution.
Le seul leger avantage serait l'ALM mais de ce côtélà, la plus-value ne me parait pas suffisante. Je préfère également Jira et sans avoir testé, une solution telle que Ice Scrum me parait à première vu intéressante...
Je vais donc m'appuyer sur une des phrases du dernier message de Simon pour exprimer l'une des idée de ce précédent message :
"Mais dans un contexte projet, sur un plateau, on peut très bien arriver à gérer des projets avec TFS."
Je crois qu'avec TFS (et les autres controleurs de version pré-DVCS), apprendre à utiliser ces outils revient à se limiter et s'adapter aux "petites" contrariétés. Alors qu'avec les DVCS, apprendre à les utiliser revient à s'ouvrir le champs des possibles! (Je vous avais préparer une longue liste des contraintes de tfs et des avantages des dvcs que je ne reproduirais pas pour l'instant... bisect, late branching,...)
Et il faut bien comprendre que le controleur de code source, pour un développeur est, ce avec quoi on travaille toute la journée et un outil "usant" est inacceptable. Et c'est normal qu'on râle...
Comme je ne veux pas que mon message ne s'attaque qu'à la gestion de conf, je retranscris rapidement l'essence de mon 1er message (mais en moins nuancé, donc :( )
En ce qui concerne l'intégration continue, l'utilisation de jenkins me semble à la fois en temps de mise en place et d'administration et de fonctionnalité une largement meilleure solution.
Le seul leger avantage serait l'ALM mais de ce côtélà, la plus-value ne me parait pas suffisante. Je préfère également Jira et sans avoir testé, une solution telle que Ice Scrum me parait à première vu intéressante...
Philippe
29 sept. 2011, 19:16:3429/09/2011
à altnetfr
Je m'insère dans la discussion...
Mon avis est que ce qui différencie les DVCS avec les autres outils de
gestion, c'est que pour les derniers, il faut passer du temps pour se
contraindre à leur utilisation alors que pour les premiers, il faut
passer du temps pour en sortir avec de nouvelles possibilités.
Les uns il faut s'habituer à leur limitations, les autres à leurs
nouveaux paradigmes.
Que penser des limitations de :
- early branching (et tous les problèmes de merge et de gestion de
branche que ça introduit). Qui a fait une 2ème branche dans sa vie
avec TFS après en avoir mergée une 1ère? Ou corrigé un bug sur
plusieurs branches...
- changement entre 2 versions du projet lourdingue
- shelving peu performant (pas d'historique)
- quelqu'un m'explique pourquoi TFS ne merge AUCUN fichier
automatiquement!?! Il faut tout le temps lui dire "Oui, vas-y, t'as le
droit". Ils ont pas confiance en leur algo de merge...
- c'est quoi ce mode connecté/déconnecté !?! le readonly? baser une
solution sur le readonly... o_O
- ...
et des fonctionnalités :
- bisection
- les workflows. Si un mec arrive à faire çà (
http://nvie.com/posts/a-successful-git-branching-model/ ) avec tfs
sans se suicider, je lui paye une bière!
- commit local et réorganisation des commits (plus jamais d'historique
pourri par des commits foireux).
- rapidité ( sur notre projet, j'attends 13s l'extraction d'un fichier
du serveur TFS :( )
- visualisation graphiques des branches
- cherry picking aisée
- administartion (presque) inexistante
- backup gratuit
- création d'un nouveau dépot en 5 secondes (montre en main) et sans
avoir besoin nécessairement de serveur. Et pour commencer certains
projet, ça c'est bien! Souplesse, agilité!!
- plus grande facilité de mise en ouevre de la revue de code
- un nombre impression de petite amélioration qui font qu'on se sent à
l'aise (aide à la saisie des commentaires de commit, visualisation des
différences plus parlantes, recherche facile dans l'historique d'un
bout de code...)
- ...
Bénéficier (un peu) des workitems est cher payé pour supporter une
intégration continue sans réelle plus-value et un controleur de code
source usant, contraignant et fade de TFS au quotidien.... et en tant
que développeur, je pense que le controleur de code source doit être
choisi avec soin étant donné qu'on passe toute une journée à
l'utiliser!
Les 2 seuls avantages que j'ai jamais vu à TFS sont la gestion d'un
projet agile (mais je préfère Jira. Et icescrum peut être une bonne
solution --que j'ai pas testé--) et l'intégration des différentes
briques mais vu le temps qu'on passe à administrer tfs et mettre tout
en place, j'ai fini par croire que ça aurait été plus vite avec un
jenkins.
Je crois qu'avec ce produit, j'ai perdu mes illusions.
PS : Et je vous ai pas parlé de prix pour avoir un truc moins bien :)
Mon avis est que ce qui différencie les DVCS avec les autres outils de
gestion, c'est que pour les derniers, il faut passer du temps pour se
contraindre à leur utilisation alors que pour les premiers, il faut
passer du temps pour en sortir avec de nouvelles possibilités.
Les uns il faut s'habituer à leur limitations, les autres à leurs
nouveaux paradigmes.
Que penser des limitations de :
- early branching (et tous les problèmes de merge et de gestion de
branche que ça introduit). Qui a fait une 2ème branche dans sa vie
avec TFS après en avoir mergée une 1ère? Ou corrigé un bug sur
plusieurs branches...
- changement entre 2 versions du projet lourdingue
- shelving peu performant (pas d'historique)
- quelqu'un m'explique pourquoi TFS ne merge AUCUN fichier
automatiquement!?! Il faut tout le temps lui dire "Oui, vas-y, t'as le
droit". Ils ont pas confiance en leur algo de merge...
- c'est quoi ce mode connecté/déconnecté !?! le readonly? baser une
solution sur le readonly... o_O
- ...
et des fonctionnalités :
- bisection
- les workflows. Si un mec arrive à faire çà (
http://nvie.com/posts/a-successful-git-branching-model/ ) avec tfs
sans se suicider, je lui paye une bière!
- commit local et réorganisation des commits (plus jamais d'historique
pourri par des commits foireux).
- rapidité ( sur notre projet, j'attends 13s l'extraction d'un fichier
du serveur TFS :( )
- visualisation graphiques des branches
- cherry picking aisée
- administartion (presque) inexistante
- backup gratuit
- création d'un nouveau dépot en 5 secondes (montre en main) et sans
avoir besoin nécessairement de serveur. Et pour commencer certains
projet, ça c'est bien! Souplesse, agilité!!
- plus grande facilité de mise en ouevre de la revue de code
- un nombre impression de petite amélioration qui font qu'on se sent à
l'aise (aide à la saisie des commentaires de commit, visualisation des
différences plus parlantes, recherche facile dans l'historique d'un
bout de code...)
- ...
Bénéficier (un peu) des workitems est cher payé pour supporter une
intégration continue sans réelle plus-value et un controleur de code
source usant, contraignant et fade de TFS au quotidien.... et en tant
que développeur, je pense que le controleur de code source doit être
choisi avec soin étant donné qu'on passe toute une journée à
l'utiliser!
Les 2 seuls avantages que j'ai jamais vu à TFS sont la gestion d'un
projet agile (mais je préfère Jira. Et icescrum peut être une bonne
solution --que j'ai pas testé--) et l'intégration des différentes
briques mais vu le temps qu'on passe à administrer tfs et mettre tout
en place, j'ai fini par croire que ça aurait été plus vite avec un
jenkins.
Je crois qu'avec ce produit, j'ai perdu mes illusions.
PS : Et je vous ai pas parlé de prix pour avoir un truc moins bien :)
in...@softfluent.com
1 oct. 2011, 04:27:5801/10/2011
à altnetfr
Philippe mets le doigt sur un point important.
Il y a d'un côté une approche la plus complète possible en terme de
fonctionnalités, avec un enjeu de cadrer l'utilisation.
De l'autre une approche structurante, qui eut parfois poser l'enjeu de
"s'ouvrir le champs des possibles" comme Philippe le dit.
Pour avoir observé des centaines de projets sur le terrain, le besoin
est souvent mû par cette volonté de "s'ouvrir le champ des possibles"
au niveau du développeur, sans que cela soit réellement justifié par
les besoins du projet. Alors, ok, on est dans un groupe de
développeurs ici, et donc on a envie de faire les trucs les plus
sophistiqués possibles, mais il faut tout de même se poser la question
de la pertinence réelle d'ouvrir ce champ.
La complexité induite est rarement mesurée, et souvent, ça n'intéresse
même pas le développeur, mais il y a tout de même un sacré impact
économique. Sur les projets, personnellement, je vois plutôt un enjeu
d'arriver à réduire le champ des possibles, et pas seulement en
matière de gestion de source ! Les plates-formes telles que Java
et .NET sont justement trop ouvertes, et il n'y a pas 2 projets qui
les utilisent de la même façon.
Pour revenir au sujet, le besoin réel de gestion de sources distribué
est somme toute rare dans les vrais projets d'entreprise, si on ne
travaille pas chez Dassault Systèmes qui a 2000 développeurs répartis
géographiquement.
Et on peut éviter pas mal de besoin de "merge" en organisant
correctement le code source. Donc certes, le merge TFS est moins
abouti que les merge de produits historiques qui ont 20 ans d'age,
c'est une évidence, mais avant de se lancer là-dedans,
personnellement, je m'assurerais de mesurer toutes les conséquences en
terme de compétences d'équipe et de capacité à faire durer la méthode
lorsque le le projet aura 5 ans de développement, 10 versions dans la
nature et 1 million de lignes de code à maintenir...
Daniel
Il y a d'un côté une approche la plus complète possible en terme de
fonctionnalités, avec un enjeu de cadrer l'utilisation.
De l'autre une approche structurante, qui eut parfois poser l'enjeu de
"s'ouvrir le champs des possibles" comme Philippe le dit.
Pour avoir observé des centaines de projets sur le terrain, le besoin
est souvent mû par cette volonté de "s'ouvrir le champ des possibles"
au niveau du développeur, sans que cela soit réellement justifié par
les besoins du projet. Alors, ok, on est dans un groupe de
développeurs ici, et donc on a envie de faire les trucs les plus
sophistiqués possibles, mais il faut tout de même se poser la question
de la pertinence réelle d'ouvrir ce champ.
La complexité induite est rarement mesurée, et souvent, ça n'intéresse
même pas le développeur, mais il y a tout de même un sacré impact
économique. Sur les projets, personnellement, je vois plutôt un enjeu
d'arriver à réduire le champ des possibles, et pas seulement en
matière de gestion de source ! Les plates-formes telles que Java
et .NET sont justement trop ouvertes, et il n'y a pas 2 projets qui
les utilisent de la même façon.
Pour revenir au sujet, le besoin réel de gestion de sources distribué
est somme toute rare dans les vrais projets d'entreprise, si on ne
travaille pas chez Dassault Systèmes qui a 2000 développeurs répartis
géographiquement.
Et on peut éviter pas mal de besoin de "merge" en organisant
correctement le code source. Donc certes, le merge TFS est moins
abouti que les merge de produits historiques qui ont 20 ans d'age,
c'est une évidence, mais avant de se lancer là-dedans,
personnellement, je m'assurerais de mesurer toutes les conséquences en
terme de compétences d'équipe et de capacité à faire durer la méthode
lorsque le le projet aura 5 ans de développement, 10 versions dans la
nature et 1 million de lignes de code à maintenir...
Daniel
Philippe
3 oct. 2011, 05:00:4103/10/2011
à altnetfr
Daniel,
juste pour pas partir dans des faux débats, je tiens à préciser que ce
n'est pas parce que tu utilises un outils DVCS que tu est obligé de
l'utiliser pour faire un workflow complexe.
Beaucoup de gens l'utilise avec un workflow centralisé comme des
outils tfs, svn,... http://fr.whygitisbetterthanx.com/#any-workflow
L'utilité dans ce cas, c'est qu'avec la fonctionnalité DVCS, de
nombreuses fonctionnalités qui facilitent la vie sont "arrivées" avec.
C'est ça que j'appelais "s'ouvrir le champs des possibles". Pas
besoin de bosser chez Dassault. De plus, ces outils étant moins lourd
à installer, il est même moins difficile à mettre en oeuvre même sur
des petits projets!
J'ai pas compris le passage " le merge TFS est moins abouti que les
merge de produits historiques qui ont 20 ans d'age". J'espère que TFS
(un outil récent) gère mieux les merges que des aussi vieux outils!!!
Pour information, les algo de merge sont identiques depuis plus de
20ans (!!) et les seuls caractéristiques qui font que les DVCS sont
meilleurs que les autres outils sont le "late branching" et surtout le
3-way merge (on prend comme référence, un 3ème fichier qui est le plus
proche parent entre les 2 fichiers à merger ce qui permet de mieux
détecter les modifications). Ce que ne gère pas TFS et qui donc oblige
beaucoup plus de merges manuels (assez source d'erreur car on ne
comprends pas tout le temps PARFAITEMENT les modifications faites par
un autre développeur). BONUS : On peut néanmoins s'approcher de ce 3-
way merge en utilisant p4merge ( http://blog.zobie.com/2009/04/using-p4merge-with-team-foundation-server/
) . Que je conseille fortement!!!!!
PS : Mais bon, c'est vrai qu'il faut y avoir goûté pour comprendre ;)
Certains disent qu'on ne peut revenir en arrière après y avoir goûté.
Moi, je dis que c'est possible, mais on peste....
juste pour pas partir dans des faux débats, je tiens à préciser que ce
n'est pas parce que tu utilises un outils DVCS que tu est obligé de
l'utiliser pour faire un workflow complexe.
Beaucoup de gens l'utilise avec un workflow centralisé comme des
outils tfs, svn,... http://fr.whygitisbetterthanx.com/#any-workflow
L'utilité dans ce cas, c'est qu'avec la fonctionnalité DVCS, de
nombreuses fonctionnalités qui facilitent la vie sont "arrivées" avec.
C'est ça que j'appelais "s'ouvrir le champs des possibles". Pas
besoin de bosser chez Dassault. De plus, ces outils étant moins lourd
à installer, il est même moins difficile à mettre en oeuvre même sur
des petits projets!
J'ai pas compris le passage " le merge TFS est moins abouti que les
merge de produits historiques qui ont 20 ans d'age". J'espère que TFS
(un outil récent) gère mieux les merges que des aussi vieux outils!!!
Pour information, les algo de merge sont identiques depuis plus de
20ans (!!) et les seuls caractéristiques qui font que les DVCS sont
meilleurs que les autres outils sont le "late branching" et surtout le
3-way merge (on prend comme référence, un 3ème fichier qui est le plus
proche parent entre les 2 fichiers à merger ce qui permet de mieux
détecter les modifications). Ce que ne gère pas TFS et qui donc oblige
beaucoup plus de merges manuels (assez source d'erreur car on ne
comprends pas tout le temps PARFAITEMENT les modifications faites par
un autre développeur). BONUS : On peut néanmoins s'approcher de ce 3-
way merge en utilisant p4merge ( http://blog.zobie.com/2009/04/using-p4merge-with-team-foundation-server/
) . Que je conseille fortement!!!!!
PS : Mais bon, c'est vrai qu'il faut y avoir goûté pour comprendre ;)
Certains disent qu'on ne peut revenir en arrière après y avoir goûté.
Moi, je dis que c'est possible, mais on peste....
Karim Aouadi
3 oct. 2011, 08:01:0403/10/2011
à paris...@googlegroups.com
Bonjour à tous, j'interviens que très rarement, mais je n'ai pas réussi à me retenir ;)
Ce que tu dis Daniel est symptomatique d'une informatique qui perd:
Pour moi la complexité ne se réduit pas, elle s'affronte, pour apprendre.
Tu parles de solutions trop ouverte et donc réduire le champ des possibles.
Moi je dis, restons ouvert, les solutions a nos problèmes peuvent venir d'ailleurs.......
Ta construction intellectuelle, peut paraitre élégante pour certains, voir très bien articulé, mais elle est fondée sur un modèle complètement faux.
Tu as surement suivi beaucoup de projet je n'en doute pas mais si tu faisais de l'agile tu ne tiendrais pas ce discours
Malheureusement pour pouvoir te prouver que tu te trompes, il me faudrait tout un livre.... ;(
Ensuite lorsque tu écris que Git c'est seulement pour des projets décentralisé, tu ne dois pas faire de tests fonctionnels et d'intégration et du déploiement sur des plateforme de type heroku.
Integration continue en mode centralisé a atteint ces limites, proposer au developpeur de ce créer une branch local en récupérant la mise a jour de leur source du projet et lancer en local tes tests d'intégrations continue, possède l'avantage au developpeur d'identifier des problèmes de déploiement, et s'intéresser aux environnement de production.
Git nous propose aussi d'autre outils que le mode décentralisé, ensuite faire un merge avec CVS SVN et GIT, c'est le jour et la nuit.
On peut imaginer toutes les solutions pour réduire la complexité d'une mise en production, si la solution réside dans un process ou une philosophie tentant de réduire les incertitudes, c'est la garantie de l'échec d'un déploiement et des accidents en production en cascade.
Comment ces startups americain, Groupon, Living Social, Twillio, Spotity etc....peuvent faire au maximum 12 mises en production par jour?
En France nous avons trop intellectualisé nos problèmes, chercher à mettre l'intelligence du développement dans le process.(trop de chef de projet) au lieu de chercher préparer nos developpeurs à mieux affronter les défis.
Le résultat, c'est aucun leader du logiciel,, aucune innovation et pour les plus talentueux d'entre nous un départ forcé à l'étranger, et le developpement en Offshore en Tunisie et au Maroc
Pour ceux que ça interesse je les invite a lire Lean Startup, qui parle justement de ces sujets.
Cdlt Karim Aouadi
in...@softfluent.com
3 oct. 2011, 09:45:3403/10/2011
à altnetfr
Karim,
Il me semble qu'il serait préférable d'éviter les jugements de valeur,
et de parler d'informatique qui perd pour qualifier ce qui échappe à
la "religion de l'agile".
Le point qui me choque le plus dans certaines discussions est la
vision unique du monde selon laquelle ce qui ne serait pas agile ou
lean serait forcément mal ou inefficace.
Désolé de te le dire Karim, mais il n'y a pas qu'une vérité.
Malgré mon expérience, je ne me permettrai pas de dire que tu te
trompes, ni en un livre, ni en un message.
Et ce n'est pas faute d'avoir vu des projets agiles et non agiles,
c'est juste parce que je respecte le point de vue de chacun.
Il y a des outils, des approches et des façons de faire, et l'objectif
d'une communauté est de les partager, non pas pour imposer son point
de vue, mais pour l'exprimer, chacun en tirant ses propres
conclusions.
Si la gestion de source centralisée était une aberration, pourquoi
donc y aurait-il donc les 2 approches
Cf http://fr.wikipedia.org/wiki/Gestion_de_versions
Sans contester le mérite de la gestion de sources décentralisées par
rapport à un besoin en ce sens, je dis juste que la simplicité a aussi
du mérite.
Pour avoir audité rien que l'année dernière une demi-douzaine de
startups qui se sont pris pour Groupon, Living Social ou Spotify, je
dis qu'il faut juste faire attention à maitriser la complexité.
Alors se dire que le développeur pourra l'affronter juste parce qu'il
est agile, c'est purement et simplement suicidaire, surtout dans un
pays où l'essentiel des développeurs a moins de 10 ans d'expérience.
Pour revenir à la discussion initiale, TFS a son rôle à jouer dans une
gestion de sources centralisée.
Si on est convaincu que la gestion de source centralisée est un mal,
il est évident qu'on ne peut pas aimer TFS
Mais ce n'est pas le problème de savoir si c'est un bon produit ou
pas, c'est le problème du choix.
Si on n'aime que les blondes, il est possible qu'on n'aime pas
Virginie Ledoyen.
Désolé, mais moi je trouve qu'il y a des blondes et des brunes qui
peuvent être jolies.
Mes 0,02 Euros
Daniel
> Le 1 octobre 2011 10:27, danielcohenza...@gmail.com <i...@softfluent.com> a
Il me semble qu'il serait préférable d'éviter les jugements de valeur,
et de parler d'informatique qui perd pour qualifier ce qui échappe à
la "religion de l'agile".
Le point qui me choque le plus dans certaines discussions est la
vision unique du monde selon laquelle ce qui ne serait pas agile ou
lean serait forcément mal ou inefficace.
Désolé de te le dire Karim, mais il n'y a pas qu'une vérité.
Malgré mon expérience, je ne me permettrai pas de dire que tu te
trompes, ni en un livre, ni en un message.
Et ce n'est pas faute d'avoir vu des projets agiles et non agiles,
c'est juste parce que je respecte le point de vue de chacun.
Il y a des outils, des approches et des façons de faire, et l'objectif
d'une communauté est de les partager, non pas pour imposer son point
de vue, mais pour l'exprimer, chacun en tirant ses propres
conclusions.
Si la gestion de source centralisée était une aberration, pourquoi
donc y aurait-il donc les 2 approches
Cf http://fr.wikipedia.org/wiki/Gestion_de_versions
Sans contester le mérite de la gestion de sources décentralisées par
rapport à un besoin en ce sens, je dis juste que la simplicité a aussi
du mérite.
Pour avoir audité rien que l'année dernière une demi-douzaine de
startups qui se sont pris pour Groupon, Living Social ou Spotify, je
dis qu'il faut juste faire attention à maitriser la complexité.
Alors se dire que le développeur pourra l'affronter juste parce qu'il
est agile, c'est purement et simplement suicidaire, surtout dans un
pays où l'essentiel des développeurs a moins de 10 ans d'expérience.
Pour revenir à la discussion initiale, TFS a son rôle à jouer dans une
gestion de sources centralisée.
Si on est convaincu que la gestion de source centralisée est un mal,
il est évident qu'on ne peut pas aimer TFS
Mais ce n'est pas le problème de savoir si c'est un bon produit ou
pas, c'est le problème du choix.
Si on n'aime que les blondes, il est possible qu'on n'aime pas
Virginie Ledoyen.
Désolé, mais moi je trouve qu'il y a des blondes et des brunes qui
peuvent être jolies.
Mes 0,02 Euros
Daniel
Guillaume Collic
3 oct. 2011, 10:25:2703/10/2011
à paris...@googlegroups.com
Daniel,
Concernant la forme, je te rejoins sur le respect. Je tacherais d'y faire plus gaffe, un jugement arrivant vite.
Concernant le fond, je te rejoins aussi sur l'importance de la simplicité. Mais, c'est justement le manque de simplicité que je reprocherais à TFS, donc cela m'étonne. Git ou Hudson permettent de faire des choses complexes, mais aussi des choses simples beaucoup plus simplement que TFS : que ce soit la gestion centralisée (car ce n'est pas une aberration au niveau du workflow projet), ou un build qui suit les standards de la plateforme. Ce sont des outils qui demandent beaucoup moins à être "affrontés" que TFS. Si j'ai manqué quelque chose, n'hésite pas à approfondir ce qui est plus simple dans TFS que je ne vois pas. L'intégration des outils ? quoique…
Merci de partager tes avis ;)
Ps : la discussion initiale pour moi, malgré le titre plus vaste, c'est : quels ecueils attendre avec git et hudson sur de gros projet .NET, que je n'aurais pas vu sur de gros projet Java ou de petits projets .NET.
Philippe
3 oct. 2011, 10:30:4703/10/2011
à altnetfr
Complètement d'accord avec le dernier message de Guillaume. Avec TFS,
il faut se battre chaque jour :(
il faut se battre chaque jour :(
Philippe
3 oct. 2011, 10:39:1403/10/2011
à altnetfr
Ah, et pour répondre à daniel, s'il existe les outils de gestion de
version centralisé et décentralisé, c'est pour moi purement
historique.
Les DVCS, c'est assez récent et sont là pour pallier à des problèmes
des centralisés. Leur utilisation finira par s'estomper, mais comme
cvs, dans plus de 20 ans :)
De toute façon, on sera surement "bientôt" tous d'accord car TFS
devrait évoluer pour devenir un DVCS (qui est clairement l'avenir)
http://www.infoq.com/news/2011/08/tfs-modify-merge-commit
Mais ça serait pas encore pour la prochaine version, même si il y aura
du mieux :(
version centralisé et décentralisé, c'est pour moi purement
historique.
Les DVCS, c'est assez récent et sont là pour pallier à des problèmes
des centralisés. Leur utilisation finira par s'estomper, mais comme
cvs, dans plus de 20 ans :)
De toute façon, on sera surement "bientôt" tous d'accord car TFS
devrait évoluer pour devenir un DVCS (qui est clairement l'avenir)
http://www.infoq.com/news/2011/08/tfs-modify-merge-commit
Mais ça serait pas encore pour la prochaine version, même si il y aura
du mieux :(
Karim Aouadi
3 oct. 2011, 10:44:5503/10/2011
à paris...@googlegroups.com
Je ne te reproche qu'une seule chose, les personnes qui s'exprime sur ce fil pose de bonnes questions sur TFS et son cout qui parait pour certains acceptable et d'autre trop cher, il parle de leur expérience, ils s'enthousiasme pour GIT parce qu'il l'utilise au quotidien, il a fait ces preuves, il est gratuit,
Leur argument est basé sur leur expérience personnelle, si certains peuvent avoir du mal a faire passer l'idée, l'important c'est d'y percevoir l'intention, par contre que tu te sers d'une construction intellectuelle pour réduire leur retour d'expérience peu concluant, je ne suis pas d'accord.
Si tu te servais de Git régulièrement et que tu parlerais de ton retour d'expérience plutôt négative sur le sujet, je n'aurais même pas écrit mon mail précèdent.
Je ne parle pas de jugement de valeur, je parle simplement de ta façon de le faire.
j'ai même aucun souci pour que tu mes traites d'intégriste agile, je prends même ceci comme un compliment.
Apres j'imagine que certains pensent que j'exagère, je fais du jugement de valeur, c'est plutôt ta façon de faire qui me gene
Si je dois être exclu du groupe pour m'être opposer à ta façon de faire pas de souci.....mais sincèrement j'aimerai que ce groupe se bouge.....et il y a des gens qui essaie de sortir des sentiers battus, je les encourage à continuer, à montrer vos désaccords, et mais surtout à rester loyale.
A tous cordialement Karim Aouadi
in...@softfluent.com
3 oct. 2011, 11:57:3503/10/2011
à altnetfr
C'est là que notre approche diffère.
Si je me servais de Git régulièrement, je suis quasiment certain que
je n'en parlerai pas négativement.
Blâmer les outils est souvent un moyen d'éviter de remettre en cause
ce qu'on en fait.
Et c'est bien mon point.
Daniel
> Le 3 octobre 2011 15:45, danielcohenza...@gmail.com <i...@softfluent.com> a
Si je me servais de Git régulièrement, je suis quasiment certain que
je n'en parlerai pas négativement.
Blâmer les outils est souvent un moyen d'éviter de remettre en cause
ce qu'on en fait.
Et c'est bien mon point.
Daniel
> écrit :
>
>
>
>
>
>
>
> > Karim,
>
> > Il me semble qu'il serait préférable d'éviter les jugements de valeur,
> > et de parler d'informatique qui perd pour qualifier ce qui échappe à
> > la "religion de l'agile".
> > Le point qui me choque le plus dans certaines discussions est la
> > vision unique du monde selon laquelle ce qui ne serait pas agile ou
> > lean serait forcément mal ou inefficace.
>
> > Désolé de te le dire Karim, mais il n'y a pas qu'une vérité.
> > Malgré mon expérience, je ne me permettrai pas de dire que tu te
> > trompes, ni en un livre, ni en un message.
> > Et ce n'est pas faute d'avoir vu des projets agiles et non agiles,
> > c'est juste parce que je respecte le point de vue de chacun.
>
> > Il y a des outils, des approches et des façons de faire, et l'objectif
> > d'une communauté est de les partager, non pas pour imposer son point
> > de vue, mais pour l'exprimer, chacun en tirant ses propres
> > conclusions.
> > Si la gestion de source centralisée était une aberration, pourquoi
> > donc y aurait-il donc les 2 approches
> > Cfhttp://fr.wikipedia.org/wiki/Gestion_de_versions
>
>
>
>
>
>
>
> > Karim,
>
> > Il me semble qu'il serait préférable d'éviter les jugements de valeur,
> > et de parler d'informatique qui perd pour qualifier ce qui échappe à
> > la "religion de l'agile".
> > Le point qui me choque le plus dans certaines discussions est la
> > vision unique du monde selon laquelle ce qui ne serait pas agile ou
> > lean serait forcément mal ou inefficace.
>
> > Désolé de te le dire Karim, mais il n'y a pas qu'une vérité.
> > Malgré mon expérience, je ne me permettrai pas de dire que tu te
> > trompes, ni en un livre, ni en un message.
> > Et ce n'est pas faute d'avoir vu des projets agiles et non agiles,
> > c'est juste parce que je respecte le point de vue de chacun.
>
> > Il y a des outils, des approches et des façons de faire, et l'objectif
> > d'une communauté est de les partager, non pas pour imposer son point
> > de vue, mais pour l'exprimer, chacun en tirant ses propres
> > conclusions.
> > Si la gestion de source centralisée était une aberration, pourquoi
> > donc y aurait-il donc les 2 approches
Clément
4 oct. 2011, 16:45:5904/10/2011
à altnetfr
@Karim : entièrement d'accord avec toi sur la "sur-processisation"
avec plein de chefs de projet dans tous les sens...cependant, on ne
peut pas partir exactement dans l'autre direction, i.e sans processus,
quoiqu'on fasse, il y a finalement des processus, même en Agile, peut-
être souvent implicites...
Un autre point est qu'on peut avoir une approche Agile qui ne dénigre
pas les processus et qui en donne la responsabilité à toute l'équipe
de les construire et de les faire évoluer, tout en les outillant de
façon adéquate (mon point de vue est qu'on processus "papier" ne va
durer bien longtemps...), et dans ce cas la première valeur du
manifeste prend tout son sens dans la dualité entre l'assertion de
gauche (individualités et interactions) et celle de droite (outils et
processus). C'est aussi ce que souligne Radwanne dans l'autre thread
plus large sur l'ALM ("c'est à l'équipe de définir sa marche à suivre
et à l'améliorer régulièrement")
@Daniel : je suis entièrement d'accord avec "Blâmer les outils est
ce qu'on a besoin de faire en terme SCM et CI...et éventuellement,
faut regarder ce qu'on peut faire en terme d'intégration à TFS (partie
WI) d'autres solutions de CI et SCM, pour ne pas jeter le bébé avec
l'eau du bain...
On 3 oct, 17:57, "danielcohenza...@gmail.com" <i...@softfluent.com>
wrote:
avec plein de chefs de projet dans tous les sens...cependant, on ne
peut pas partir exactement dans l'autre direction, i.e sans processus,
quoiqu'on fasse, il y a finalement des processus, même en Agile, peut-
être souvent implicites...
Un autre point est qu'on peut avoir une approche Agile qui ne dénigre
pas les processus et qui en donne la responsabilité à toute l'équipe
de les construire et de les faire évoluer, tout en les outillant de
façon adéquate (mon point de vue est qu'on processus "papier" ne va
durer bien longtemps...), et dans ce cas la première valeur du
manifeste prend tout son sens dans la dualité entre l'assertion de
gauche (individualités et interactions) et celle de droite (outils et
processus). C'est aussi ce que souligne Radwanne dans l'autre thread
plus large sur l'ALM ("c'est à l'équipe de définir sa marche à suivre
et à l'améliorer régulièrement")
@Daniel : je suis entièrement d'accord avec "Blâmer les outils est
souvent un moyen d'éviter de remettre en cause ce qu'on en fait."
@radwane par rapport au prix à payer (CI et SCM), du coup ça dépend de
ce qu'on a besoin de faire en terme SCM et CI...et éventuellement,
faut regarder ce qu'on peut faire en terme d'intégration à TFS (partie
WI) d'autres solutions de CI et SCM, pour ne pas jeter le bébé avec
l'eau du bain...
On 3 oct, 17:57, "danielcohenza...@gmail.com" <i...@softfluent.com>
wrote:
Clément
4 oct. 2011, 17:12:2304/10/2011
à altnetfr
Pour rebondir, même si je vous disais ne pas voir d'intérêt immédiat à
changer de CI et de SCM, je suis curieux de voir ce qu'on pourrait
faire.
Côté CI, pour ma part, je n'ai pas non plus d'experts MS dans mon
équipe, et surtout on est resté sur la solution à base de MSBuild
(conseil: fuyez comme la peste la solution à base de workflow de
TFS2010 !) Sinon, ce qui manque par rapport à un Hudson/Jenkins, c'est
l'aspect reporting sur les builds qui est très pauvre dans TFS. Dans
notre cas, nous utilisons principalement un indicateur, c'est l'état
du build, après on regarde la log si erreur.
Quels sont les indicateurs dont vous ne vous passeriez pas sur votre
build ?
Voyez-vous d'autres points concernant la CI ? (approfondissez l'aspect
compliqué par rapport à la configuration...j'ai du mal à voir)
En terme d'intégration, il n'y a que la récupération des Work Items
liés aux ChangeSets pris en compte dans le build qui serait à
reprendre, avec modification de ceux-ci pour les tagguer avec la
version du build....
Côté SCM, je n'ai jamais eu de problèmes de performances (@yann ?)
pourtant notre solution est assez volumineuse il me semble. Par contre
je confirme le cauchemar des merges, mais rien de bien pire qu'avec
SVN finalement, et les broutilles du genre check-in d'un fichier
affichant tous les pending, affichage de tous les conflits avant auto-
resolve...ne me semble pas entraver la productivité, contrairement aux
merges de branches...mais ça a un avantage, c'est de se forcer à faire
le moins de branches possible :).
Concernant le cherry picking, je ne l'ai même jamais utilisé sur TFS,
ça me paraît hasardeux au possible : comment s'assurer qu'un check-in
fait après X autres sur la même branche ne pende pas d'un de ces X et
que le cherry picking de ce check-in serait du coup fiable (si tant
est qu'il compile !)...
Concernant le workflow "compliqué" proposé dans un lien par Philippe,
on fait exactement ça et avec TFS sans se tirer de balles (sauf les
merges qui sont peut-être un peu plus douloureux...), à moins que je
n'ai rien compris...
L'administration TFS est faite par nos propres soins et ça n'est pas
franchement compliqué, si on y passe 2h par mois, c'est déjà
beaucoup...
Les fonctionnalités de check-in en local et de bisection me paraîssent
clairement super intéressantes.
Pour l'intégration d'un autre SCM à la place du Source Control TFS, je
vois les points d'attention suivants :
- les check-in policies pour se rappeler de faire les choses bien (et
non pas pour fliquer !) -> hook script j'imagine ?
- le lien avec les Work Items, bien utile pour retracer des modifs,
donner plus d'éléments contextuels au check-in (tâches, User Story...)
-> des propositions dans un autre outil sans faire 15 manipulations
manuelles pour retrouver l'info ?
Tout ça me donne bien envie d'en parler de vive voix, par exemple dans
un format OpenSpace pour qu'il y ait un maximum d'interactions et
d'oppositions, avec peut-être 2 petites présentations de 15 minutes
chacune pour lancer les débats (une sur TFS et sur un DVCS...)...qu'en
pensez-vous ?
Clément
> ...
>
> plus de détails »
changer de CI et de SCM, je suis curieux de voir ce qu'on pourrait
faire.
Côté CI, pour ma part, je n'ai pas non plus d'experts MS dans mon
équipe, et surtout on est resté sur la solution à base de MSBuild
(conseil: fuyez comme la peste la solution à base de workflow de
TFS2010 !) Sinon, ce qui manque par rapport à un Hudson/Jenkins, c'est
l'aspect reporting sur les builds qui est très pauvre dans TFS. Dans
notre cas, nous utilisons principalement un indicateur, c'est l'état
du build, après on regarde la log si erreur.
Quels sont les indicateurs dont vous ne vous passeriez pas sur votre
build ?
Voyez-vous d'autres points concernant la CI ? (approfondissez l'aspect
compliqué par rapport à la configuration...j'ai du mal à voir)
En terme d'intégration, il n'y a que la récupération des Work Items
liés aux ChangeSets pris en compte dans le build qui serait à
reprendre, avec modification de ceux-ci pour les tagguer avec la
version du build....
Côté SCM, je n'ai jamais eu de problèmes de performances (@yann ?)
pourtant notre solution est assez volumineuse il me semble. Par contre
je confirme le cauchemar des merges, mais rien de bien pire qu'avec
SVN finalement, et les broutilles du genre check-in d'un fichier
affichant tous les pending, affichage de tous les conflits avant auto-
resolve...ne me semble pas entraver la productivité, contrairement aux
merges de branches...mais ça a un avantage, c'est de se forcer à faire
le moins de branches possible :).
Concernant le cherry picking, je ne l'ai même jamais utilisé sur TFS,
ça me paraît hasardeux au possible : comment s'assurer qu'un check-in
fait après X autres sur la même branche ne pende pas d'un de ces X et
que le cherry picking de ce check-in serait du coup fiable (si tant
est qu'il compile !)...
Concernant le workflow "compliqué" proposé dans un lien par Philippe,
on fait exactement ça et avec TFS sans se tirer de balles (sauf les
merges qui sont peut-être un peu plus douloureux...), à moins que je
n'ai rien compris...
L'administration TFS est faite par nos propres soins et ça n'est pas
franchement compliqué, si on y passe 2h par mois, c'est déjà
beaucoup...
Les fonctionnalités de check-in en local et de bisection me paraîssent
clairement super intéressantes.
Pour l'intégration d'un autre SCM à la place du Source Control TFS, je
vois les points d'attention suivants :
- les check-in policies pour se rappeler de faire les choses bien (et
non pas pour fliquer !) -> hook script j'imagine ?
- le lien avec les Work Items, bien utile pour retracer des modifs,
donner plus d'éléments contextuels au check-in (tâches, User Story...)
-> des propositions dans un autre outil sans faire 15 manipulations
manuelles pour retrouver l'info ?
Tout ça me donne bien envie d'en parler de vive voix, par exemple dans
un format OpenSpace pour qu'il y ait un maximum d'interactions et
d'oppositions, avec peut-être 2 petites présentations de 15 minutes
chacune pour lancer les débats (une sur TFS et sur un DVCS...)...qu'en
pensez-vous ?
Clément
>
> plus de détails »
Radwane
4 oct. 2011, 18:39:2104/10/2011
à altnetfr
Carrément pour l'open space usine logicielle :)
Y a des choses super sympa que permet ces nouveaux outils tel que le
build incassable, avec hudson et git, un commit se fait dans une
branche de l'utilisateur (oui les branches ce n'est plus un problème
et encore mieux c'est ultra rapide à créer pas une copie de tous les
fichiers...), si ce commit casse la branche il n'est pas mergé... Donc
la branche master n'est pas cassé.
Oui les rapports sont mieux (même cruise control.net était mieux que
TFS...).
Sinon pour la liaisons des commits aux works items sur le papier ça
peut être intéressant, on l'utilise dans mon projet, mais actuellement
aucun bénéfice... Ca vous est utile dans votre projet ?
> > > > > > Moi je dis, restons ouvert, les solutions a nos problèmes peuvent venir...
>
> read more »
Y a des choses super sympa que permet ces nouveaux outils tel que le
build incassable, avec hudson et git, un commit se fait dans une
branche de l'utilisateur (oui les branches ce n'est plus un problème
et encore mieux c'est ultra rapide à créer pas une copie de tous les
fichiers...), si ce commit casse la branche il n'est pas mergé... Donc
la branche master n'est pas cassé.
Oui les rapports sont mieux (même cruise control.net était mieux que
TFS...).
Sinon pour la liaisons des commits aux works items sur le papier ça
peut être intéressant, on l'utilise dans mon projet, mais actuellement
aucun bénéfice... Ca vous est utile dans votre projet ?
>
> read more »
Guillaume Collic
5 oct. 2011, 02:31:4205/10/2011
à paris...@googlegroups.com
C'est dommage, l'open space usine logicielle gratuit de Londres (citcon - 11 novembre) est plein justement depuis ce matin ;-) Moi j'y serais, d'autres personnes s'étaient inscrit à temps ?
Carrément partant pour participer aussi à un autre à Paris si ça s'organise ^^
2011/10/5 Radwane <hassen....@gmail.com>
Répondre à tous
Répondre à l'auteur
Transférer
0 nouveau message