Hoje, um dos meus colegas e eu temos um debate sobre "Devemos colocar os documentos de especificação no sistema de controle de origem, como o SVN?". Na minha opinião, deveria ser. Tudo relacionado ao projeto em desenvolvimento deve ser controlado cuidadosamente com o sistema de controle de origem. É um conceito errado no processo de desenvolvimento de software?
Respostas:
E daí se a maioria dos sistemas de controle de origem os armazena apenas como blobs? A maioria das pessoas não comenta as diferenças entre os documentos, mas, se o fizer, sempre poderá obter duas versões e usar o recurso do sistema de criação para diferenciá-las.
Com o espaço do disco rígido em centavos por gigabyte por mês, não há uma boa razão para não colocar documentos no sistema de controle de origem e é provável que seja útil. Minha preferência pessoal é escrever documentos usando marcação embutida, por exemplo, marcação de wiki ou DocBook . Isso permite o uso de ferramentas poderosas para comparação e revisão de documentos.
Os documentos de especificação de versão são definitivamente um objetivo digno.
No entanto, seus documentos de especificação são somente texto e em um arquivo de texto sem formatação ? Nesse caso, essa pode ser uma boa solução.
Caso contrário, o controle de origem provavelmente não é o lugar certo para eles - o controle de origem é ruim para arquivos binários .
Normalmente, os arquivos de texto sem formatação não são tão bons para formatação nem para visualização rápida; portanto, um wiki com versionamento é provavelmente uma idéia melhor.
Todos os documentos devem estar em alguma forma de arquivo (de preferência com controles de revisão).
Os sistemas de controle de fonte são uma solução. Mas geralmente esses sistemas são projetados para documentos de texto sem formatação. Assim, coisas como documentos do Word ou RTF, etc. não se encaixam tão bem (especialmente quando você tenta comparar versões diferentes).
Mas existem outras soluções projetadas especificamente para documentos. O SharePoint vem à mente, mas tenho certeza de que existem outros.
Definitivamente. O problema de os documentos serem armazenados como binários (por exemplo, documentos do Word) é irritante. Uma boa solução é se você usar uma das ferramentas do Tortoise (experimentei o SVN e o Mercurial) e poderá escolher "Visual Diff" que permite escolher o docdiff. Com o docdiff, você vê todas as alterações com cores e outras coisas :-). A principal desvantagem é que toda vez que você faz uma alteração, todo o documento é confirmado novamente (não apenas a alteração). Mas considerando que os documentos de texto não são grandes normalmente e que o espaço provavelmente não é o seu principal problema, isso não é problema.
Tenho certeza que você pode usar o docdiff sem o Tortoise, é só que eu não tentei.
Há uma abordagem alternativa que você deve discutir: BDD
Por favor, considere o desenvolvimento orientado a comportamento com especificações executáveis. Suas especificações são simplificadas em uma série de conjuntos de instruções dadas quando e armazenadas em arquivos de texto. Uma ferramenta BDD como Cucumber ou SpecFlow converte esses arquivos de texto em testes executáveis, que sua ferramenta de construção pode executar.
Pepino: http://cukes.info/ - BDD para Ruby
SpecFlow: http://www.specflow.org/ - BDD para .Net
Para uma demonstração rápida do fluxo de trabalho com uma ferramenta como SpecFlow, consulte o passo a passo do SpecFlow de Rob Conery: http://tekpub.com/view/concepts/5
Agora, não apenas você está versionando seu código, mas suas especificações e sua ferramenta de Integração Contínua (pense em TeamCity, CruiseControl, Hudson, etc.) está forçando que todas as especificações ainda sejam válidas em TODAS as versões ... Isso é valioso para você?