Usine De Développement : vos méthodes de production d'applications
yoann
Membre
Salut tout le monde,
Je viens de lire un article plutôt intéressant sur Octo Talks portant sur une "Usine De Développement" pour leurs projets iPhone et les différents concepts qu'ils ont jugé bon de mettre en place chez eux pour améliorer la création d'application iPhone.
Voici l'article : http://blog.octo.com/monter-une-usine-de-developpement-iphone/
Je serais curieu de savoir comment chacun est organisé de son coté ? Pour ma part c'est beaucoup du "à l'arache"... J'ai mon Redmine + SVN de fonctionnel, je crée les accès à mes clients sur leur projet hébergé derrière mon ADSL en pleine campagne et c'est parti, avec ça j'arrive à maintenir un certain degré de fonctionnement mais j'ai consience que ce n'est pas vraiment la bonne méthode quand on travail avec d'autres ^^
Alors comment ça se passe chez vous ? (Si vous pouvez en parler bien entendu ;-)
Si vous avez des solutions de build + test unitaire automatique différents de ce qui est mis en avant par Octo n'hésitez pas à partager :-)
Je viens de lire un article plutôt intéressant sur Octo Talks portant sur une "Usine De Développement" pour leurs projets iPhone et les différents concepts qu'ils ont jugé bon de mettre en place chez eux pour améliorer la création d'application iPhone.
Voici l'article : http://blog.octo.com/monter-une-usine-de-developpement-iphone/
Je serais curieu de savoir comment chacun est organisé de son coté ? Pour ma part c'est beaucoup du "à l'arache"... J'ai mon Redmine + SVN de fonctionnel, je crée les accès à mes clients sur leur projet hébergé derrière mon ADSL en pleine campagne et c'est parti, avec ça j'arrive à maintenir un certain degré de fonctionnement mais j'ai consience que ce n'est pas vraiment la bonne méthode quand on travail avec d'autres ^^
Alors comment ça se passe chez vous ? (Si vous pouvez en parler bien entendu ;-)
Si vous avez des solutions de build + test unitaire automatique différents de ce qui est mis en avant par Octo n'hésitez pas à partager :-)
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
En effet très bon article... rédigé par "colionel", membre de pommedev :P
Il nous avais proposé de publier cet article également sur pommedev... et on s'était montré intéressé.
Sauf que j'ai un peu laissé trainé par manque de temps de m'en occuper, et alex était un peu occupé aussi, donc heu mes excuses publiques à colionel :P
Après du coup on pensait ouvrir un sujet pour discuter justement de ce sujet, tu nous as devancé yoann
Par contre il n'a pas mensionné le fait d'ecrire le code des tests unitaires avant d'écrire les fonctions (méthode agile)
Elle ne sont pas incompatible
Avant de mettre en place un quelconque "process" dans une équipe, il convient de mesurer précisément ce qu'apporte ce process aux développeurs pour qu'ils puissent créer une application de qualité.
Dans un monde (peut être idéal) ou une équipe se forme à partir de personnes compétentes et motivées, il vaut mieux laisser un peu de chaos et ne pas rigidifier la façon de travailler (souvent uniquement dans le but de rassurer un manager).
Je travaille actuellement pour un gros éditeur de logiciel français (sud IDF) et j'observe chaque jour les effets pervers d'avoir un dev contrôlé par des process.
J'ajoute également un lien vers le manifeste agile : http://agilemanifesto.org/ pour ceux que ça intéresse
Tout dépend le contrôle en question. Des outils tel que hudson et des règles de commit vérifié et non juste énnoncé sont pas si mal pour le développement.
c'est pas possible de remplacer hudson par Automator pour l'integration continue ?
Ouch, c'est violent comme idée !!
Le principe d'Hudson c'est de compiler à chaque fois et surtout de synthétiser les erreurs etc. Par contre trouver un équivalent plus adapté aux projets Xcode ça doit se faire j'imagine
Développant seul pour l'instant, je le met de côté pour un futur travail d'équipe.
Je ne connais pas encore hudson, je me renseigne
Concernant la vérification des règles avant commit, tout dépend de ce qui est traqué. Un exemple de règle automatique pour du C++ : "tout pointeur doit être testé avant d'être utilisé". Dans les faits ça se traduit en : un pointeur est testé != NULL avant de faire appel à une méthode. Si le pointeur est nul, on n'appelle pas la méthode. Conséquence : le soft ne plante pas, mes le programme par en vrille et ne rempli pas ses fonctions.
Après on peut rajouter tout ce qui est analyse statistique du code sur la redondance, le style d'indentation, etc.
CruiseControl marche assez bien pour builder avec Xcode. Le reporting d'erreurs est juste un petit peu brouillon, car l'output de xcodebuild n'est pas très facile à parser proprement.
Globalement, je suis plutôt d'accord avec ce qu'énonce l'article. Dans mon contexte (développement multi-plateformes : Windows + Mac/iPhone + Consoles) avec plusieurs dizaines de développeurs), j'ai vécu l'avant et l'après CruiseControl, et ça change la vie ! Maintenant, je peux taper sur les dev Windows quand ils committent n'importe quoi, sans avoir à attendre 1 semaine :P
Hormis ça, le fait de pouvoir sortir une version régulière, toute packagée, sans qu'un développeur s'y colle, est une bénédiction. La machine fait tout comme une grande, et sort les versions au rythme souhaité. Personnellement, je ne m'imaginerais pas builder une version tous les jours sur mon MBP, ne serait-ce que parce que la build prend 2 heures...
Quant à la question des tests, il est toujours intéressants de faire tourner des tests unitaires régulièrement, mais ça ne fait pas tout. S'imaginer que parce qu'une batterie de tests passe à 100%, tout est OK, ce serait une illusion. Mais ça permet d'éliminer des régressions assez faciles à détecter...
Après, sur une équipe de 2 / 3 personnes, c'est peut-être overkill, mais à partir d'un certain nombre de devs, ça devient intéressant !
Comme le dit Kettch, avoir une système de build automatisé dans un environnement hétérogène (iPhone + autres plateformes) est bénéfique pour s'assurer qu'on a toujours du code qui builde dans le source control.
Lancer une série de tests unitaires pour tracker les régressions, c'est encore mieux....
Générer un installer à tout moment, c'est génial...
Quand on s'arrête à ça, c'est parfait (et encore c'est ni une condition nécessaire, ni une condition suffisante de réussite).
On parle tout de même d'iPhone où les équipes de dév sont souvent constitués maxi de 3 personnes...
...D'où la suite de mon message (qui peut être vu comme une disgression mais prenez-le plus comme un Disclaimer ;-) ), ATTENTION AUX ABUS.
Pour avoir travaillé à la fois dans des équipes "100% free style" et d'autres purement issues de l'industrie lourde,il ne faut pas croire que les méthodes de ces dernières vous assure une productivité accrue et une qualité du soft.
Il existe un juste milieu qui rend à la fois a) les développeurs heureux et b) un soft bon.
J'insiste sur ce fait, car les jeunes ingés qui sortent de l'école ont justement le complexe de l'Industrie versus l'Artisanat ("ouais avant je codais dans mon garage, maintenant je vais bosser sérieusement...").
J'ai assisté à des dérives inquiétantes des méthodes "industrielles" où "Le process" comme on dit là bas est institué comme un moyen détourné pour fliquer les gens et les déposséder de leur savoir faire.
La politique du chiffre (ceux qui connaissent les feuilles excel avec du rouge et du vert savent de quoi je parle) fait partie de ces dérives : un soft qui ne plante jamais est un soft bon...OK mais sinon l'ergo du soft, c'est comment ? Passez votre chemin
Du coup la terminologie "Usine de Développement" me fait très peur. Les développeurs deviennent le corps ouvrier de Zola (j'exagère un peu non ? Allez faire un tour à l'intérieur d'un certain éditeur français, qui se proclame justement une "Software Factory", et vous verrez que je ne suis pas très loin de la vérité).
Dans le manifeste Agile, il y a 2 postulats qu'il ne faut jamais oublier:
1. Individuals and interactions over processes and tools
2. Responding to change over following a plan.
J'ai tenté de les suivre dans les projets où j'avais le total contrôle des opérations: j'ai toujours eu des résultats bien supérieurs à ceux promus dans l'industrie traditionnelle.
Gérald.
Pour ma part ce que je trouve très intéressant c'est la partie build automatique et régulier. Pour moi l'intérêt n'est pas de fliquer, surtout quand on est 3, mais d'avoir un suivit automatisé de ce que l'ont fait. àŠtre prévenu régulièrement si un fichier est oublié dans le SVN etc ça évite de perdre bien des heures. C'est surtout ça que je vois d'intéressant la dedans.
Je suis plus issue du free style pour ma part, et a vrai dire les software factory où bosse les amis ne me tente vraiment pas du tout... Ce que je trouve intéressant c'est de prendre le meilleur des deux :-)