Dove dovrebbero essere conservati gli asset di sviluppo pesanti come i documenti delle specifiche e i file sorgente dell'editor multimediale?

Question

Dove dovrebbero essere conservati gli asset di sviluppo pesanti come i documenti delle specifiche e i file sorgente dell'editor multimediale?

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)

7

Non è raro dove sto lavorando su un sito che include elementi come i documenti delle specifiche binari (o effettivamente indifendibili a causa di fattori al di fuori del mio controllo) (ad esempio, PDF, documenti Word, fogli di calcolo Excel) e file sorgente multimediali (ad es. File di origine FLA, file Photoshop, file Illustrator).

Come dovrebbero essere conservati?

Il mio istinto è quello di buttarli in git. Lo storage è economico, ma rende l'operazione di clonazione molto più lunga di quanto sarebbe altrimenti.

Una possibile alternativa sarebbe usare un wiki. In alcuni casi l'ho provato, ma non ho mai trovato un caso in cui i punti di forza intrinseci del formato wiki (cronologia delle versioni accessibile a layperson e facile accesso alle ultime copie) hanno o avrebbero portato a un vantaggio sufficiente a giustificare il lavoro aggiuntivo nel mantenimento del wiki .

La terza opzione è lasciare che si blocchino localmente e nei thread di posta elettronica.

Quindi quale approccio dovrei prendere per questo?

version-control

posta Steven Xu 18.09.2011 - 05:34

fonte

4 risposte

Leggi altre domande sui tag version-control

Sistema disaccoppiato nei luoghi sbagliati: meta-problema? [chiuso] Come tagliare le e-mail solo per il corpo, quando si utilizza l'e-mail come input per un sistema esterno?

score 2 · Answer 1

usiamo un wiki per questo (confluenza), usato per essere il controllo delle versioni, ed è stato un piacere estremo lavorare con. Il livello di organizzazione che un wiki ti dà non è facilmente raggiungibile usando le directory tree (cosa faresti usando git / samba) o email. Pensa anche alla scalabilità e al futuro: git potrebbe funzionare ora, ma lo farebbe anche tra 10 anni, quando ci saranno altri x documenti? Un altro enorme vantaggio: avere un'idea veloce? basta trovare un posto adatto e iniziare a digitare. Non devi nemmeno pubblicare in primo luogo.

score 1 · Answer 2

Direi che dipende da come stai usando quei dati:

se lo stai migliorando pesantemente e frequentemente, usa i vantaggi dei moderni sistemi di controllo di revisione. Ma pensa alla struttura e alla modularità dei tuoi repository (chi userà il sistema di controllo di revisione in che modo).
se i documenti vengono aggiornati a malapena ma sono molto utilizzati per le ricerche, una wiki è una soluzione eccezionale e vale la pena.
se non è il caso, utilizzare una soluzione semplice e economica. Andrei comunque con un posto locale invece di email-attachment-chaos, ma una (samba-) directory o file / link all'interno del tuo wiki / issue-tracker / wordpress / ... lo farà.

score 0 · Answer 3

L'approccio che fai dipende dal tuo team e dalla metodologia di processo che stai utilizzando. Qualunque cosa si adatti meglio al tuo flusso di lavoro è ciò che dovresti fare. Tu vuoi che questi artefatti siano versionati e gestiti, proprio come il codice. E-mail non fornisce facilmente questo, mentre un sistema di controllo delle versioni e la maggior parte del software wiki lo fa. In definitiva, si desidera essere in grado di collegare una revisione specifica del software con artefatti specifici e accurati che descrivono tale revisione del software.

Hai detto di aver creato alcuni documenti in Microsoft Office. I prodotti Office hanno modifiche e riesaminano il monitoraggio integrato. Sebbene sia ancora necessario eseguire la versione dei documenti, il rilevamento delle modifiche ti consentirà di vedere come un documento è progredito nel tempo. Consiglierei di conoscere questa funzione e di vedere come utilizzarla nel tuo processo.

Hai anche menzionato i PDF. Non sono sicuro di come utilizzi i PDF, ma se sono generati da altri file, esegui solo la versione del file nativo. Probabilmente non ci vuole molto tempo per passare da un file nativo in un PDF generato. Questo vale davvero per tutto ciò che viene generato da altre fonti. Non conservare i prodotti generati, ma solo quelli che utilizzi per generarli come artefatto versione. Risparmierà spazio e ti aiuterà a mantenere la tua sanità mentale.

score 0 · Answer 4

Innanzitutto è davvero una buona idea avere tutte queste cose sotto controllo di versione!

Lo strumento che usi dipende dal tipo di dati. Per i file multimediali comprimere gli originali e scaricarli in una cartella sembra essere l'opzione migliore, forse, con la copia del documento di copertina che entra nel controllo della versione principale (git o altro).

Per documenti di parole come casi d'uso e specifiche ecc. Penso che la migliore strategia sarebbe quella di archiviarli in uno dei più recenti formati basati su "xml" e memorizzarli in "git". Il "diff" in realtà significherebbe qualcosa allora, e, sebbene i documenti stessi sarebbero più grandi, i "diff" sarebbero più piccoli.