Xcode et développement collaboratif
gilv
Membre
Salut,
J'ai fait une recherche sur les forums et les post que j'ai trouvé date un peu (2006 ...) donc je voudrai
savoir si avec Xcode il est possible de développer a plusieurs sur une même application. Que faut-il mettre en place, payant-gratuit, retour d'expérience ...
Merci A+
J'ai fait une recherche sur les forums et les post que j'ai trouvé date un peu (2006 ...) donc je voudrai
savoir si avec Xcode il est possible de développer a plusieurs sur une même application. Que faut-il mettre en place, payant-gratuit, retour d'expérience ...
Merci A+
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Utilise un serveur GIT avec Xcode et une bonne dose d'organisation et de gestion d'équipe et ça ira.
Quel que soit ensuite l'outil de gestion de code collaboratif que tu utilises, que ce soit avec SVN ou avec GIT bref les standard dans ce domaine, Xcode le gère très bien.
J'ai une grosse préférence pour GIT personnellement, SVN commence à être dépassé (ou à la limite GIT-SVN si ton serveur collaboratif est sous SVN mais que tu veux utiliser GIT en local car tu préfères profiter de tout ce qu'il apporte de plus). Bon après, Xcode intègre des outils pour les commit, checkout, diff, etc, mais moi pour la gestion des commits, branches, rebase, dcommit, stash, etc je préfère quand même carrément utiliser l'application SourceTree, gratuite, dédiée à ça, et vraiment super bien foutue (gère GIT et GIT-SVN et Mercurial)
Pour les débutants en Git je conseillerais plutôt un client plus simple que SourceTree, par exemple GitHub.
Perso le client GitHub il est pas mal mais je trouve qu'il lui manque certains trucs à gauche à droite qui facilitent la vie sous SourceTree.
Et en particulier quand on fait du GIT-SVN, ce qui est souvent le cas quand par exemple on est en entreprise avec un serveur SVN car historiquement c'est un SVN qui a été installé (c'est encore très courant) mais qu'on préfère quand même faire du GIT parce que c'est quand même bien mieux, du coup SourceTree rend ça vraiment transparent.
Par exemple le bouton "Push" fait à la fois un rebase pour s'assurer que tu es en phase avec le code du serveur, puis un commit GIT pour commiter des modifs en local, puis un dcommit SVN pour les pousser sur le serveur, et ça en un seul bouton sans que tu n'aies à te poser de questions.
Après, c'est vrai que j'ai été longtemps habitué à faire du SVN, je suis passé à GIT il y a quelques années (surtout avec GitHub), et que je ne suis passé à GIT-SVN qu'il y a un an, mais que du coup j'ai appris les mécanismes, habitudes et terme des outils de versionning (commit, update, etc) au fur et à mesure...
Merci pour vos réponses ... je suis aller voir sur le site de GIT, le PB c'est que c'est gratuit en "Public" et payant en "private".
@Yoann ... Tu peux en dire un peu plus !!!
A+
Gil.
Heu bah go Google "xcode git" et tu devrais trouver de quoi t'informer.
GIT est un système de gestion de code, tout comme SVN (ou même comme le très ancien et maintenant abandonné CVS, ou comme Mercurial, ou d'autres encore). Les deux système de versionning de code les plus répandus étant justement GIT et SVN aujourd'hui.
Ensuite, quand tu fais du versionning de code, en général il te faut un serveur, une machine qui se de référence comme étant la machine avec la dernière version du code source, en somme. Chacun fait ses modifications de son code de son côté puis va ensuite "commiter" et faire un "push" de ses modifications sur le serveur (c'est à dire envoyer ses modifications de code sur la machine serveur servant de référence) et "updater" ou faire un "pull" des nouvelles modifications du serveur sur sa machine (pour récupérer le code que d'autres développeurs auraient poussé sur le serveur)
Quand tu utilises SVN, tu es obligé d'avoir un serveur unique référent et chacun va faire des commit et des update sur ce serveur.
Si tu choisis GIT (un peu plus avancé et plus récent que SVN, il est en gros son successeur), tu peux aussi choisir d'avoir une machine servant de référent (histoire que tout le monde push et pull sur cette machine et qu'on sache que la dernière version est sur ladite machine), ceci dit ce n'est pas obligé, tu peux aussi travailler en mode "pair-à -pair".
Par exemple si vous travaillez à 2 sur un projet, Alice va pouvoir faire des "push" de son code vers la machine de Bob, Bob va pouvoir faire des "pull" du code d'Alice sur sa machine, et vice-versa, un serveur unique au milieu n'est pas nécessaire (Alice et Bob sont en quelques sortes à la fois serveur et client dans ce scénario). C'est aussi pratique si tu travailles tout seul sur ta machine pour utiliser GIT même si tu es seul sur ton projet pour profiter des avantages de la gestion de version (pouvoir revenir en arrière, pouvoir tester des branches, etc, etc)
MAIS en pratique dans 95% des cas de developpement collaboratif on va dire, même avec GIT on aime bien quand même fonctionner avec une machine qui fait office de référence (comme on le fait avec SVN), histoire de toujours savoir où est la dernière version de code et que tout le monde push son code et pull le code des autres depuis la même machine, car sinon on pourrait vite si perdre.
Du coup dans les deux cas, si tu vux faire du developpement collaboratif, que tu utilises SVN ou GàŽT il te faut une machine serveur qui fait donc office de dépôt de code de référence. Tu peux monter un tel serveur sur tes propres machines (sur ton propre Mac par exemple, ou sur un Mac dédié à cet usage c'est mieux car ça fait en plus office de sauvegarde séparée, etc), ou tu peux utiliser des services en ligne qui proposent de telles solutions.
Le service le plus connu et utilisé pour ceux qui utilisent GIT est le site GitHub, qui est un serveur GIT (avec une interface Web et plein de petits trucs sympas en plus) sur lequel tu peux donc créer tes dépôts de code publics (gratuit) ou prives (payant, à partir du 2ème je crois), l'avantage étant que GitHub gère tout l'aspect serveur pour toi (sauvegardes, disponibilité permanente pour n'importe qui sur le web puisse accéder à ton dépôt de code à toute heure, etc) ce qui en fait un serveur idéal pour partager avec la communauté OpenSource ton code que tu voudrais rendre public.
Mais bien sûr, pour des projets collaboratifs privés tu peux tout a fait préférer te monter ton propre serveur GIT de ton côté (tout comme pour SVN tu aurais à monter ton propre serveur SVN) et chacune des personnes intervenant sur le projet ira faire ses push et ses pull GIT sur cette machine privée.
A ce sujet, je suis tombé une fois sur https://bitbucket.org quelqu'un a déjà essayé ?
Nous au taf on est en train de mettre doucement en place GitLab, un service grosso-modo identique à github (serveur GIT, interface web, gestion de pull requests et des issues et d'un wiki, ...) mais qu'on peut installer donc chez nous sur nos propres serveurs. Et pour l'instant ça à l'air super prometteur, on espère à terme migrer totalement dessus et nous débarrasser de SVN :-)
Il a l'avantage d'offrir des répertoires privés et gratuits et relativement simple.
Le sujet est interessant, j'aimerais bien avori vos retour d'expériences sur le travail en équipe ( collaboratif), vous utilisez quoi comme méthodes de travaille en équipe : Pull request sur GitHub, peer programming,... ou bien les boites font confiance au développeur, meme débutant, de pusher leurs codes sans controle. Merci.
Dans tous les cas le principe de base pour du travail sur un dépôt centralisé c'est de toujours tester son code avant de push. En gros tu écrire une méthode, tu commit sur ton git local, tu pull les changement, tu gère tes conflits, tu test de nouveau, du commit et tu push (avec de nouveau un pull avant au cas où quelqu'un ait push entre temps).
Dans cette optique, tu peux aussi placer des conditions de test unitaire pour que tout le code puisse être testé automatiquement à chaque fois, y compris par ceux qui ne le connaisse pas. De cette manière tu peux tester les dépendances d'un code sans savoir les faire marcher.
L'étape suivante c'est la forge logiciel pour lancer un build et les test unitaire à chaque git push et ainsi envoyer une alerte si quelqu'un a fait de la merde.
Ensuite, on clique sur le bouton "Push" dans SourceTree qui fait automatiquement avant un "rebase" avant pour récupérer le code serveur, faire un merge automatique, et te laisser résoudre les conflits s'il y en a, puis faire le push vers le serveur.
Ensuite sur le serveur, à chaque push, notre outil d'intégration continue (Jenkins) fait une compilation du code automatique (comme ça si tu n'as pas verifié que ton code compilait ou que tu as oublié de commiter des fichiers ça se verra tout de suite), lance les tests unitaires sur la machine, et remonte des stats (nombre de warnings, de tests U réussis/ratés, etc) puis envoie un mail à toute l'équipe si jamais il y a un souci (Build instable car ça compile mais avec trop de warnings, ou bien que les tests U ne passent pas tous, ou Build Failed si ça n'a pas compilé, etc)
Enfin, il y a quelques outils qui existent pour faire du Code Review (conventions de nommage, de codage, de formatage, ...) mais en tant qu'architecte logiciel sur un projet je prend toujours un peu de temps occasionnellement pour faire une revue de code express de ce qu'ont codé les autres, en particulier les nouveaux, et leur rappeler le cas échéant les règles de codage ou les erreurs qu'ils ont faites (retain cycle, mauvais design pattern, ...) et comment les corriger pour que ça n'arrive plus.
Après j'essaye de plus en plus de faire du TDD mais on sait tous qu'en pratique sur un vrai projet avec les délais qu'on a ce n'est pas toujours évident de s'y tenir, mais ça à l'énorme mérite de se forcer à faire une architecture bien découpée et a mettre en place par exemple des inversions de dépendance pour pouvoir tester les différents modules de vos applis de façon séparée.
Après pour le reste, bah tout va un peu ensemble : quand on est habitué à faire de l'architecture logicielle bien propre et bien structurée, forcement on a déjà un projet bien découpé, MVC, avec des modules indépendants, du couplage faible, des composants réutilisables déjà testés unitairement de leur côté, et des Desing Patterns facilitant aussi la mise en place des Tests U et la possibilité de bien tester chaque fonctionnalité indépendamment du reste.
Après pour tout ce qui est bouchons réseau, on utilise bien sûr ma fameuse classe OHHTTPStubs, et pour tout ce qui est mocks bien sur il y a OCMock mais il se trouve que pour le projet qu'on a en cours on ne l'a même pas utilisé car on a fait du swizzling a la place dans nos tests U (car OCMock ne permet pas de faire des mocks de méthodes de classe, et qu'on s'est fait une petite lib de swizzling avec blocks pour nous faciliter la vie donc on en profite). C'est pas parfait mais ça fonctionne nickel.
Enfin quand on écrit des Tests U il faut toujours penser à tester d'une pat bien les fonctionnalités unitaires et pas macro, et aussi tous les cas possibles. Si on veut une couverture de code de 100% le mieux étant les TDD puisqu'ils font ça par définition, dans le sens où avec le Red-Green-Refactoring forcément quand tu passes de Red à Green tu codes juste ce qu'il faut pour répondre au Red (un test qui ne passe pas) et n'essaye pas de coder + de fonctionnel que ce que couvre le test.
Pour ça il y a d'autres solutions, comme UIAutomation ou MonkeyTests par exemple (je n'ai encore mis en oe“uvre aucun des deux)
Le gars de CocoaControls avait fait une présentation vidéo sur le sujet (il avait même cité OHHTTPStubs pour ses stubs réseau ;-))
Mais mes TestsU c'est pas mettre une méthode en debug pour tester vite fait, ça on le fait tous, un petit bouton pour tester tel ou tel truc dans son ensemble, et c'est pratique aussi mais ressemble plutôt a du test fonctionnel.
Non les TestsU c'est vraiment unitaire donc les fonctionnalités atomiques.
Par exemple, j'ai un service qui fait une requête à un webservice et qui récupère le résultat pour le stocker en base CoreData.
Je vais avoir des tests unitaires pour la requête aux webservices et des tests unitaires pour le stockage en base.
- Un des tests unitaires pour mes WebServices va être d'appeler ma méthode avec certains paramètres d'entrée, et vérifier que la requête envoyée est exactement celle attendue. À ce stade, je ne vais pas vérifier que la réponse de notre service est correcte, mais bien que les headers et le corps de la requête que j'envoie sont corrects, que je les passe au bon format (JSON? x-www-formdata?...), qu'il n'y a pas des soucis d'encodage, que je n'ai pas inversé ou décalé mes paramètres ou bien géré les cas de "nil", etc.
- Un autre test unitaire pour ce même service va vérifier que si je passe des paramètres incohérents ou erronés, le cas d'erreur est bien traité et remonté
- J'aurai une autre série de tests unitaires pour la partie parsing du résultat JSON retourné par le WebService, avec des tests unitaires passant un JSON en entrée du test et vérifiant que parseur le parse correctement et me génère bien les objets modèle correspondants attendus. Ainsi que les tests au cas où le service retournerai un JSON invalide ou le serveur m'a retourné une 404 ou une 500 etc
- J'aurais enfin une série de test qui vérifie que quand je stocke mon objet en base, il n'y a pas d'erreur CoreData (propriétés obligatoires, relationships entre objets dans le même MOC, etc)
Chacune de ces séries de tests seront totalement indépendantes et testeront une fonctionnalité précise et non pas un fonctionnement global. C'est vraiment de unitaire sur chaque module voire méthode, pour vérifier que selon les différentes entrées possible, on a bien la sortie attendue qui est retournée.
C'est pour cela que c'est aussi d'autant plus important d'avoir une architecture découpée en modules indépendants, avec de l'inversion de dépendances, etc. Si j'intègre le code de parsing du JSON directement dans mon module d'envoi de requêtes au WebService je ne pourrai ni le tester de façon indépendante ni le réutiliser en dehors donc c'est que mon archi serait mal foutue.
Merci pour ce retour AliGator, malheureusement y a pas trop de documentation sur les Tests Unitaires sous objective C, pour connaitre il faut être vraiment expérimenté ou bien venir d'un autre monde que Cocoa.
Est-ce que vous connaissez des sources qui implémentent des tests unitaires pour regarder un peux comment les autres testent leurs modules ?
Moi j'ai un lien intéressant :
http://www.cocoawith...h-complete.html
Je suis entièrement d'accord, ce que je fais n'est pas du test U mais bien un test de la chaine complète avec généralement un WS de test qui me renvois tous les cas de merde possible. Le découplage de mes services est je pense fait comme il faut, du module de DL au module d'entrée dans CoreData en passant par le converter.
Me reste simplement à me pencher comme il faut sur les test U et comment simuler les entrées qui sont censé venir du net pour avoir des test indépendant de l'état du réseau.
ca tombe bien ça c'est précisément le but de OHHTTPStubs ;-)
Simuler des réponses à des requêtes de WS, des données venant du réseau, etc
Mais aussi simuler différents états réseau (soit un réseau qui répond immédiatement sans délai pour faire des tests indépendants de l'état du réseau, soit simuler un délai de réponse pour tester la réaction de ton appli à un réseau lent, soit simuler des erreurs réseau oueds erreurs 500 ou 404, etc, etc. mon framework va te permettre de faire tout ça ;-)
Oui, c'est vrai dans le sens où la littérature donne souvent des exemples en Java, utilisant jUnit.
Mais en pratique, lire et comprendre du Java est très faisable pour un programmeur ObjC (Java en est fortement inspiré).
Ce qui compte est surtout de comprendre le principe.
Après ce qui m'ennuie sur tous les livres qui parlent de test automatisés, c'est que leurs exemples sont toujours basés sur Swing, avec l'IHM construite par le code, et je ne vois pas comment retranscrire ça dans notre monde où nous utilisons des xib.
Test-Driven iOS Development.
Ce livre est bon. En gros, l'auteur se lance dans une appli simpliste au niveau de l'IHM, crée les tests U et le code correspondant, pour se rendre compte que ça ne fonctionne pas! Moi, j'aime bien cette honnêteté, de prêcher pour les tests U, mais d'admettre qu'ils ne garantissent pas une appli qui marche.
Le point fort du livre est justement les démonstrations des différentes techniques pour tester.
Le point faible est que tu finis la lecture en te disant que c'est bien joli tout ça, mais que:
- il faut être sacrément expérimenté en Cocoa/ObjC pour tester les contrôleurs
- tester les contrôleurs demande des tonnes de code
- les tests de vue ne sont pas abordés, l'auteur considérant cela comme peu faisable.
Pour le dernier point, on peut tester une vue en test U, de cette manière:
1) on code la vue jusqu'à obtenir visuellement le résultat attendu.
2) on capture une image du résultat
3) par la suite, on comparera le résultat avec la capture; on aura donc une régression s'il y a une différence.
Il faut évidemment du code de comparaison d'image, j'avais codé le mien sur Mac.
Pour ce qui est des contrôleurs, j'ai simplement laissé tombé: ce n'est pas rentable, et c'est même décourageant de les tester. J'ai cherché un peu sur le web, et j'ai adopté le principe du "skinny controller, fat model". Il s'agit de mettre le minimum de code dans le contrôleur et transférer le maximum de logique dans le modèle, qui lui, est facile à tester. De fait, je ne teste plus le contrôleur en test U; au pire, on peut le tester en test fonctionnel via UIAutomation.