Come convincere un'azienda a cambiare il proprio controllo del codice sorgente [chiuso]

Question

Il mio attuale posto di lavoro è attualmente in fase di transizione, è subentrata una nuova proprietà, le cose si stanno finalmente standardizzando e vengono applicate linee guida adeguate.

Ma stiamo ancora usando VSS, non c'è davvero alcun motivo per usarlo se non quello che è stato impostato inizialmente.Non utilizziamo Visual Studio o qualsiasi strumento che lo richieda specificamente.

Quale sarebbe l'argomento migliore in assoluto che posso sollevare per convincerli che passare a qualcosa come Subversion sarebbe una soluzione molto migliore, a lungo termine.

Answer 1

VSS si affida totalmente ai client per gestire il database.Se un client interrompe la connessione nel bel mezzo di una scrittura sulla rete proprio nel momento sbagliato, il tuo file viene cestinato sul server.Non solo la mancia, ma tutta la storia.Spero che tu abbia un buon backup.Ci sono passato.E' una brutta notizia.

L'utilizzo di VSS su VPN o altre connessioni remote è spaventoso.Utilizza SMB per trasferire i dati e devi recuperare il file e tutti i suoi delta solo per ottenere la mancia.Sgradevole.

Ho visto VSS iniziare a funzionare con 1 GB di dati.Errori del database, ecc.MS (da qualche parte in una FAQ o in una KB) afferma che 2 GB è in realtà il limite massimo di sicurezza.Non ci sono buoni strumenti di gestione (sono i clienti a gestire il manicomio), quindi non ricevi alcun avvertimento a riguardo.

Nulla con un processo server per fornire un certo livello di transazioni e controllo dell'integrità è una soluzione superiore.

Answer 2

L’argomento migliore dovrebbe essere il motivo per cui vuoi che passino alla sovversione.:)

Non so assolutamente nulla di VSS, ma mi viene in mente la frase "se non è rotto non aggiustarlo".Devi mostrare ai tuoi manager che VSS è rotto e deve essere riparato.Ancora meglio se puoi mostrare alla direzione come farebbe risparmiare denaro.

Answer 3

@Adam Davis:Uhhh in realtà Adam, VSS è un orribile sistema di controllo del codice sorgente.Ha una lunga storia di corruzione della cronologia e perdita di dati.È terribile durante la fusione, non gestisce bene più sviluppatori ed è molto lento.Anche la storia è povera.Microsoft non lo supporta più, noterete che non lo hanno mai utilizzato per il proprio sviluppo interno e ora non lo vendono nemmeno in favore di una soluzione più moderna (VSTS).In breve, se devi scegliere tra VSS e qualsiasi altro tipo di controllo del codice sorgente, scegli l'alternativa.

Answer 4

Semplicemente esaminando le funzionalità, un buon controllo del codice sorgente offre:

• capacità di vedere facilmente i registri di chi ha fatto cosa, quando e in quale ordine e in quali file
• mantenere una cronologia delle versioni passate di tutto
• torna facilmente indietro e riproduci una versione specifica dei tuoi file da qualsiasi versione precedente, per riprodurre più facilmente i bug segnalati nelle versioni precedenti
• possibilità di recuperare il codice eliminato o rimuovere modifiche indesiderate, senza doversi preoccupare di perdere dati nel processo

Answer 5

Qualsiasi documento che dimostri il passaggio ridurrà i costi.In caso contrario, grafici e diagrammi multicolori.Magari una presentazione in power point.

Answer 6

Internet è pieno di articoli ben scritti sui difetti del VSS.Lo raccoglierei come prova dell’allontanamento dal VSS.Trova un requisito chiave che VSS non può supportare (lavoro remoto, supporto su altri sistemi operativi, integrazione di strumenti) e utilizzalo per risolvere il problema.Devi quindi trovare un sistema di controllo del codice sorgente che sia adatto ai requisiti della tua organizzazione: sei sicuro che Subversion sia quel sistema?Organizza una dimostrazione del sistema che hai scelto e utilizzala per dimostrarne il valore.

Ho implementato questo cambiamento presso un precedente datore di lavoro (prima in CVS e poi in SVN) e, sebbene abbia avuto successo, abbiamo dovuto costruire molti bit attorno al limite e fare affidamento su molti progetti open source (a volte inaffidabili) per ottenere tutti gli strumenti di cui avevamo bisogno.Con il senno di poi avrei dovuto considerare di provare a valutare strumenti professionali come Perforce, Vault o anche Team System.Dopo averli valutati, avrei potuto esprimere un giudizio di valore adeguato sul fatto che CVS/SVN valessero il loro prezzo "gratuito".

Answer 7

essere in grado di gestire ramificazioni e biforcazioni è un inizio.

Prova a usare sovversione per un po' in parallelo a vss: molto probabilmente troverai molti argomenti per convincere il tuo capo.Se non lo fai, il tuo capo ha ragione, non c'è motivo di cambiare.

Answer 8

Portali su Google per "problema vss", "corruzione sicura della fonte" o semplicemente cercalo nella pagina Wiki.Ciò dovrebbe convincerli che probabilmente non è una cosa fattibile a lungo termine su cui scommettere su una parte così vitale della tua attività.

Quanto è grande la tua squadra?(cioè, intendo quanti membri, non se siete o meno degli schivatori di insalata) Una volta che inizi ad avere più di una mezza dozzina di utenti piuttosto attivi, VSS ti farà venire il mal di testa.

Dubito seriamente che Microsoft lo utilizzi (in effetti, non usano una variante personalizzata di Subversion o CVS?) e devi chiederti: se l'azienda non mangia il proprio cibo per cani, perché dovresti mangiarlo tu?

Answer 9

La risposta di base è che è necessario dimostrare che il passaggio soddisfa le esigenze dell'azienda.Per esempio:

1. minori costi di sviluppo
2. programma più breve (un'altra sfumatura di #1)
3. più adatto a soddisfare i requisiti del processo (come la tracciabilità dei requisiti software o la riproducibilità della build, ecc.).

Per sostenere queste cose occorre anche qualcosa di quantitativo, non solo "abbasseremo i costi perché questa è la cosa". Giusto modo di farlo!".

Una cosa a cui prestare attenzione è che è troppo facile per uno sviluppatore convincersi che sarebbe vantaggioso apportare la modifica senza prima passare attraverso i filtri aziendali di base.Una volta che ciò accade, ci si ritrova con sviluppatori insoddisfatti dei propri strumenti e doppiamente frustrati perché pensano che il management non ascolterà.Se non riesci a spuntare una delle cose sopra, non avrai alcuna possibilità di convincere la direzione di qualcosa (a meno che la direzione non sia incompetente, ma questa è un'altra domanda).

Answer 10

Perché Subversion su VSS?

• Software gratis
• Più facile da gestire
• i "check-in" sono atomico!
• Facile da ramificare e unire
• Sviluppo continuo (es.VSS è un vicolo cieco)
• Strumenti migliori per tenere traccia delle modifiche e visualizzare i registri
• Set di strumenti e piattaforma indipendente, ma si integra anche con molti strumenti

Ho fatto la proposta al mio manager ed è stata una vendita abbastanza semplice.L'ho trovato molto più semplice da usare, soprattutto per le ramificazioni (il nostro progetto ha impiegato 5 ore per "condividere e aggiungere" in VSS, quindi ogni operazione ha richiesto tempo extra per essere completata!).

Answer 11

Io ho scritto in precedenza sul motivo per cui VSS non è una buona idea.Potresti essere in grado di ottenere alcune informazioni da questo.Anche Questo articolo E Questo contenere ulteriori informazioni.

VSS 2005 ha coperto alcune delle crepe della versione 6.0, ma non in modo particolarmente convincente.Rimane la stessa base cerebralmente morta.

Answer 12

Anche se non è rotto, c'è un potenziale vantaggio nella migrazione da VSS.Innanzitutto, e cosa più banale, non dovrai acquistare nuove licenze VSS.In secondo luogo, vi sono molti esempi di carenze nel prodotto VSS (alcuni riconosciuti anche dagli Stati membri).La curva di apprendimento per SVN è bassa almeno quanto quella per VSS e, se ci sono sviluppatori più soddisfatti del loro sistema di controllo del codice sorgente, è più probabile che lo utilizzino presto e spesso.Ciò si tradurrà in molti meno rischi per la tua azienda e questo è un buon vantaggio.

Answer 13

@Jason:VSS è rotto.

Penso che il metodo più potente per motivare un cambiamento rispetto a VSS sia sottolineare quanto sia fondamentale una risorsa il tuo codice sorgente.Assumere rischi con la propria integrità non è una saggia scelta aziendale.

Aggiungi che i tuoi programmatori sono i creatori di questa risorsa e che rendere più semplice per loro la produttività significa più valore nella risorsa del codice sorgente.Joel su Software parla spesso di come investire nei suoi programmatori sia una grande vittoria per la sua azienda.

Le altre risposte qui descrivono tutte ragioni specifiche a cui puoi indicare quando sollevi il tuo caso.

Answer 14

Oltre ai punti tecnici forniti in altre risposte, potrebbero esserci ragioni non tecniche nascoste per le quali dovresti essere pronto a rispondere a:

Dovresti indagare se la tua azienda ha qualche tipo di politica contro (o paura sbagliata) del software open source.Se l'azienda o i suoi avvocati non capiscono i dettagli di quali licenze "infettano" il codice proprietario e quali no, così come cosa puoi fare con il codice open source che non influisce sul tuo codice proprietario, lo farai hanno difficoltà a convincerli a passare da uno strumento proprietario a uno open source.(E potresti avere un lavoro educativo più grande tra le mani.)

Nel sostenere il passaggio dal proprietario (ad es.VSS) all'open source (ad es.sovversione) dovrai anche essere pronto a difendere la qualità del codice e la mancanza di qualsiasi necessità di garanzia o altri diritti contrattuali relativi al codice.