Devrions-nous mettre les documents de spécification dans un système de contrôle de source tel que svn?

11

Aujourd'hui, un de mes collègues et moi avons un débat sur "Faut-il mettre les documents de spécification dans un système de contrôle de source tel que SVN?". À mon avis, ça devrait l'être. Tout ce qui concerne le développement du projet doit être soigneusement contrôlé avec le système de contrôle des sources. Est-ce un mauvais concept dans le processus de développement logiciel?

version-control specifications

— Edison Chuang
source

4

Alors, que se passe-t-il si la plupart des systèmes de contrôle de source ne les stockent que comme des blobs? La plupart des gens ne donnent pas d'informations sur les différences entre les documents, mais si vous le faites, vous pouvez toujours obtenir deux versions et utiliser la fonctionnalité du système de création pour les différencier.

— SnoopDougieDoug
source

2

C'est vrai, je suis content si SVN s'assure que j'ai toujours la version actuelle. Les différences sont moins importantes la plupart du temps.

— Zachary K

Ce n'est pas le seul problème, les modifications de verrouillage et d'écrasement sont un problème lorsqu'il y a plusieurs éditeurs

— Nicole

1

Différents documents ne sont pas importants pour vous. Mais pour un PM, la possibilité de voir les changements dans les spécifications est très importante.

— Martin York

Cette réponse ressemble plus à un commentaire sur une autre réponse. Par exemple, la question ne mentionne rien sur les blobs.

— Bryan Oakley

15

Avec un espace sur le disque dur à quelques centimes par gigaoctet par mois, il n'y a aucune bonne raison de ne pas mettre de documents dans le système de contrôle des sources, et cela sera probablement utile. Ma préférence personnelle est d'écrire des documents en utilisant le balisage en ligne, par exemple le balisage Wiki ou DocBook . Cela permet d'utiliser des outils puissants pour la comparaison et la révision de documents.

— Kevin Cline
source

3

À tout le moins, il est amusant de voir à quoi ressemblait la version 1.0 des spécifications, par rapport à ce qui est expédié!

— Martin Beckett

8

La versionnage des documents de spécification est certainement un objectif valable.

Cependant, vos documents de spécification sont -ils uniquement en texte et dans un fichier texte brut ? Si c'est le cas, cela peut être une bonne solution.

Sinon, le contrôle des sources n'est probablement pas le bon endroit pour eux - le contrôle des sources est mauvais pour les fichiers binaires .

Habituellement, les fichiers en texte brut ne sont ni aussi bons pour le formatage ni pour une visualisation rapide, donc un wiki avec versioning est probablement une meilleure idée.

— Nicole
source

Habituellement, notre document comprend non seulement du contenu en texte brut, mais aussi des images telles que le diagramme UML ou quelque chose comme ça. Je suis totalement d'accord que les fichiers au format binaire ne conviennent pas au système de contrôle de source. Cependant, je pense que c'est mieux que rien. droite? S'il y avait un wiki, nous pourrions l'adopter. Ce serait génial. Mais je m'en inquiète. Nos gens seraient "trop occupés" pour apprendre à utiliser wiki. (Triste)

— Edison Chuang

1

Il existe de nombreux wikis de nos jours avec les éditeurs WYSIWYG. Je suis un converti très réticent de sharepoint. En tant que développeur, je détestais le sharepoint avec passion. Ensuite, je me suis inscrit avec Microsoft BPOS qui est fourni avec sharepoint et je l'ai utilisé pour collaborer sur des projets avec des membres distants de l'équipe. Il a un wiki, des forums, des calendriers et des bibliothèques de documents (qui font le suivi pour Microsoft Office Docs) et un tas d'autres choses qui rendent la collaboration du projet facile. Je pense qu'un Wiki en tant que spécification vivante est parfait en raison de l'histoire qu'il fournit.

— Michael Brown

À strictement parler, le contrôle des sources n'est pas mauvais pour les fichiers binaires. Ce n'est pas comme s'il les détruisait ou les mutait d'une manière ou d'une autre. On peut dire, cependant, que les fichiers binaires sont mauvais pour le contrôle des sources, mais uniquement parce qu'ils occupent beaucoup d'espace disque et rendent le clonage plus lent. L'espace disque est bon marché, donc ce n'est pas aussi mauvais qu'il y a 5 ans.

— Bryan Oakley

1

Tous les documents doivent être sous une forme d'archive (de préférence avec des contrôles de révision).

Les systèmes de contrôle des sources sont une solution. Mais généralement, ces systèmes sont conçus pour les documents en texte brut. Ainsi, des choses comme les documents Word ou RTF, etc. ne correspondent pas si bien (surtout lorsque vous essayez de comparer des versions différentes).

Mais il existe d'autres solutions spécialement conçues pour les documents. SharePoint me vient à l'esprit, mais je suis sûr qu'il y en a d'autres.

— Martin York
source

0

Absolument. Le problème que les documents sont stockés sous forme de fichiers binaires (par exemple des documents Word) est ennuyeux. Une bonne solution de contournement est que si vous utilisez l'un des outils Tortoise (j'ai essayé SVN et Mercurial), vous pouvez choisir "Visual Diff" qui vous permet de choisir docdiff. Avec docdiff, vous pouvez voir tous les changements avec les couleurs et les trucs :-). Le principal inconvénient est que chaque fois que vous apportez une modification, le document entier est à nouveau validé (pas seulement la modification). Mais étant donné que les documents texte ne sont normalement pas énormes et que l'espace n'est probablement pas votre problème principal, ce n'est pas un problème.

Je suis sûr que vous pouvez utiliser docdiff sans Tortoise, c'est juste que je ne l'ai pas essayé.

— Omar Kohl
source

Il ne résout cependant pas le problème "Écraser les modifications de plusieurs éditeurs".

— Omar Kohl

0

Il existe une approche alternative dont vous devriez discuter: BDD

Veuillez considérer le développement basé sur le comportement avec des spécifications exécutables. Vos spécifications sont simplifiées en une série d'énoncés donnés - quand - alors d'instructions qui sont stockés dans des fichiers texte. Un outil BDD tel que Cucumber ou SpecFlow convertit ces fichiers texte en tests exécutables, que votre outil de génération peut exécuter.

Concombre: http://cukes.info/ - BDD pour Ruby

SpecFlow: http://www.specflow.org/ - BDD pour .Net

Pour une démonstration rapide du flux de travail avec un outil comme SpecFlow, consultez la procédure pas à pas SpecFlow de Rob Conery: http://tekpub.com/view/concepts/5

Maintenant, non seulement vous versionnez votre code, mais vos spécifications et votre outil d'intégration continue (pensez à TeamCity, CruiseControl, Hudson, etc.) font en sorte que toutes les spécifications soient toujours valides sur CHAQUE build ... Est-ce que cela est précieux pour vous?

— Jeff Fritz
source