Oggi, uno dei miei colleghi e io abbiamo un dibattito su "Dovremmo inserire 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?
E se la maggior parte dei sistemi di controllo del codice sorgente li memorizzasse solo come BLOB? La maggior parte delle persone non si lamenta delle differenze tra i documenti, ma se lo fai, puoi sempre ottenere due versioni e usare la funzione del sistema di authoring per diffarle.
Con spazio sul disco rigido a pochi centesimi di dollaro al mese, non ci sono buone ragioni per non inserire documenti nel sistema di controllo del codice sorgente ed è probabile che sia utile. La mia preferenza personale è scrivere documenti usando markup in linea, ad es. Wiki Markup o DocBook . Ciò consente l'utilizzo di potenti strumenti per il confronto e la revisione dei documenti.
I documenti relativi alle specifiche delle versioni sono sicuramente un obiettivo degno.
Tuttavia, i tuoi documenti delle specifiche sono solo testo e in un file di testo normale ? Se è così, questa potrebbe essere una buona soluzione.
In caso contrario, il controllo del codice sorgente probabilmente non è il posto giusto per loro - il controllo del codice sorgente è danneggiato per i file binari .
Di solito, i file di testo semplice non sono né validi per la formattazione né per la visualizzazione rapida, quindi una wiki con il 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 normale. Quindi cose come documenti Word o RTF ecc. Non si adattano molto bene (specialmente quando provi a confrontare versioni diverse).
Ma esistono altre soluzioni progettate specificamente per i documenti. Mi viene in mente SharePoint, ma sono sicuro che ce ne sono altri.
Sicuramente. Il problema che i documenti sono memorizzati come file binari (ad esempio documenti di parole) è fastidioso. Una buona soluzione è 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 apporti una modifica, l'intero documento viene nuovamente eseguito (non solo il cambiamento). Ma considerando che i documenti di testo non sono enormi normalmente e che lo spazio probabilmente non è il tuo problema principale, questo non è un problema.
Sono sicuro che puoi usare docdiff senza Tortoise, è solo che non l'ho provato.
C'è un approccio alternativo da discutere: BDD
Si prega di considerare lo sviluppo guidato dal comportamento con le specifiche eseguibili. Le tue specifiche vengono semplificate in una serie di istruzioni Given - When - Then che sono memorizzate in file di testo. Uno strumento BDD come Cucumber o SpecFlow converte quei file di testo in test eseguibili, che il tuo strumento di compilazione può eseguire.
Cetriolo: link - BDD per Ruby
SpecFlow: link - BDD for .Net
Per una rapida demo del flusso di lavoro con uno strumento come SpecFlow, controlla il walk-through SpecFlow di Rob Conery: link
Ora, non solo stai facendo il versioning del tuo codice, ma le tue specifiche e lo strumento di Continuous Integration (pensa TeamCity, CruiseControl, Hudson, ecc.) impone che tutte le specifiche siano ancora valide su OGNI build ... È prezioso per voi?
Leggi altre domande sui tag version-control specifications