In una grande organizzazione che si occupa del miglior sviluppo del software, l'infrastruttura di sviluppo è il dominio dell'IT, come dovrebbe essere. Questi server sono solitamente bloccati come qualsiasi altro server e gli sviluppatori non hanno accesso root a queste macchine. (Verrà concesso l'accesso root amministratore di Office al server di posta elettronica aziendale) IT avrà uno SLA con sviluppo che copre disponibilità, backup, prestazioni, ecc. I ragazzi IT forniscono supporto per gli strumenti di sviluppo software grezzi - GIT / Jenkins / Redmine / Clearcase ecc. - sicurezza, gestione della licenza e degli utenti, aggiornamenti software ecc. Di solito c'è un team di strumenti specializzato nella creazione e personalizzazione degli strumenti sui server e nella garanzia che gli sviluppatori dispongano degli strumenti necessari per portare a termine il lavoro. Il team degli strumenti spesso riferisce al responsabile dello sviluppo, ma lavora a stretto contatto con il team IT e di solito sono sviluppatori di software a sé stanti: la natura della bestia è che le due squadre sono strettamente legate, ma vi sono chiare linee di responsabilità. Il team di strumenti può essere parte dell'IT, ma non tutti gli IT hanno le competenze.
Poche aziende lavorano in questo modo. L'IT non 'ottiene' lo sviluppo del software e lo sviluppo del software non 'ottiene' l'IT. A IT piace stabilità, sicurezza e continuità di servizio. SD vuole l'ultima: vogliono tutto e lo vogliono subito. Di conseguenza, in quasi tutte le organizzazioni per le quali ho lavorato, la SD mette in secondo piano i server "dietro le quinte" dell'IT. Li tollera, purché non causino problemi, ma li lavi completamente da loro. I backup sono spesso carenti, e SLA - diamine, se si rompe, "l'abbiamo costruito, lo ripareremo". Gli strumenti sono spesso pochi script hacked-up che funzionano la maggior parte del tempo e non ci sono veri e propri budget per il sistema. Non importa quando si rompe, perché nessuno sa veramente cosa fanno gli sviluppatori di software tutto il giorno, quindi viene corretto e viene messo il tempo in "funzionalità XYZ" di ciò che ogni prodotto ha un budget di progetto abbastanza grande .... .
Quindi, per rispondere alla tua domanda: i server di sviluppo di solito non sono considerati, quindi non hanno idea della loro importanza relativa. La soluzione corretta è che sono considerati nella pianificazione aziendale.
Di solito ciò che accade quando uno fallisce, come ho detto, viene risolto, il manager corre chiedendo perché, promettendo di risolverlo, e tutto torna a come era quando i costi lo facevano correttamente .... ...
Gestire l'infrastruttura di sviluppo - ovvero l'IT (gli OP che penso tu abbia chiamato) - i responsabili della produzione. Gli sviluppatori di software non dovrebbero essere autorizzati nelle vicinanze dell'infrastruttura di sviluppo, ad eccezione degli utenti.
Nella piccola casa, IT e SD sono spesso le stesse persone, in questo caso è importante per loro capire la differenza nei ruoli e imparare a indossare e togliere i "cappelli".
In risposta al tuo blog ....
Hai entrambi ragione. Il server di produzione è più importante, il suo fallimento creerà un'interruzione istantanea, ma ciò non rende l'infrastruttura di sviluppo. irrilevante. Se i sistemi di sviluppo falliscono (irrecuperabili), lo stesso vale per il business. Da qualche parte, esiste un rapporto costi / benefici tra il costo da proteggere e il costo del fallimento. L'azienda deve decidere quanto è disposto a investire la capacità di recupero del disastro. Chi è il migliore si qualifica per quantificarlo? Suggerimento: non è uno sviluppo software