DevOps è limitato alle aziende con prodotti SaaS?

Le pratiche che descrivono DevOps, come consegna continua, automazione, ecc. Sono rilevanti per i prodotti che forniscono un servizio continuo, come i prodotti SaaS.

Ad esempio, una società di sviluppo software che realizza progetti per altri clienti potrebbe non essere mai mantenuta dopo la fine del progetto. E i progetti client non sono condivisi con altri client, perché irrilevanti.

DevOps si applica anche alle aziende che sviluppano più progetti unici? Quali pratiche DevOps si applicano in questo caso, se non del tutto?

Assolutamente no!

DevOps si basa sull'eliminazione dei silos (dipartimenti) tradizionali per essere più efficienti.

Una migliore comunicazione tra i team, una migliore visibilità e un processo affidabile e automatizzato sono i modi per ottenere un prodotto migliore.

Lavoravo per una grande azienda di media in cui sostenevamo uno strumento interno e sviluppavamo siti Web rivolti al pubblico.

I vantaggi di DevOps nel nostro caso sono stati i seguenti:

• Attraverso la costruzione continua, informiamo il team di sviluppo prima piuttosto che dopo se ci sono integrazione o problemi di costruzione con il loro codice. Possono risolvere i problemi mentre la loro mente è ancora sul pezzo di codice che hanno appena impegnato.
• Tramite test e consegna continui (nel QA), abbiamo consentito al team addetto al QA di individuare i problemi in anticipo e di segnalarli prima. Ciò ha ridotto il tempo necessario per trovare e correggere i bug, nonché ridurre la complessità di queste indagini.
• Con i nostri strumenti di raccolta e aggregazione dei log, abbiamo dato agli sviluppatori l'accesso a qualcosa che di solito non guardavano (erano molto entusiasti dei debugger :) - capire come i log sono visti e utilizzati da altri team ha migliorato la qualità generale dei log
• Abbiamo spesso condiviso informazioni e creato documentazione per condividere le conoscenze tra i team, cercando di abbattere i muri. Comprendendo le esigenze di Ops, creiamo alcune guide su ciò che dovrebbe sempre essere tenuto presente quando si avvia il bootstrap di un'applicazione (dove / come gestire le proprietà, ecc.). Comprendendo la realtà del Dev (codifica più funzionalità, più velocemente, gogogogo!) Siamo riusciti a far sì che le operazioni operative creassero server e cluster più adatti alle esigenze del dev.
• Anche la qualità complessiva delle distribuzioni è stata notevolmente migliorata. Le implementazioni sono state gestite dal nostro team, quindi abbiamo avuto una visibilità perfetta sia su Ops sia su Dev. Ciò ha eliminato molti problemi relativi al "trasferimento di codice" in cui lo sviluppatore avrebbe consegnato un pacchetto e un documento di una pagina alle operazioni dicendo "Installa questo!".

Nel complesso, direi che indipendentemente dal fatto che stai aggiornando il tuo ambiente di produzione una volta al giorno o una volta al mese e indipendentemente dal numero di clienti che hai o dal tuo modello di business, ogni azienda può utilizzare una migliore comunicazione, strumenti migliori, migliore visibilità, feedback più veloce, eccetera.

Il mio team e io siamo responsabili dello sviluppo di "pezzi unici", prodotti che una volta finiti vengono consegnati al cliente per la manutenzione o in alcuni casi gestiti da noi a pagamento.

Dobbiamo ancora mantenere una solida pipeline di sviluppo per gestire il costante feedback dei nostri clienti al fine di garantire che spediamo loro qualcosa di affidabile e collaudato per funzionare.

Sebbene al cliente non importi di DevOps (nella maggior parte dei casi), è comunque utile per noi. Con DevOps, siamo in grado di inviare rapidamente nuove build, in modo che i clienti possano vedere il feedback in pochi minuti e non ore, e siamo anche in grado di rilevare eventuali errori / bug con i nostri test tramite Jenkins / Travis.

Per garantire che le nostre strategie di implementazione siano le stesse in tutti i progetti, ci concentriamo sulla containerizzazione delle nostre applicazioni. Utilizzando Docker, siamo in grado di distribuire facilmente l'applicazione ai nostri clienti.

Il costo risparmiato da DevOps è difficile da determinare. Abbiamo costi aggiuntivi sotto forma di software che scegliamo di utilizzare per la pipeline (Travis, Jenkins, Puppet, che cosa hai), ma risparmiamo anche tempo e denaro correggendo bug / fornendo rapidamente feedback ai clienti. Il nostro rapido tempo di risposta rende felici i nostri clienti, a loro volta, mantenendo felici i nostri portafogli.

Ho lavorato per aziende che producono software come prodotti termoretraibili, come installazioni completamente installate e supportate e come codice incorporato nei dispositivi. In tutte queste aziende, DevOps fornisce un supporto essenziale per lo sviluppo:

• Build di software automatizzati e riproducibili, con configurazioni note e controllate di compilatori, librerie e altri strumenti di build.
• Test di sistema automatizzati e ripetibili per test di regressione e per nuovi test di funzionalità.
• Altre azioni automatizzate e regolari (ad esempio schermate di esempio di aggiornamento continuamente disponibili in tutte le lingue supportate, per i traduttori da verificare e per gli autori tecnici da incorporare nei manuali dell'utente).

In tutti i casi, queste sono cose che i singoli sviluppatori potrebbero fare come una tantum, ma che non sarebbero un buon uso del tempo degli sviluppatori, né avrebbero la stessa sicurezza del controllo di configurazione che hanno le build automatizzate.

Le attività di sviluppo e implementazione di software in precedenza non richiedevano una profonda integrazione tra i reparti. Ma per oggi è necessario cooperare strettamente con tutti i dipartimenti (sviluppo, operazioni IT, controllo qualità, ecc.).

Per gli sviluppatori, il cambiamento è ciò per cui vengono pagati. Le aziende hanno sempre bisogno di cambiamenti per adattarsi al mondo moderno. Questa comprensione spinge gli sviluppatori a produrre il massimo numero possibile di modifiche. I professionisti IT hanno una comprensione diversa, in cui il cambiamento è dannoso. Ognuno di loro pensa che funzioni correttamente, a vantaggio del business. Anzi, se li consideriamo separatamente, hanno entrambi ragione.

Tutti i dipendenti devono capire che fanno parte di un singolo processo. DevOps coltiva il pensiero, il che rende possibile rendersi conto che le decisioni e le azioni personali di tutti dovrebbero essere dirette verso la realizzazione di un unico obiettivo. E il successo dovrebbe essere misurato rispetto all'intero ciclo di sviluppo-consegna e non dal successo dei singoli ruoli. Come risultato della stretta collaborazione tra sviluppatori e specialisti della manutenzione, viene formata una nuova generazione di ingegneri, che prendono i migliori risultati di entrambe le discipline e li combinano a beneficio dell'utente. Ciò si manifesta nella comparsa di team interfunzionali con esperienza nello sviluppo, gestione della configurazione, gestione del database, test e gestione dell'infrastruttura.

Quindi la metodologia è utile non solo in SaaS.

Affatto. Mentre ci sono già ottimi esempi su questo thread, mi piacerebbe condividere un mio aneddoto. Nel 2001 ho ereditato un progetto software con una versione che prevedeva la creazione di un CD. La documentazione per il processo di rilascio includeva 40 (!) Passaggi documentati da un ingegnere precedente, che includeva alcune ridicole istruzioni scritte a mano come "apri questo file di configurazione e cambia il nome del file .jar alla riga 41 per includere il numero di versione di la nuova versione ".

Abbiamo automatizzato in modo aggressivo ogni fase di quel processo di costruzione, sostituendo istruzioni scritte a mano come quelle con cose come 'patch' con script bash. Abbiamo anche dovuto aprire i biglietti con il nostro fornitore di strumenti di installazione di terze parti per rendere comprensibili i file dei progetti.

Una volta automatizzato tale processo, abbiamo acquistato un "CD Jukebox". Ogni notte dopo il superamento dei test, la macchina di creazione creava automaticamente un nuovo CD di installazione. I nostri tester potrebbero venire la mattina dopo, prendere un disco e assicurarsi che tutto fosse installabile.

Abbiamo certamente cicli di feedback più stretti quando possiamo distribuire software come servizio, ma si applicano tutti i principi fondamentali di automazione, feedback, tempo di ciclo, piccole versioni, ecc.