procedure consigliate per il check in / validazione del codice sorgente

Question

procedure consigliate per il check in / validazione del codice sorgente

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

3

Sto cercando le migliori pratiche seguite dalle grandi organizzazioni per il check-in e le convalide del codice.

Attualmente seguiamo questi passaggi, - Lo sviluppatore scrive il codice - Gli sviluppatori eseguono alcuni test iniziali - Il codice è in attesa di convalida ora - Il capo tecnico esamina il codice (possibili bug, vedi se la convenzione di codifica è seguita, ecc.) - Una volta approvato dal lead tecnico, il codice passa allo stato QA - Una volta che il QA approva, il codice viene archiviato nel bagagliaio.

Ora stiamo passando a un nuovo progetto e stavo cercando alcune best practice che facilitassero il processo. Abbiamo un software personalizzato che mantiene lo stato del codice.

Grazie, Ali

version-control code-reviews source-code

posta bbqtonite 18.08.2011 - 21:51

fonte

4 risposte

Leggi altre domande sui tag version-control code-reviews source-code

Semplici accessor e mutatori beneficiano delle intestazioni di blocco commentate? È necessario creare un'applicazione di inventario

score 4 · Answer 1

Mi sembra una cattiva pratica che non ci siano check-in finché il codice non è pronto per la produzione. Avrei un ramo di produzione e ci sarò tagliato solo quando il codice ha attraversato tutti questi passaggi. la mia versione del tuo processo sarebbe simile a questa:

Lo sviluppatore scrive il codice, lo controlla.
Effettua il test iniziale, controlla le correzioni
Il codice viene revisionato, le modifiche suggerite (se presenti) sono archiviate.
Revisionato da QA, tutte le modifiche / correzioni qui sono archiviate.
Il codice viene trasferito al ramo principale, pronto per essere eseguito gratuitamente in the wild.

Nel tuo esempio, sembra che il check-in venga effettuato solo una volta ogni qualche giorno, in cui il check-in è qualcosa che dovresti fare più volte al giorno.

score 0 · Answer 2

Il codice dovrebbe sempre essere nel controllo del codice sorgente. Il nuovo codice può essere eseguito su un ramo, recensioni, modifiche, miglioramenti sono fatti lì.

Il QA può essere compilato dal ramo.

Dopo l'approvazione finale, unisci in tronco.

score 0 · Answer 3

Sarei d'accordo sul fatto che il codice debba essere archiviato il più spesso possibile, ma non consentire check in che interrompono la compilazione. L'integrazione continua è uno strumento molto valido da usare come pure IMO. Richiedere che tutti i check-in superino il processo di compilazione e i test di unità (e anche la copertura di test se possibile) è un buon modo per garantire che le persone non stiano semplicemente buttando roba sul muro.

I prototipi e altre funzionalità di lunga durata dovrebbero essere inserite in rami separati secondo necessità e potrebbero avere regole meno rigide.

score 0 · Answer 4

Sono d'accordo con gli altri che solo un singolo check-in non è molto buono. Dovresti controllare tutto il tempo, sfortunatamente i VCS "Enterprise" sembrano rendere difficile il check-in, il che è quasi suicidio per quanto posso dire. Principali problemi di integrazione invariabilmente risultato.

Una cosa che vorrei aggiungere: fare una "diff" sul codice nel controllo della versione e il codice che sta per essere controllato. Per lo meno, vedendo il diff ti permetterà di scrivere più commenti di check-in convincenti. Fare una "diff" prima del check-in può impedirti di sovrascrivere le modifiche di qualcun altro o altri errori orribili.