Chi è responsabile dell'installazione di un sistema di build automatizzato?

Sono un project manager presso la mia azienda. Lavoro con alcuni team di sviluppatori che utilizzano un sistema di controllo versione standard noto come CVS. Mi piacerebbe vedere l'integrazione continua e le build automatizzate implementate per aiutare a prevenire problemi con la rottura della build e con cattive distribuzioni che si intrufolano sui server di produzione.

Sono sicuro di poterlo impostare da solo, ma non voglio farlo da solo per due motivi:

1. Non ho tempo per questo. Ho le mie responsabilità, che coinvolgono marketing, comunicazione ad altre parti interessate con membri del team che non fanno parte dello sviluppo, comunicazione con i clienti e pianificazione del progetto.

2. Ancora più importante, sono il project manager. Il mio scopo è quello di fornire la leadership, non di micro-gestire il team di sviluppo .

Quali sono alcune cose che posso fare per trovare qualcuno nel team di sviluppo che sarebbe appassionato di creare questo? Uno sviluppatore è la persona giusta per questa attività, considerando che richiede la conoscenza di Java, Spring e Google App Engine? Quali sono alcuni suggerimenti per aiutare a promuovere il cambiamento dove si teme il cambiamento?

Per prima cosa avrei cercato alcune possibilità. Ad esempio, Hudson è un server di integrazione continua piuttosto popolare ed è estremamente flessibile. Puoi inviare un'e-mail al tuo team di sviluppo con qualcosa del genere:

Vorrei introdurre uno strumento di integrazione continua in modo che le revisioni tossiche emergano molto prima che poi. Ho guardato [hudson, acme CIS, foo] e tutti sembrano funzionare. Dato che stiamo usando CVS con [elenco avvertenze qui], sto cercando consigli e vivrò con tutto ciò che il team decide.

Dave, per favore prenditi cura di ottenere un consenso e metterlo in pratica. Team: per favore, dai il tuo contributo a Dave entro la fine della giornata di giovedì, così possiamo testarlo venerdì.

Vi prego di inviarmi le mie credenziali una volta stabilito qualcosa.

Questo approccio ha i seguenti vantaggi:

• Stai delegando, non dumping
• Le persone sanno che hai fatto qualche ricerca, la qualità delle cose che fai notare aiuta a definire le tue aspettative per la qualità dello strumento implementato
• Sei a conoscenza di [avvertimenti], non lasciamoci deragliare discutendoli a meno che non siano davvero dei rompicapo per il compito da svolgere
• Permetti un po 'di democrazia. Certo, effettuerai il login per vedere se qualcosa si è rotto, ma le persone che hanno a che fare con un CIS saranno quelle che sceglieranno la piattaforma.

Nel mio finto scenario, è Davestato selezionato perché ha il minimo nel suo piatto e probabilmente non avrebbe problemi a configurare un nuovo server. A seconda del carico di lavoro, Davepotresti dover essere tu. È così soggettivo che lo menziono semplicemente. Non puoi sempre dire not my job to do thatsoprattutto se sei l'unico che ha il tempo di farlo. Se tutti stanno già trascinando nel tempo, la loro percezione della tua disponibilità ad aiutare diventa più importante. Misurazione che è un'abilità che sviluppi nel tempo.

In ogni caso, entro venerdì avrai un server CIS o dettagli sul perché ciò non è possibile senza un set aggiuntivo di mani.

Lo vedo andare in tre modi possibili:

1. Chiedi a qualcuno nel team di sviluppo di elaborare una rapida valutazione dei possibili strumenti e di fargli montare qualcosa in fretta. Se i tuoi singoli progetti dispongono di script di compilazione adeguati (ovvero puoi creare progetti al di fuori dell'IDE), dovrebbe essere abbastanza rapido collegarli all'IC.

2. Tratta l'infrastruttura di costruzione come un progetto interno all'interno del tuo team e gestiscila come tale. Un po 'più coinvolto rispetto al primo punto, ma se fatto bene otterrai un sistema migliore. Inoltre, diffondere le conoscenze sul team ridurrà il rischio di un'eccessiva specializzazione menzionata di seguito. Ottieni anche i vantaggi della peer-review. Tuttavia, alcuni programmatori possono percepire questo compito come umiliante e come tale potrebbero non spendere tanto quanto dovrebbero.

3. Assumi un dev come build master e fagli installare tutti gli strumenti. Quindi continua a usarlo per migliorare il sistema, aggiungere metriche, generazione automatica di documenti, test automatizzati ecc. Questo è più costoso, ma se fatto bene gli investimenti in questa persona pagheranno molto rapidamente aumentando l'efficienza del tuo team di sviluppo. Questa persona dovrebbe essere competente con le lingue e le strutture utilizzate dal tuo team e avere il desiderio di incollarle in un sistema. D'altra parte (dai commenti) questo potrebbe non rientrare nel budget e la creazione di una posizione specializzata potrebbe portare a una soluzione sotto documentata che può rendere difficili le transizioni.

Detto questo, prima di iniziare qualsiasi cosa assicurati di cosa vuoi davvero. Alla tua domanda mancano alcuni dettagli per indirizzarti nella giusta direzione tecnica. Devi sapere quali vantaggi desideri ottenere utilizzando tali strumenti, hai bisogno di una visione generale del sistema desiderato. Si può fare molto per creare un ambiente che lega tutto, ma senza un piano generale da costruire contro di te si può anche correre in cerchio e rendere le cose più complicate di quello che sono già.

Un manager che una volta avevo detto che gli strumenti sono buoni ma senza un processo sono inutili. Vorrei solo che avrebbe dato seguito a quello che ha detto quando è arrivato il momento di metterli in atto ...

Quindi, se decidi di assumere qualcuno, ci sono chiari vantaggi nell'ottenere un programmatore piuttosto che qualcuno con un background più ITish. Il punto principale è che questa persona può dedicare un po 'di tempo ed energia alla creazione del codice colla e dei plugin che integreranno i diversi sistemi insieme in un sistema coerente.

Spero che questo abbia aiutato

Se hai un ruolo guida, è tuo compito identificare i componenti / le pratiche mancanti e la tua responsabilità vederlo implementato correttamente. Il compito di implementazione può essere delegato o meno, ma alla fine è responsabilità dei leader.

La chiave per l'accettazione è capire, o almeno darti il ​​beneficio del dubbio. Puoi parlare di ciò che vuoi fare e far emergere costi e benefici. Se la discussione non porta alla comprensione, puoi fare affidamento sulla loro fiducia nelle tue decisioni, ma solo se hai creato quel tipo di repoire.

Se il tuo delegato si impegna a limitare i limiti di competenza, presentalo durante uno stand up o una riunione di gruppo e chiedi un volontario. Se nessuno viene avanti, assegnalo semplicemente come faresti con qualsiasi altro lavoro.

aggiornare:

C'è una struttura organizzativa all'interno di ogni azienda. Un ruolo di leadership ha la responsabilità delle risorse a quel livello. Hanno anche la responsabilità di sottolineare e affrontare eventuali problemi. Potrebbero aver bisogno di ulteriori risorse e / o suggerimenti a quel punto salirai la catena. Se riesci a risolvere il problema, hai la possibilità di implementare una soluzione da solo o delegare. Questo può e dovrebbe coinvolgere le persone che influenzerà direttamente, idealmente in collaborazione con loro.

Non posso dire che il livello di direttore e le posizioni sopra indicate non debbano mai essere direttamente responsabili di una determinata persona o gruppo in un'azienda. Dipende molto dalla struttura organizzativa dell'azienda. Ho lavorato in start-up in cui il CTO era direttamente responsabile per sviluppatori e tester. In una più grande gestione aziendale più tradizionale a quel livello non avrebbe la visibilità o la familiarità richieste per prendere le decisioni appropriate a quei livelli inferiori.

Sono principalmente uno sviluppatore e lo installo quando posso (vale a dire quando non mi è espressamente vietato farlo). In generale, poiché i posti in cui lavoro sono negozi .NET, scelgo CruiseControl.NET perché è open source, funziona con la maggior parte dei principali sistemi di controllo del codice sorgente e relativamente facile da usare. Ho sempre desiderato impostare un Ambient Orb come una delle uscite, ma di solito è fuori dal mio controllo.

Presentalo in una riunione per vedere se qualcuno ha il desiderio di farlo, purché non abbia alcun impatto sui progetti su cui sta attualmente lavorando.

Nel mio posto attuale (uno dei laboratori nazionali), l'abbiamo impostato solo per creare le build in modo coerente in modo che le persone che vogliono vedere cosa stiamo facendo siano in grado di ottenere una versione eseguibile in qualsiasi momento . Non vogliono test unitari (l'impressione del project manager è che lo sforzo che mettiamo nei test unitari potrebbe essere stato messo nel porting del progetto su .NET).

Al mio posto precedente, l'intento era quello di rendere le build standard e coerenti tra i prodotti. Troppi prodotti potrebbero essere costruiti solo su un computer speciale (nel caso di un prodotto, che coinvolge un controllo di terze parti con un DRM aggressivo che da tempo era fallito, abbiamo dovuto mantenere in vita una macchina per circa 5 anni dopo la chiusura dello sviluppatore perché il suo era l'unico in grado di costruire questo prodotto di spedizione commerciale ora sostituito). Inoltre, le installazioni potevano essere eseguite da una sola persona mattutina, quindi se avevi bisogno di una build dopo le 15:00, hai aspettato il giorno successivo.

Uno sviluppatore è la persona giusta per questa attività, considerando che richiede la conoscenza di Java, Spring e Google App Engine?

Dipende. Se hai una persona con QA decente nello scripting, chiedi prima di assegnarglielo.

Configurarlo per cominciare non è un compito complicato. La configurazione non dovrebbe richiedere più di un paio di giorni (principalmente in un ambiente aziendale, i problemi stanno ottenendo un account per eseguire le cose con tutte le autorizzazioni necessarie) e iniziare.

Prova a configurarlo da una direzione diversa: quando si verifica un problema nell'ambiente di produzione, affidati al team di sviluppo per risolverlo e risolverlo rapidamente. Quindi introdurre l'idea di un semplice build notturno che viene compilato dall'ultimo codice, timbro versione ecc. Se non riesce a creare non verrà promosso.

Penso che lo script di compilazione dovrebbe essere di proprietà dello sviluppo. Quando modificano le dipendenze o apportano modifiche, sono le migliori a sapere come aggiornare gli script. E dì loro che se il project manager lo possiede, li chiamerai semplicemente in una riunione quando c'è un problema.

Potresti semplicemente dire al tuo prossimo incontro "OK, penso che dovremmo farlo a causa di. Chi può implementarlo" Ti do meglio delle probabilità che qualcuno dirà "Sicuro che lo farò". allora non devi litigare.