Differenza tra DevOps e Gestione della configurazione software

Qual è la differenza tra operazioni di sviluppo e gestione della configurazione del software?

Per me sembra essere lo stesso fintanto che sia DevOps che Software Configuration Management sono focalizzati su:

1. Creazione dell'infrastruttura di sviluppo - incaricato del controllo della versione , della gestione della build, della gestione della distribuzione, della gestione delle dipendenze, dell'integrazione e della consegna continue , ecc.
2. Utilizzo delle migliori pratiche per l'organizzazione dell'ambiente degli sviluppatori .
3. Assicurazione della qualità dei processi di sviluppo: raccolta di metriche sull'efficacia dello sviluppo, lavoro per eliminare le strozzature del processo di sviluppo (esecuzione di unit test, valutazione della copertura di unit test, esecuzione di ispezioni, ecc.)
4. Gestione dell'infrastruttura : piattaforme target e sue specifiche.
5. Gestione delle versioni: accertarsi che la versione sia stata consegnata al cliente / cliente in tempo.

Forse mi manca qualcosa? Questo collegamento mostra che prevale l'uso del termine "Gestione della configurazione del software". Tuttavia, quale combinazione di parole preferiresti utilizzare per descrivere una serie di attività elencate: Operazioni di sviluppo o Gestione della configurazione del software ?

I termini descrivono concetti e responsabilità molto simili, e in generale sono in qualche modo sinonimi. Il termine "DevOps" è relativamente nuovo, reso popolare dalla conferenza Devopsdays Ghent 2009 e dai successivi eventi Devopsdays . È meglio descritto in questo diagramma :

D'altra parte, Software Configuration Management è un termine molto più consolidato all'interno della professione e deriva dal termine non specifico del software Configuration Management . La gestione della configurazione del software viene spesso citata in un contesto di ingegneria del software, una semplice definizione è data da Roger Pressman in "Ingegneria del software: un approccio da professionista" :

è un insieme di attività progettate per controllare i cambiamenti identificando i prodotti di lavoro che possono cambiare, stabilendo relazioni tra loro, definendo meccanismi per la gestione di diverse versioni di questi prodotti di lavoro, controllando le modifiche imposte e verificando e riferendo sulle modifiche apportate.

Sebbene tutti i termini a cui fai riferimento siano vaghi, DevOps sembra essere solo un modo meno formale di descrivere più o meno lo stesso insieme di principi di Gestione della configurazione o Gestione della configurazione del software se visto dal punto di vista di uno sviluppatore di software, in particolare dando la priorità ai team strettamente accoppiati :

DevOps è una risposta alla crescente consapevolezza che esiste una disconnessione tra ciò che è tradizionalmente considerato attività di sviluppo e ciò che è tradizionalmente considerato attività operativa. Questa disconnessione si manifesta spesso come conflitto e inefficienza.

Nello stesso articolo, si notano le somiglianze con SCM:

L'aggiunta al Wall of Confusion è la discrepanza fin troppo comune negli strumenti di sviluppo e operazioni. Dai un'occhiata agli strumenti popolari che gli sviluppatori richiedono e utilizzano quotidianamente. Dai un'occhiata ai popolari strumenti che gli amministratori di sistema richiedono e utilizzano quotidianamente. Con alcune notevoli eccezioni, come i bug tracker e forse SCM , è dubbio che vedrai molto interesse nell'uso degli altri strumenti o una significativa integrazione tra loro. Anche se vi è una certa sovrapposizione nei tipi di strumenti, spesso le implementazioni saranno diverse in ciascun gruppo.

Per quanto riguarda l'uso dei termini, il tuo confronto non ha davvero senso:

1. SCM è un sottoinsieme di CM, non un termine competitivo,
2. DevOps è un termine abbastanza nuovo, inutile confrontarlo con termini stabiliti,
3. DevOps deriva dalle operazioni degli sviluppatori (ovviamente) ma raramente viene espanso come tale.

Personalmente come Sr. Software Configuration Manager per molti anni (10+) Sento i termini non corrispondenti in una varietà di situazioni di vita reale. Non è insolito per il personale non tecnico a causa della natura relativa delle posizioni. Entrambi hanno ruoli, esigenze e requisiti specifici simili ma che a mio avviso possono essere chiaramente divisi.

Credo che il modo migliore per descrivere la divisione di questi ruoli sia concentrarsi sulla loro relatività all'interazione. Ciò significa che Software Configuration Management si concentra sui sistemi e gli ambienti interni, insieme all'integrazione, implementazione, rilascio e gestione del codice sorgente. Where as Developer Operations (DevOps) si concentra maggiormente sull'aspetto operativo dell'architettura delle applicazioni esternamente affrontata, pur mantenendo una chiara comprensione del codice come era destinato all'uso e alla pratica del suo ambiente. Se le prestazioni di una macchina mostrano segni di degrado, la comunicazione tra più applicazioni è difettosa, le comunicazioni tra business to business (BtB) e / o le limitazioni dell'architettura in relazione a un ambiente di produzione, quindi si dovrebbe cercare le operazioni degli sviluppatori per la loro diagnosi e soluzione.

In genere, nella mia esperienza, il Software Configuration Manager può fare anche queste cose, ma ciò toglie il loro focus principale di tracciamento, gestione e distribuzione delle configurazioni ambientali e delle revisioni del software. Gestione del software che consente la separazione delle funzioni, il monitoraggio di bug e difetti, il monitoraggio del progetto, il ciclo di vita dello sviluppo del software e il worflow. Queste attività non sono al centro delle operazioni degli sviluppatori e quindi meno imperative, ma possono ancora essere eseguite.

Ho visto molti esempi della confusione di ciascuno, e in ognuno c'è un crossover limitato. Tuttavia, è molto importante pensare alle differenze tra le responsabilità di ciascuna delle posizioni indipendenti in relazione al loro obiettivo principale. Soprattutto quando si ha a che fare con sistemi e hardware utilizzati internamente per gestire la configurazione degli ambienti e il rilascio del prodotto, si dovrebbe cercare un Software Configuration Manager. D'altra parte, quando si ha a che fare con le prestazioni del sistema, il monitoraggio, la ricerca e la diagnosi dei sistemi utilizzati dai propri clienti, è necessario consultare le Operazioni degli sviluppatori o DevOps.

Ora, questo non è inteso come un rant, né come una risposta definitiva, ma piuttosto un'identificazione personale delle differenze di ciascuna delle posizioni. Vorrei sapere se sto benissimo, o se le cose sono chiarite da questa risposta.

Saresti spinto a trovare una solida definizione per DevOps. È più un'idea che un lavoro da svolgere. Ed è un'idea troppo nuova per tutti per concordare esattamente cosa significa. Tuttavia, ecco la mia opinione.

DevOps è in realtà solo un nuovo termine per la gestione della configurazione, ma è stato scelto per dimostrare che il ruolo non è un ruolo individuale, è una collaborazione tra il team di sviluppo e il team operativo.

Storicamente, la gestione della configurazione sarebbe stata eseguita esclusivamente dal team di sviluppo e quindi passata a operazioni che avrebbero visto tutto con profondo sospetto. Il che è abbastanza giusto, a dire il vero. Ne sono responsabili. Sono i primi a essere chiamati alle 4 del mattino quando va storto. Dovrebbero davvero avere un certo coinvolgimento nel suo sviluppo.

Questo è il semplice chiarimento alla domanda: DevOps è un termine usato per descrivere il coordinamento o la relazione tra Sviluppo (sviluppo dei codici di programma in ambiente di sviluppo) e Operazioni (che garantisce il massimo tempo di attività dell'ambiente di produzione).

La gestione della configurazione del software è un mezzo per raggiungere questo coordinamento. SCM ha coinvolto strumenti e tecniche per gestire l'automazione del processo di passaggio dallo sviluppo alla produzione (operazioni)

Per riassumere, SCM collega Dev e Ops.

Vedo che DEVOPs è alla fine dell'esecuzione operativa: script di automazione della distribuzione, buildout dell'ambiente, questo genere di cose. SCM, d'altra parte, riguarda l'integrità dei prodotti e l'effettiva gestione e tracciabilità delle modifiche ai prodotti. Ho sempre visto ALM come parte di SCM - dopo tutto, come mai puoi gestire le modifiche a un prodotto se non hai idea dei driver per la modifica o di chi le ha apportate? I quadri di distribuzione potrebbero cadere da una parte e dall'altra parte dipenderà invariabilmente dalle esigenze normative dell'organizzazione per cui lavori - dopo tutto - vuoi che uno sviluppatore sia in grado di eseguire un hack rapido, il che significa che la tua macchina per dialisi funziona correttamente solo al 99,99% del tempo o hai bisogno di quella situazione per permetterti di hackerare il codice del tuo sito web perché i tuoi sviluppatori hanno indirizzi IP hardcoded?