Un moyen facile d'impliquer des non-programmeurs (c'est-à-dire des concepteurs) dans l'utilisation du contrôle de version?

13

Quels sont les principaux moyens d'impliquer votre équipe dans l'utilisation du contrôle de version pendant le développement, le développement Web ou autre?

Je refuse de travailler sans, ce qui signifie que toute personne impliquée dans le projet doit également l'utiliser. C'est juste une bonne pratique.

Les interfaces graphiques comme Tower ont aidé, mais le concept de celui-ci est rencontré avec de la colère (une attitude un peu `` pas mon travail! ''), De la timidité, ou tout simplement sans l'utiliser (en utilisant FTP à la place, en contournant le contrôle de version pour, par exemple, le développement ou le déploiement) ).

Edit: j'aurais dû clarifier un peu que je ne parlais pas seulement d'images / PSD.

version-control teamwork

— Kevin
source

11

Rendez-le FACILE à utiliser ...

1

Je trouve que Git est assez facile une fois que vous y avez passé quelques jours, et que vous avez un consensus sur la façon dont le développement devrait se dérouler .. cela a toujours été un obstacle plus important pour les autres.

— Kevin

2

Un élément à retenir est que le contrôle de version et la sauvegarde se mélangent parfois (bien que très différemment) et à un concepteur avec des données binaires; sauvegarder peut déjà être la norme et donc comprendre ce qu'il gagne doit être compris.

— Aaron McIver

1

@Kevin: Ce qui est facile, évident et intuitif pour un programmeur n'est pas nécessairement quelque chose du genre pour d'autres personnes, même intelligentes et créatives.

— David Thornley

1

Engagez-vous avec un concepteur, puis engagez-la en privé dans le contrôle des versions. :)

11

Je travaille sur une équipe de développeurs et de designers et nous utilisons tous le contrôle de version. Pour les designers, ça craint.

Le partage / sauvegarde de fichiers équivaut toujours au contrôle de version

Quand tu dis:

Je refuse de travailler sans, ce qui signifie que toute personne impliquée dans le projet doit également l'utiliser. C'est juste une bonne pratique.

Vous devez être conscient des pièges de l'utilisation du contrôle de version avec des données binaires:

Écrasement : si deux concepteurs travaillent sur le même fichier, le second à valider écrasera les modifications du premier en tant que version actuelle. Le seul moyen d'empêcher cela est le verrouillage ou une communication constante sur qui fait quoi dans quel fichier, ce qui peut entraver le flux de travail de leur équipe.
Fusion : La fusion assistée par outil est inexistante dans les données binaires. La fusion manuelle est douloureuse et sujette à d'énormes quantités d'erreurs.
Ballonnement du référentiel: les systèmes VC stockent uniquement les lignes modifiées pour les fichiers texte. Ce n'est pas possible avec des données binaires, car le fichier entier sera différent du système VC. Cela signifie que bien que 20 versions d'un fichier texte de 10 Ko ne puissent occuper que 20 Ko, 20 versions d'un fichier de 1 Mo occuperont probablement plus près de 20 Mo. Une équipe de conception de taille moyenne peut facilement générer de nombreuses révisions sur des dizaines de fichiers binaires. Votre service informatique pourrait bientôt vous détester pour les besoins de stockage et peut-être même une augmentation de la mémoire / CPU de votre serveur VC.

Vous et les autres développeurs pouvez également bientôt détester le temps que les extractions ou les mises à jour peuvent prendre, sauf si vous avez configuré une très bonne organisation de référentiel pour éviter les fichiers binaires.
Bénéfice réduit : Vos concepteurs reviendront rarement, voire jamais, aux versions précédentes des fichiers binaires, car 1) aucun moyen facile de vérifier le contenu d'une version antérieure 2) aucun moyen facile de fusionner de toute façon, et surtout, 3) ils ne ne fonctionnent pas de cette façon - ils sont utilisés pour créer des versions alternatives de certains graphiques qui peuvent toujours être utiles dans les fichiers de production eux-mêmes.

Pour votre code, vous devez absolument utiliser VC et vous avez raison de l'exiger.

Mais vous devez vérifier l'hypothèse que cela signifie que tout le monde doit également l'utiliser, ainsi que si c'est même une bonne pratique pour les concepteurs (bien que la sauvegarde soit). Vous devez stocker les ressources graphiques finales requises par votre site Web / application dans votre VC, mais pour les fichiers de production, ce n'est peut-être pas la bonne solution.

— Nicole
source

Concernant le "gonflement du référentiel": vous pouvez essayer de contourner cela avec les bons formats de fichier. La documentation stockée dans un format de langage de balisage de document et les graphiques stockés dans un format de langage de balisage graphique au lieu des formats binaires équivalents peuvent être très utiles. Bien sûr, la viabilité de celui-ci dépend du projet en question et de la volonté et de la compétence des personnes impliquées. ;)

— Baelnorn

5

L'écrasement ne se produit pas sur les VCS valant quoi que ce soit. Ce qui se passe, c'est que vous avez deux versions du même fichier. Oui, le HEAD du dépôt aura la dernière sauvegarde; mais le travail de l'autre concepteur n'est pas perdu comme il le serait sur un disque dur partagé. Je pense que c'est une distinction importante.

— Berin Loritsch

2

@Berin: C'est vrai, mais l'un des avantages du VCS moderne est que deux personnes peuvent travailler sur la même chose en même temps et une grande partie du travail de réconciliation est automatique. Cependant, avec un fichier binaire où il n'y a pas de processus de fusion significatif, ce n'est pas possible. De plus, le responsable du référentiel est celui que les gens considéreront comme "réel".

— jprete

1

Comme le cycle de vie du code source et de la documentation de conception diffère, assurez-vous d'utiliser des référentiels séparés pour eux. Je ne suis pas d'accord pour dire que les dépôts sont nuls pour les concepteurs; la plupart du temps est consacré à la réflexion et à la modélisation, sans apporter beaucoup de petits changements aux documents. Nous en faisons également une règle pour interdire la fusion automatique (sur tous les fichiers stockés dans les référentiels) et avons donc un verrouillage de fichier obligatoire pour les modifications. Combiné à une bonne communication d'équipe, cela évite beaucoup des inconvénients que vous mentionnez.

— rsp

1

Vous avez tout à fait tort, par exemple: Écrasement - ce n'est pas un problème de contrôle de version, au contraire, cela vous aide à le détecter. Les systèmes VC stockent uniquement les lignes modifiées pour les fichiers texte. - Faux pour git.

— maaartinus

4

Je refuse de travailler sans, ce qui signifie que toute personne impliquée dans le projet doit également l'utiliser. C'est juste une bonne pratique.

C'est une excellente attitude, là-haut avec «pas mon travail! :-)

La meilleure façon d'obtenir l'adhésion est d'utiliser quelque chose comme TortoiseGit ou TortoiseSVN pour intégrer le contrôle de version dans Explorer (en supposant que Windows). Il faut du temps pour voir un réel avantage si vous n'êtes pas habitué au paradigme du contrôle de version. La tortue facilite au moins le travail avec VCS avec la souris. Un simple "Clic droit -> Enregistrement" suffit.

Pour cette raison, j'ai cherché à implémenter un contrôle de version transparent dans TortoiseGit à chaque fermeture de fichier. Si vous donnez à quelqu'un une branche sur laquelle travailler, puis que chaque écriture / fermeture devient une opération de validation, à un moment donné, en tant que développeur, vous pouvez fusionner leur branche sans vous soucier de la cohérence de l'ensemble du référentiel, et ils peuvent continuer avec entreprise de faire ce qu'ils font sans avoir à connaître le contrôle de version.

J'ai ce même problème avec un énorme ensemble de documents d'audit que je ne peux pas amener les gens à contrôler les versions, nous avons donc 50 versions du même document flottant qui sont toutes subtilement différentes.

— Chris K
source

4

La façon de procéder est de mettre en place un système de construction (comme Hudson ) qui utilise le système de contrôle de version pour récupérer les sources de construction et en faire une règle de projet que seuls les objets qui sont fournis par le système de construction vont à l'équipe de test et finalement déployé sur le site du client.

Précisez très clairement qu'en ce qui concerne le processus du projet, tout ce qui ne provient pas de la construction est réservé aux développeurs uniquement; tant que le travail de quelqu'un n'est pas accepté dans la construction, il pourrait tout aussi bien ne pas exister.

— rsp
source

2

Illustrer les avantages:

Montrez-leur comment ils peuvent gagner du temps en permettant à tout le monde de partager leur travail et d'accéder à un emplacement central.
Montrez-leur comment il permet aux concepteurs de travailler sur différentes parties du projet en même temps et de le fusionner à nouveau.
Montrez-leur comment ils peuvent étiqueter et créer une ancienne version d'une application à des fins de test ou de dépannage.
Montrez-leur comment ils peuvent jouer avec une conception pour l'expérimentation, puis actualiser le projet et ne pas conserver les modifications s'ils ne le souhaitent pas.
Montrez-leur comment ils peuvent voir ce qui s'est passé au fil du temps.

— jzd
source

1

-1 Il s'agissait d'engager des non-programmeurs; la liste apparaît adaptée à un programmeur. Si vous modifiez votre réponse, je supprimerai certainement le vote

— négatif

1

Je pense que vous avez manqué la partie "pour les non-programmeurs". Toutes les tâches que vous avez mentionnées sont des tâches de programmeur.

— Erik Funkenbusch

Désolé, je viens de lire la question, pas le titre. Je vais modifier la réponse.

— jzd

1 Supprimé ...

— Aaron McIver

1

"Pas mon travail" sur le contrôle de version est une attitude sensée d'un non-programmeur.

Créez un système de contrôle de version aussi simple et invisible que Dropbox pour la synchronisation ou Time Machine pour la sauvegarde.

Ça devrait juste marcher. Pas de paiement, pas de validation. Mettez simplement les fichiers dans le dossier du projet.

— mouviciel
source

1

J'ai utilisé tortoiseHG / mercurial avec la nouvelle dame du site Web, aucun problème là-bas. Le fait de ne pas avoir d'extraction simplifie les choses et met toute la pression sur la personne qui doit réellement s'assurer que les fichiers sont synchronisés. Cela ne semble même pas "une chose de plus à faire", c'est juste "ok je vais faire une démo du site donc je dois demander à Peter de resynchroniser les changements." et ce n'est pas un problème.

Je n'avais aucune expérience avec mercurial auparavant, nous utilisons VSS et je n'aurais jamais souhaité cela sur personne pour le contrôle de source de site Web. Je l'ai essayé une fois et je ne blâmerais personne pour ne pas vouloir l'utiliser ensuite.

— Peter Turner
source

0

Je dirais que l'utilisation de clones de tortue *, c'est plus simple. Ou intégrez le contrôle de version, dans l'IDE ou autre.

— Coyote21
source