Gli sviluppatori dovrebbero "possedere" il / i server / i di costruzione? [chiuso]

Question

Gli sviluppatori dovrebbero "possedere" il / i server / i di costruzione? [chiuso]

#1 da (2 voti)
#2 da (1 voti)

1

Il server di build della nostra azienda fa schifo. Gli agenti di compilazione (ce ne sono una decina, ognuno è una VM separata, e apparentemente vivono tutti sul proprio server ESX) sono SLOW. L'interfaccia web è SLOW ed è in esecuzione su una VM Windows, anche su ESX. Tutto è lento, lento, lento. Il caricamento degli artefatti a volte fallisce per motivi sconosciuti. A volte l'interfaccia web segnala nell'interfaccia utente che ha esaurito la memoria e si blocca poi si blocca. Sembra che l'IT lo stia riavviando almeno una volta al giorno. Oggi stanno ripristinando un aggiornamento minore perché ha causato problemi.

Attualmente IT possiede l'hardware su cui sono in esecuzione i server di sviluppo e non abbiamo visibilità in merito. Abbiamo il controllo admin sul software. Noi (gli sviluppatori) ci lamentiamo costantemente, ma nulla sembra migliorare davvero. Ha senso che gli sviluppatori posseggano il / i server / i di build? L'IT non ha davvero tanto incentivo a renderli affidabili e veloci come fanno gli sviluppatori. Per far sì che l'IT risolva i problemi dobbiamo sporgere denuncia ai nostri manager e poi devono parlare con i loro manager che poi dicono all'IT di ripararlo. Siamo in grado di segnalare problemi direttamente all'IT ma questo non sembra funzionare per risolvere il problema perché l'IT ha molte altre cose di cui hanno bisogno. Inoltre, gli sviluppatori sono quelli che stanno effettivamente utilizzando il sistema di build e probabilmente hanno molta più familiarità con esso rispetto all'IT.

Come funziona in altre aziende?

Siamo circa un'azienda di 150 persone. Quindi probabilmente metà di questo è di tipo ingegneristico, ma un terzo di quello è probabilmente l'hardware, quindi abbiamo circa 40 sviluppatori.

continuous-integration build-system

posta dgrant 04.04.2014 - 22:33

fonte

2 risposte

Leggi altre domande sui tag continuous-integration build-system

Implementazione di oggetti con diverse rappresentazioni equivalenti Utilizzo del software GPL con hardware closed-source

score 2 · Answer 1

Idealmente gli sviluppatori non dovrebbero avere il proprietario del server di build o addirittura mantenere il processo di compilazione da soli. Ogni build in un'azienda deve passare attraverso condotte parametriche comuni che sono state definite per i progetti di costruzione dell'azienda. Ciò offre diversi vantaggi: in primo luogo, gli sviluppatori non devono preoccuparsi del processo di creazione, un team dedicato lo mantiene. In secondo luogo, i nuovi cambiamenti apportati alla pipeline possono portare benefici a tutti contemporaneamente, piuttosto che doverli implementare in dozzine di singoli processi di compilazione. Infine, consente all'organizzazione di ricavare potenti metriche sulla qualità delle loro build su tutta la linea.

Questo non è un sogno irrealizzabile; in realtà lo facciamo nella mia compagnia. 300 ingegneri costruiscono diverse centinaia di progetti nella stessa pipeline su base regolare, e a volte abbiamo migliaia di corse attraverso la pipeline in un solo giorno, tutte costruite e distribuite automaticamente alla produzione. Funziona incredibilmente bene, perché abbiamo una strong enfasi sui principi di Continuous Delivery, come spiegato dal libro canonico sull'argomento .

La mia organizzazione non è arrivata da un giorno all'altro. Richiedeva il buy-in dai dirigenti in cima. Siamo stati allo stesso punto della maggior parte delle persone circa due anni fa: build individuali per progetti e configurazione manuale e distribuzione negli ambienti. I seguenti principi di Continuous Delivery hanno prodotto enormi benefici per gli sviluppatori.

Quindi, come ho detto, nella mia mente è la strategia ideale per le build e le implementazioni. Ma sembra che il tuo dipartimento IT non abbia ancora acquisito l'idea di fornire sistemi e processi di generazione di qualità. Se non riesci ad ottenere assistenza dal tuo reparto IT, allora il mio suggerimento sarebbe provare a eseguire il tuo processo per ora con i tuoi server di build se hai la libertà organizzativa di farlo. Lasciare l'IT a fare le tue cose è un modo sorprendentemente efficace per convincerle a offrirti un supporto migliore. :)

score 1 · Answer 2

In passato, ho avuto esperienze molto positive con un team di sviluppo dedicato composto da pochi sviluppatori che hanno segnalato al dipartimento QA. Le build del team di build erano il gold standard dell'azienda. Se la tua build fosse rotta, non l'accetterebbe. Il codice spedito proviene dai loro server solo . Ciò ha fornito un sacco di incentivi per ogni squadra per garantire che le loro build e test unitari fossero equilibrati. Questo ha funzionato molto bene in una compagnia di circa 120 sviluppatori e 40 QA che coprono circa 15 squadre.

Secondo me, ogni squadra è responsabile delle proprie build ma non del server di build. Lascia sviluppare gli sviluppatori! Un team di build è responsabile per i server di build e per la collaborazione con ogni rispettivo team per garantire la sicurezza di build e test.

Potresti voler adottare un approccio "di base". Se hai la possibilità di mettere da parte il tuo hardware, configurerei un personal build server e imposterei l'esempio. Una volta che la parola viene fuori che sei in grado di fornire rapidamente build di successo e ripetibili, altri vorranno adottare la tua strategia. Speriamo che questo incoraggi il buy-in da parte di coloro che hanno il potere di apportare le modifiche necessarie.