Assicurare qualità e bug Correggere la velocità nel progetto Python open source

Question

Assicurare qualità e bug Correggere la velocità nel progetto Python open source

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

1

Sto mantenendo un framework open source (in Python su piattaforme * nix se questo è importante) per la prima volta nella mia vita. È praticamente pre-alfa, non molto più di una dimostrazione scientifica del concetto, ancora. Ma è anche già utilizzato in produzione da un altro dipartimento perché è l'unico framework globalmente adatto alle loro esigenze. Ora ci sono due obiettivi polari: qualità e velocità di sviluppo.

Ovviamente voglio qualità sotto forma di documentazione, unit test, revisioni del codice e qualche tipo di utilizzo "beta", prima di essere sicuro di poter utilizzare un cambiamento nella produzione. Ma il team di sviluppo ha delle linee morte e quando trovano un bug, che capita piuttosto spesso in questo prototipo, allora hanno bisogno della correzione del bug per essere in produzione molto velocemente. Al momento non ho soluzioni funzionanti e le nostre idee divergono.

Penso che questo progetto non possa essere l'unico con questo problema. In che modo altri progetti lo risolvono?

Pubblicherò la mia idea e l'idea dei team di sviluppo come risposte per ulteriori discussioni, entrambe le soluzioni non sono comunque una soluzione, perché la mia idea si concentra essenzialmente sulla qualità e la loro soluzione si concentra solo sulla velocità.

open-source project-management quality speed

posta erikbwork 14.04.2013 - 00:17

fonte

3 risposte

Leggi altre domande sui tag open-source project-management quality speed

Best practice per il mantenimento di lettere maiuscole e dati del caso corretto Classi nidificate vs namespace

score 1 · Answer 1

Potresti scoprire che all'inizio, se ci sono molti bug che richiedono correzioni, allora qualcosa come la preferenza del team di sviluppo è più appropriata. Una volta che il codice è un po 'più stabile, puoi passare più a quello che hai in mente.

score 0 · Answer 2

La mia soluzione:

Ci sono due rami:

master contiene solo build stabili e testate
dev contiene lo stato di sviluppo del bordo più sanguinante
f-<xyz> feature branch, che contengono funzionalità e correzioni di bug attualmente in fase di sviluppo e non ancora riconosciute per il ramo dev ; questo è possibile perché la maggior parte delle persone che lavorano al progetto hanno il permesso di scrittura per il repository, che è la regola aziendale

Ogni richiesta di funzionalità o bug dovrebbe seguire la seguente procedura:

Scrivi un problema nella pagina del progetto, che contiene la descrizione del problema, la soluzione suggerita e ulteriori note come il nome del ramo della funzione.
Effettua il check-in e invia le modifiche al ramo della funzione e fai riferimento al problema.
Trova 2 persone per esaminare e riconoscere il tuo cambiamento (cercando errori, testo non chiaro, che la documentazione sia aggiornata e che ci siano test unitari per la modifica)
Dopo aver ottenuto 2 ACK, trova un maintainer per unire la tua modifica al ramo dev.

Questo processo dipende da almeno altre 2 persone (se uno di loro è un manutentore) e anche dopo non è ancora stato rilasciato, è solo nel ramo dev .

Perché si verifichi un rilascio: 1. Qualcuno deve preparare il rilascio * trova un impegno significativo per il rilascio del candidato * ricontrollare per stabilità, qualità e documentazione * Contrassegna il candidato al rilascio * ottenere l'ok a un incontro di progetto settimanale attraverso voti

Tutti gli utenti devono utilizzare l'ultima versione o devono essere in grado di adattare il loro codice alle modifiche strutturali e ai bug inattesi, se utilizzano direttamente il ramo dev .

Come detto nella domanda, questo riguarda principalmente la qualità e la longevità del progetto, che è il mio obiettivo principale. Naturalmente anche il team di sviluppo in un ambiente di produzione ha bisogno di velocità.

score 0 · Answer 3

Soluzione del team di sviluppo:

È necessario un solo ramo: master . Tutti possono spingere a quel ramo e le recensioni non sono necessarie. Ogni organismo è responsabile del fatto che HEAD di questo ramo funzioni correttamente e non stia rompendo i progetti che si basano su di esso. Le soluzioni dovrebbero essere aggiunte quando necessario e la garanzia della qualità, in quanto la documentazione e i test unitari possono essere aggiunti in seguito.

Non penso che in questo approccio ci sia qualcosa che manterrà la qualità viva. Il team di produzione non avrà mai il tempo di scrivere documentazione e unit test e nessuno rivedrà il codice.