Come si applica DevOps al software pacchettizzato?

3

Sto cercando di saperne di più sulla tendenza DevOps e su cosa sia effettivamente DevOps e su come potrebbe applicarsi alla mia situazione (recentemente alimentata dai risultati del sondaggio Stack Overflow che iniziano menzionando DevOps). Tutte le mie ricerche fino ad ora indicano cose come DevOps, gli sviluppatori si assumono la responsabilità per l'implementazione e la automatizzano.

Credo di comprendere i principi e i loro benefici in scenari in cui il software è un servizio in esecuzione (come un sistema informativo o un sito Web) gestito dalla società che lo sviluppa. Tuttavia, nessuna delle descrizioni che ho letto finora (su Wikipedia o sui principali hit di Google) menziona DevOps limitato a situazioni come questa, quindi presumo che sia applicabile universalmente.

Non riesco a capire come i principi si applicherebbero in una situazione in cui un team / azienda sviluppa software desktop offline che viene acquistato, scaricato e installato dai suoi clienti. L'unico coinvolgimento della società in via di sviluppo è quello di ospitare i pacchetti di installazione sul proprio sito Web.

In questo caso, la parte "deployment & operations" di DevOps dovrebbe essere limitata a confezionare l'installer e copiarlo nell'area download, o c'è qualcosa che mi manca?

Nessuno degli articoli su DevOps che ho letto finora ha toccato questo modello di sviluppo del software. È qualcosa in cui è applicabile il principio DevOps e, in caso affermativo, come?

    
posta Angew 13.03.2018 - 16:28
fonte

2 risposte

6

Iniziamo separando alcuni termini:

DevOps

Un movimento per portare insieme lo sviluppo e le operazioni per aiutare ad abbattere le barriere tra i dipartimenti e condividere competenze e conoscenze. Strettamente collegati sono:

Consegna continua

La consegna continua di valore. Questo è spesso gestito come parte di qualcosa come un framework di scrum per aggiungere costantemente valore di business nel prodotto piuttosto che creare enormi rilasci monolitici. In termini più semplici, si tratta di approcci come "Sviluppa in Master" e Integrazione continua.

Distribuzione continua

La Distribuzione continua è il prossimo passaggio logico da Continuous Delivery. Se il codice viene creato automaticamente, distribuito per testare gli ambienti, E automaticamente testato tramite test automatici, perché non può essere continuamente integrato in un ambiente live per ottenere un feedback REALE dagli utenti e utilizzare questa conoscenza più rapidamente?

Quindi DevOps si limita a confezionare l'installer e copiarlo nell'area download?

Uno degli obiettivi principali di questi principi è cercare di ridurre al minimo il tempo di ciclo tra la scrittura del codice e il codice che viene eseguito dai clienti. Ci sono molte ragioni per cui questo è buono, tra cui:

  • Distribuzione più rapida delle correzioni
  • Feedback più rapido sulla qualità delle versioni
  • Variazioni incrementali più piccole (e forse anche più importanti meno dannose)

Se fossi in te, guarderei il tempo necessario per i vari passaggi coinvolti nella distribuzione ai tuoi clienti. Quanto tempo ci vuole per ottenere dalla tua casella Dev per costruire? Distribuire a Integrazione? Per distribuire al QA? Pubblicare nell'area download? O per inviare ai dispositivi di un cliente?

Ottieni valori numerici reali per questi, non indovinarli!

Suggerirei che il ritardo maggiore che dovrai affrontare è la quantità di tempo che impiega i clienti a scaricare e installare una nuova versione dopo averla distribuita nell'area di download. Questa sarà la più grande attesa che dovrai affrontare quando desideri che un cliente aggiorni ...

La conclusione logica?

TLDR

Suggerirei che il più grande miglioramento che è possibile apportare al processo di distribuzione sarebbe quello di automatizzarlo fornendo un meccanismo di aggiornamento automatico in modo che i clienti non debbano fare nulla per l'aggiornamento.

Tuttavia, lo sviluppo non riguarda il lavoro di supposizione! Scopri cosa rallenta questa pipeline e utilizza i dati REAL per trarre da te queste conclusioni!

    
risposta data 13.03.2018 - 17:44
fonte
2

Con il software installabile pacchettizzato la parte "Operazioni" di DevOps ha ancora due importanti lavori oltre la confezione delle versioni:

  1. Consegna degli aggiornamenti agli utenti
  2. Ottenere feedback utili sui problemi degli utenti

Per 1. al giorno d'oggi non ci sono scuse per il fatto che il tuo software non sia in grado di aggiornarsi automaticamente. Che richiede un'infrastruttura server per fornire quegli aggiornamenti.

Per 2. il tuo lavoro è ancora più complesso e complicato di quello con il software in esecuzione su server che controlli, ma hai anche un enorme potenziale di miglioramento rispetto a come le cose andavano prima. Invece di mettere l'intero fardello per utili segnalazioni di bug sugli utenti finali (il che significa che non ne riceverai praticamente nessuna), puoi integrare una funzionalità di segnalazione dei bug nel software che ti invierà qualsiasi informazione di contesto utile che potresti avere (anche se questo può ottenere molto difficile per quanto riguarda la legislazione sulla privacy!).

    
risposta data 13.03.2018 - 18:18
fonte

Leggi altre domande sui tag