Strumenti e / o metodi per la revisione periodica del codice del team di sviluppo remoto

7

Stiamo esternalizzando uno sviluppo a un piccolo gruppo di sviluppatori offshore. Il nostro processo interno per la revisione del codice è manuale, basato su carta, basato su un modello a cascata che richiede la consegna "big bang". Non può essere cambiato. L'esperienza passata è che questi sviluppatori sono abili e affidabili, tuttavia arriva il momento di consegnare, il sovraccarico delle recensioni diventa un onere difficile per tutti i soggetti coinvolti e le questioni sono state scoperte troppo tardi.

Usiamo CVS per il nostro repository sorgente. Prendono una copia del repository CVS, ricevono aggiornamenti regolari alla base di codice più recente e utilizzano GIT localmente per gestire le loro modifiche. Quando sei pronto per la consegna, inviaci un archivio di un clone CVS aggiornato con il loro lavoro integrato. Quindi eseguiamo la revisione del codice e lo controlliamo.

Stiamo cercando una catena di strumenti per supportare un processo di revisione del codice in cui possiamo eseguire revisioni regolari e leggere al di fuori del nostro processo interno, in modo che quando il processo interno cominci, possiamo farlo in modalità "go fast" ho già recensito la maggior parte del codice.

I limiti sono che i sistemi e i nostri sono scollegati. Usiamo sneaker net per trasferire file tra di noi. Il meglio che possiamo fare è avere una macchina in casa che le VPN siano nel loro sistema.

La fonte è un codice commerciale e non può essere collocata ovunque sia esposta a Internet.

Un'opzione che hanno suggerito è Gerrit - che intendono utilizzare sul loro sito. C'è un modo per condividere e sincronizzare il database gerrit tra i siti, data la limitazione della rete sneaker? Qualcun altro ha una soluzione a questo tipo di problema?

    
posta mattnz 11.08.2011 - 12:21
fonte

2 risposte

4

yuk, waterfall - > cvs - > git ... sembra che sia un disastro in attesa di succedere ma ...

Il tuo miglior approccio per le revisioni del codice IMHO è Redmine con il plugin per la revisione del codice. Si crea un progetto in redmine e si comunica al repository dove risiede il codice, quindi è possibile visualizzare il codice utilizzando il browser repo integrato.

Il vantaggio qui è che solo guardando il repository collegato al progetto vengono mostrati i changeset e le differenze tra le modifiche. Con il plug-in di revisione del codice, puoi facilmente contrassegnare sezioni di codice con commenti. Questo genera un ticket (cioè un bug) nel progetto.

Questo è veloce e semplice, si finisce con una serie di ticket che possono essere assegnati e tracciati. Non richiede la condivisione del codice sorgente poiché si collega direttamente al repository CVS locale. Tuttavia, i ticket potrebbero essere difficili da visualizzare se il sistema di redmine non è disponibile per il team di outsourcing, ma puoi esportarli in Excel, PDF o e-mail.

    
risposta data 11.08.2011 - 13:01
fonte
4

Trovo strano questo problema a causa della strana relazione che hai con la tua organizzazione di sviluppo offshore.

Le mie esperienze nel lavorare con un team di sviluppo offshore SUCCESSFULLY è che si integrano al 100% nel tuo team di progetto esistente, e questo include:

  • Strumenti : il team offshore dovrebbe lavorare nello stesso ambiente di controllo del codice sorgente dell'utente. Andare a Git è una scelta molto più importante rispetto a CVS, tuttavia è meglio che si integrino nel TUO controllo del codice sorgente. Sei il loro cliente dopotutto.
  • Ambienti - Perché stai collegando VPN alla rete THEIR? Dovrebbe essere il contrario e dovrebbero farlo per controllare a distanza il codice nel TUO controllo del codice sorgente. Questo dà l'ulteriore vantaggio di liberarsi del disordine manuale di cui soffre da ora.
  • Comunicazione - Questo è difficile e non ha una risposta facile. Le differenze nel fuso orario sono sempre un ostacolo enorme.

Quindi, in breve, l'unica risposta al tuo dolore è il processo molto politico che impedisce loro di integrarsi completamente nel TUO team di sviluppo che hai identificato come "non può essere modificato". Qualche suggerimento per migliorare questa situazione incasinata sarà come dare a Tylenol una gamba rotta. Non verrà risolto finché non saranno superati questi supposti ostacoli.

    
risposta data 11.08.2011 - 13:05
fonte