Oggi, uno dei miei colleghi e io abbiamo un dibattito su "Dovremmo mettere i documenti delle specifiche nel sistema di controllo del codice sorgente come SVN?". Secondo me, dovrebbe essere. Tutto ciò che riguarda lo sviluppo del progetto dovrebbe essere controllato attentamente con il sistema di controllo della fonte. È un concetto sbagliato nel processo di sviluppo del software?
Risposte:
E se la maggior parte dei sistemi di controllo del codice sorgente li memorizzasse solo come BLOB? La maggior parte delle persone non si preoccupa delle differenze tra i documenti, ma se lo fai, puoi sempre ottenere due versioni e utilizzare la funzionalità del sistema di creazione per diff.
Con uno spazio su disco rigido a centesimi per gigabyte al mese, non c'è motivo di non inserire documenti nel sistema di controllo del codice sorgente, ed è probabilmente utile. La mia preferenza personale è quella di scrivere documenti utilizzando il markup inline, ad esempio Wiki Markup o DocBook . Ciò consente l'uso di potenti strumenti per il confronto e la revisione dei documenti.
I documenti sulle specifiche di versione sono sicuramente un obiettivo degno.
Tuttavia, i tuoi documenti di specifica sono di solo testo e in un file di testo semplice ? In tal caso, questa potrebbe essere una buona soluzione.
In caso contrario, il controllo del codice sorgente non è probabilmente il posto giusto per loro - il controllo del codice sorgente è dannoso per i file binari .
Di solito, i file di testo normale non sono altrettanto buoni per la formattazione o per la visualizzazione rapida, quindi una wiki con controllo delle versioni è probabilmente un'idea migliore.
Tutti i documenti dovrebbero essere in qualche forma di archivio (preferibilmente con controlli di revisione).
I sistemi di controllo del codice sorgente sono una soluzione. Ma di solito questi sistemi sono progettati per documenti di testo semplice. Quindi cose come documenti Word, RTF ecc. Non si adattano così bene (specialmente quando provi a confrontare versioni diverse).
Ma ci sono altre soluzioni appositamente progettate per i documenti. Mi viene in mente SharePoint, ma sono sicuro che ce ne sono altri.
Decisamente. Il problema che i documenti siano archiviati come binari (ad esempio documenti di parole) è fastidioso. Una bella soluzione è che se usi uno degli strumenti Tortoise (ho provato SVN e Mercurial) puoi scegliere "Visual Diff" che ti permette di scegliere docdiff. Con docdiff puoi vedere tutti i cambiamenti con colori e cose :-). Lo svantaggio principale è che ogni volta che si apporta una modifica, viene eseguito nuovamente il commit dell'intero documento (non solo della modifica). Ma considerando che normalmente i documenti di testo non sono enormi e che probabilmente lo spazio non è il problema principale, questo non è un problema.
Sono sicuro che puoi usare docdiff senza Tortoise, è solo che non l'ho provato.
C'è un approccio alternativo che dovresti discutere: BDD
Si prega di considerare lo sviluppo guidato dal comportamento con specifiche eseguibili. Le tue specifiche vengono semplificate in una serie di insiemi Dato - Quando - Quindi archiviati in file di testo. Uno strumento BDD come Cucumber o SpecFlow converte quei file di testo in test eseguibili, che lo strumento di compilazione può eseguire.
Cetriolo: http://cukes.info/ - BDD per Ruby
SpecFlow: http://www.specflow.org/ - BDD per .Net
Per una rapida dimostrazione del flusso di lavoro con uno strumento come SpecFlow, controlla la procedura dettagliata SpecFlow di Rob Conery: http://tekpub.com/view/concepts/5
Ora, non solo stai controllando il codice, ma anche le tue specifiche e il tuo strumento di integrazione continua (pensa a TeamCity, CruiseControl, Hudson, ecc.), Stai facendo valere che tutte le specifiche sono ancora valide su OGNI build ... È prezioso per te?