Un modo semplice per coinvolgere i non programmatori (ovvero i progettisti) nell'uso del controllo versione?

13

Quali sono alcuni modi chiave per coinvolgere il tuo team nell'uso del controllo versione durante lo sviluppo, lo sviluppo web o altro?

Mi rifiuto di lavorare senza di essa, il che significa che anche chiunque sia coinvolto nel progetto deve usarlo. È solo una buona pratica.

Le GUI come Tower hanno aiutato, ma il concetto di esso è incontrato con rabbia ("non il mio lavoro!" Atteggiamento di kinda), timidezza, o semplicemente non usandolo (usando invece FTP, aggirando il controllo della versione per esempio, sviluppo o distribuzione ).

Modifica: avrei dovuto chiarire un po 'che non intendo solo immagini / PSD.

version-control teamwork

— Kevin
fonte

11

Rendono FACILE da usare ...

1

Trovo che Git sia abbastanza facile dopo aver trascorso qualche giorno con esso e avere un consenso su come dovrebbe andare lo sviluppo .. è stato ancora un ostacolo più grande per gli altri.

— Kevin,

2

Un po 'da ricordare è che il controllo e il backup della versione a volte si fondono (sebbene notevolmente diversi) e a un designer con dati binari; il backup può già essere la norma e pertanto è necessario comprendere cosa sta guadagnando.

— Aaron McIver,

1

@Kevin: Ciò che è facile, ovvio e intuitivo per un programmatore non è necessariamente qualcosa del genere per altre persone, anche altre intelligenti e creative.

— David Thornley,

1

Impegnarsi con un designer, quindi coinvolgerla privatamente nel controllo delle versioni. :)

11

Lavoro in un team di sviluppatori e designer e tutti usiamo il controllo della versione. Per i designer, fa schifo.

Condivisione / backup di file equivale sempre a Controllo versione

Quando dici:

Mi rifiuto di lavorare senza di essa, il che significa che anche chiunque sia coinvolto nel progetto deve usarlo. È solo una buona pratica.

È necessario essere consapevoli delle insidie dell'utilizzo del controllo versione con dati binari:

Sovrascrittura : se due designer stanno lavorando sullo stesso file, il secondo da impegnare sovrascriverà le modifiche del primo come versione corrente. L'unico modo per impedirlo è bloccare o comunicare costantemente chi sta facendo cosa in quale file, entrambi i quali possono ostacolare il flusso di lavoro del proprio team.
Unione : l' unione assistita da strumenti è inesistente nei dati binari. La fusione manuale è dolorosa e soggetta a enormi quantità di errori.
Gonfiore del repository: i sistemi VC memorizzano solo le righe modificate per i file di testo. Questo non è possibile con i dati binari, poiché l'intero file apparirà diverso dal sistema VC. Ciò significa che mentre 20 versioni di file di testo da 10 KB possono occupare solo 20 KB, 20 versioni di un file da 1 MB probabilmente impiegheranno circa 20 MB. Un team di progettazione di dimensioni moderate può facilmente generare molte revisioni su dozzine di file binari. Il tuo reparto IT potrebbe presto odiarti per i requisiti di archiviazione e forse anche un aumento della memoria / CPU del tuo server VC.

Tu e altri sviluppatori potreste anche presto odiare quanto tempo possono richiedere checkout o aggiornamenti a meno che non abbiate creato un'ottima organizzazione di repository per evitare i file binari.
Vantaggi ridotti : i vostri progettisti raramente, se mai, torneranno alle versioni precedenti dei file binari, perché 1) nessun modo semplice per controllare i contenuti di una versione passata 2) nessun modo semplice per unirli comunque, e, soprattutto, 3) non indossano funzionano in questo modo: vengono utilizzati per creare versioni alternative di alcuni elementi grafici che potrebbero essere ancora utili nei file di produzione stessi.

Per il tuo codice, dovresti assolutamente utilizzare VC e hai ragione a richiederlo.

Ma è necessario verificare il presupposto che ciò significhi che anche tutti devono utilizzarlo, nonché se è anche una buona pratica per i progettisti (anche se il backup lo è). Dovresti archiviare le risorse grafiche finali richieste dal tuo sito web / applicazione nel tuo VC, ma per i file di produzione, potrebbe non essere la soluzione giusta.

— Nicole
fonte

Per quanto riguarda il "rigonfiamento del repository": puoi provare a aggirare quello con i giusti formati di file. La documentazione archiviata in un formato di linguaggio di markup del documento e la grafica archiviata in un formato di linguaggio di markup grafico anziché i formati binari equivalenti possono essere di grande aiuto. Naturalmente la fattibilità di ciò dipende dal progetto in questione e dalla volontà e competenza delle persone coinvolte. ;)

— Baelnorn,

5

La sovrascrittura non avviene sui VCS che valgono nulla. Quello che succede è che hai due versioni dello stesso file. Sì, HEAD del repository avrà l'ultimo salvataggio; ma il lavoro dell'altro designer non si perde come se fosse su un disco rigido condiviso. Penso che sia una distinzione importante.

— Berin Loritsch,

2

@Berin: È vero, ma uno dei vantaggi del VCS moderno è che due persone possono lavorare sulla stessa cosa allo stesso tempo e gran parte del lavoro di riconciliazione è automatico. Tuttavia, con un file binario in cui non esiste un processo di unione significativo, ciò non è possibile. Inoltre, il responsabile del repository è quello che la gente considererà "reale".

— giovedì

1

Poiché il ciclo di vita del codice sorgente e della documentazione di progettazione differisce, assicurarsi di utilizzare repository separati per loro. Non sono d'accordo sul fatto che i repository faccia schifo per i designer; la maggior parte del tempo viene impiegato per pensare e modellare, senza apportare molte piccole modifiche ai documenti. Facciamo anche una regola per impedire l'unione automatica (su tutti i file archiviati nei repository) e quindi abbiamo il blocco obbligatorio dei file per le modifiche. In combinazione con una buona comunicazione di squadra, questo impedisce molti degli svantaggi che menzioni.

— rsp

1

Ti sbagli, ad esempio: Sovrascrittura : questo non è un problema di controllo della versione, al contrario, ti aiuta a rilevarlo. I sistemi VC memorizzano solo le righe modificate per i file di testo. - Falso per git.

— maaartino

4

Mi rifiuto di lavorare senza di essa, il che significa che anche chiunque sia coinvolto nel progetto deve usarlo. È solo una buona pratica.

Questo è un GRANDE atteggiamento, proprio lì con "non è il mio lavoro!" :-)

Il modo migliore per ottenere il buy-in è usare qualcosa come TortoiseGit o TortoiseSVN per integrare il controllo della versione in Explorer (supponendo che Windows). Ci vuole tempo per vedere il vero vantaggio se non si è abituati al paradigma di controllo della versione. La tartaruga rende almeno facile lavorare con VCS con il mouse. Basta un semplice "clic destro -> Checkin".

Per questo motivo, ho cercato di implementare il controllo di versione trasparente in TortoiseGit ad ogni chiusura di file. Se dai a qualcuno un ramo su cui lavorare e quindi ogni scrittura / chiusura diventa un'operazione di commit, a un certo punto tu come sviluppatore puoi unire il loro ramo senza preoccuparti della coerenza dell'intero repository e possono andare avanti con il affari di fare quello che fanno senza dover conoscere il controllo delle versioni.

Ho questo stesso problema con una vasta serie di documenti di controllo che non riesco a convincere le persone a controllare la versione, quindi abbiamo 50 versioni dello stesso documento che fluttuano in modo leggermente diverso.

— Chris K
fonte

4

Il modo per avvicinarsi a questo è quello di installare un sistema di compilazione (come Hudson ), che utilizza il sistema di controllo versione per recuperare le fonti di generazione e ne fanno una regola progetto che solo i manufatti che sono una consegnati dal sistema di compilazione stanno per il test team e eventualmente distribuito nel sito del cliente.

Metti in chiaro che per quanto riguarda il processo di progetto tutto ciò che non proviene dalla build è privato solo per gli sviluppatori; fintanto che il lavoro di qualcuno non viene accettato nella build, potrebbe anche non esistere.

— RSP
fonte

2

Illustrare i vantaggi:

Mostra loro come possono risparmiare tempo consentendo a tutti di condividere il lavoro e accedere a una posizione centrale.
Mostra loro come consente ai progettisti di lavorare contemporaneamente su diverse parti del progetto e di fonderli nuovamente.
Mostra loro come possono taggare e creare una versione precedente di un'applicazione per il test o la risoluzione dei problemi.
Mostra loro come possono scherzare con un design per la sperimentazione e quindi aggiornare il progetto e non mantenere le modifiche se non lo desiderano.
Mostra loro come possono vedere cosa è successo nel tempo.

— JZD
fonte

1

-1 Si trattava di coinvolgere i non programmatori; l'elenco appare orientato a un programmatore. Se modifichi la tua risposta, eliminerò sicuramente il voto

— negativo

1

Penso che ti sia sfuggita la parte "per non programmatori". Tutte le attività menzionate sono attività del programmatore.

— Erik Funkenbusch,

Scusa, ho appena letto la domanda, non il titolo. Modificherò la risposta.

— jzd

1 Rimosso ...

— Aaron McIver il

1

"Non è il mio lavoro" sul controllo della versione è un atteggiamento sano da parte di un non programmatore.

Crea un sistema di controllo versione semplice e invisibile come Dropbox è per la sincronizzazione o Time Machine per il backup.

Dovrebbe solo funzionare. Nessun pagamento, nessun commit. Inserisci i file nella cartella del progetto.

— mouviciel
fonte

1

Ho usato tortoiseHG / mercurial con la nuova signora del sito web, senza problemi. Non avere checkout lo rende super semplice e mette tutta la pressione sulla persona che deve effettivamente assicurarsi che i file siano sincronizzati. Non sembra nemmeno "un'altra cosa da fare", è solo "ok vado a demo il sito Web, quindi devo chiedere a Peter di risincronizzare le modifiche". e questo non è un problema.

Non avevo mai avuto esperienza con mercurial prima, usiamo VSS e non avrei mai voluto farlo su nessuno per il controllo del codice sorgente del sito web. L'ho provato una volta e non darei la colpa a nessuno per non volerlo usare allora.

— Peter Turner
fonte

0

Direi l'uso di cloni di tartaruga *, è il più semplice che ottenga. Oppure integra il controllo versione, nell'IDE o altro.

— Coyote21
fonte