Quanti sforzi ci sono per mantenere un sistema di compilazione?

9

In StackExchange Podcast n. 09 viene osservato:

Un altro studio ha recentemente esaminato quanti sforzi vengono fatti per mantenere il sistema di compilazione: dal 5 al 30% di tutto lo sforzo di sviluppo viene speso per mantenere il sistema di compilazione. Le variazioni sono enormi anche quando si lavora su progetti simili.

Qual è il nome dello studio a cui si fa riferimento e dove può essere trovato? L'audio del podcast non contiene ulteriori dettagli.

Inoltre, qualcuno ha collegamenti ad altri studi riguardanti lo stesso argomento.

commandline-build-tool

— Neil Mitchell
fonte

3

Wow. Non ho mai pensato che un negozio potesse passare così tanto tempo su un sistema di costruzione. Abbiamo un sistema di compilazione fatto a mano e personalizzato che esegue build notturne di tutte (20 alcune) versioni e (50 alcune) filiali di sviluppo (se sono state apportate modifiche), avvia test unitari e arresta e avvia server di test (uno o più per release e una o più per molte filiali di sviluppo), risultati di posta ecc. Eppure nei 4 anni in cui sono stato presso questo datore di lavoro, non credo che ci abbiamo passato molto più di un paio di settimane di lavoro e che include l'estensione delle funzionalità della nostra soluzione personalizzata!

— Marjan Venema,

Questo è ciò che accade quando le persone si riferiscono a qualcosa / qualcuno e dimenticano di aggiungere i riferimenti ...

— wleao,

Non conosci lo studio, ma i risultati possono differire a seconda di ciò che definisci "mantenendo il sistema di compilazione". "L'aggiunta o la modifica di file" fa parte di questo? La configurazione di un programma di installazione fa parte del "mantenimento del sistema di generazione"?

— Doc Brown,

1

Non ho ascoltato il podcast, ma lo studio è probabilmente un articolo del più recente ICSE , chiamato "Uno studio empirico sullo sforzo di manutenzione delle costruzioni" di Shane McIntosh et al. Controlla il collegamento diretto (o la pagina DOI ufficiale se vuoi i metadati).

Il loro studio si concentra principalmente sulla frequenza con cui le modifiche al codice sorgente influiscono sulla build e su quanti sviluppatori di un team si preoccupano in genere di mantenere la build. Ricordo che è uno studio interessante, ma ho trovato i numeri un po 'difficili da interpretare, come spesso accade negli studi empirici che cercano di trovare connessioni tra le cose :)

— Deckard
fonte

2

Non ho un collegamento per te, ma parlando per esperienza personale, tale percentuale varia in base a 2 punti principali: 1) progettazione e complessità del sistema 2) e organizzazione personale

Un sistema ben progettato richiederà uno sforzo minimo per essere mantenuto anche se è piuttosto complesso. Ma se il tuo personale non è adeguatamente formato e organizzato nella gestione del codice, probabilmente passerai molto tempo a correggere build errate o commit errati e cose simili ...

Tuttavia, quando si dispone di un ambiente di sviluppo, domande e risposte, RC e produzione ... Tutto prende il suo pedaggio sul processo che va dallo sviluppo alla produzione effettiva.

Direi che le percentuali sono corrette, avvicinandosi al segno del 30% rispetto al 5%. Se tutto ciò che stai investendo è del 5%, stai facendo un buon lavoro. (Ciò include errori riscontrati durante domande e risposte o RC o persino produzione dovuti alla cattiva gestione del sistema di costruzione, che può causare enormi ritardi).

— AJC
fonte

Se tutto ciò che stai investendo è del 5%, ti suggerirei di non misurare tutto o accuratamente.

— Mattnz,

non opaco. Stai usando una definizione diversa. La maggior parte delle aziende per cui ho lavorato NON ha un sistema di build in atto, come in nessun server di build automatizzato, integrazione VCS (spesso nessun VCS a eccezione di quali progetti stessi potrebbero essere configurati da soli, che finiscono sotto il radar), ecc. In qualsiasi "studio" della percentuale di risorse utilizzate per mantenere il "sistema di costruzione" finirebbero per essere elencate come spese quasi nulla, a meno che non fossero suddivise per includere lo sforzo speso per mantenere tutti gli script ANT e Maven, qualcosa fatto raramente.

— jwenting