Immagine:
Ciao a tutti! Siamo ingegneri dell'automazione dell'azienda e supportiamo lo sviluppo dei prodotti dell'azienda: supportiamo l'intera pipeline di assemblaggio dal commit di una riga di codice da parte degli sviluppatori fino alla pubblicazione dei prodotti finiti e delle licenze sui server di aggiornamento. Informalmente siamo chiamati ingegneri DevOps. In questo articolo vogliamo parlare delle fasi tecnologiche del processo di produzione del software, come le vediamo e come le classifichiamo.
Dal materiale imparerai la complessità del coordinamento dello sviluppo multiprodotto, cos'è una mappa tecnologica e come aiuta a semplificare e replicare le soluzioni, quali sono le fasi e i passaggi principali del processo di sviluppo, come sono le aree di responsabilità tra DevOps e i team della nostra azienda.
A proposito di caos e DevOps
In breve, il concetto di DevOps comprende strumenti e servizi di sviluppo, nonché metodologie e best practice per il loro utilizzo. Identifichiamo il globale scopo dall’implementazione delle idee DevOps nella nostra azienda: si tratta di una riduzione consistente dei costi di produzione e manutenzione dei prodotti in termini quantitativi (ore uomo o ore macchina, CPU, RAM, Disco, ecc.). Il modo più semplice e ovvio per ridurre il costo complessivo dello sviluppo a livello dell'intera azienda è riducendo al minimo il costo dell'esecuzione delle tipiche attività seriali in tutte le fasi della produzione. Ma quali sono queste fasi, come separarle dal processo generale, in quali passaggi consistono?
Quando un'azienda sviluppa un prodotto, tutto è più o meno chiaro: di solito esiste una tabella di marcia generale e uno schema di sviluppo. Ma cosa fare quando la linea di prodotti si espande e ci sono più prodotti? A prima vista, hanno processi e catene di montaggio simili e inizia il gioco di “trovare X differenze” nei log e negli script. Cosa succede se ci sono già più di 5 progetti in sviluppo attivo ed è necessario il supporto per diverse versioni sviluppate nel corso di diversi anni? Vogliamo riutilizzare quante più soluzioni possibili nelle pipeline di prodotti o siamo pronti a spendere soldi per uno sviluppo unico per ciascuna?
Come trovare un equilibrio tra unicità e soluzioni seriali?
Queste domande hanno cominciato a porsi davanti a noi sempre più spesso a partire dal 2015. Il numero dei prodotti è cresciuto e abbiamo cercato di espandere al minimo il nostro reparto di automazione (DevOps), che supportava le catene di montaggio di questi prodotti. Allo stesso tempo, volevo replicare quante più soluzioni possibili tra i prodotti. Dopotutto, perché fare la stessa cosa in dieci prodotti in modi diversi?
Direttore dello sviluppo: "Ragazzi, possiamo in qualche modo valutare cosa fa DevOps per i prodotti?"
Noi: “Non lo sappiamo, non ci siamo posti questa domanda, ma quali indicatori dovrebbero essere calcolati?”
Direttore dello sviluppo: "Chi lo sa! Pensare…"
Come in quel famoso film: "Sono in un albergo! .." - "Uh... puoi indicarmi la strada?" Riflettendoci siamo giunti alla conclusione che occorre prima decidere sullo stato finale dei prodotti; questo è diventato il nostro primo obiettivo.
Quindi, come è possibile analizzare una dozzina di prodotti con team abbastanza grandi da 10 a 200 persone e determinare parametri misurabili durante la replica delle soluzioni?
1:0 a favore del Caos, ovvero DevOps sulle scapole
Abbiamo iniziato tentando di applicare i diagrammi IDEF0 e vari diagrammi dei processi aziendali della serie BPwin. La confusione è iniziata dopo il quinto quadrato della fase successiva del progetto successivo, e questi quadrati per ogni progetto possono essere disegnati nella coda di un lungo pitone sotto più di 50 passi. Mi sentivo triste e volevo ululare alla luna: in generale non si adattava.
Compiti tipici della produzione
Modellare i processi produttivi è un lavoro molto complesso e minuzioso: è necessario raccogliere, elaborare e analizzare moltissimi dati provenienti da vari reparti e catene produttive. Puoi leggere di più a riguardo nell’articolo “'.
Quando abbiamo iniziato a modellare il nostro processo produttivo, avevamo un obiettivo specifico: trasmettere a tutti i dipendenti coinvolti nello sviluppo dei prodotti della nostra azienda e ai project manager:
- come i prodotti e i loro componenti, a partire dal commit di una riga di codice, arrivano al cliente sotto forma di installatori e aggiornamenti,
- quali risorse sono fornite per ciascuna fase di produzione dei prodotti,
- quali servizi sono coinvolti in ciascuna fase,
- come sono delimitate le aree di responsabilità per ciascuna fase,
- quali contratti esistono all'ingresso e all'uscita di ciascuna fase.
Cliccando sull'immagine la si aprirà a grandezza naturale.
Il nostro lavoro in azienda è suddiviso in diverse aree funzionali. Il dipartimento delle infrastrutture è impegnato nell'ottimizzazione del funzionamento di tutte le risorse hardware del dipartimento, nonché nell'automazione della distribuzione delle macchine virtuali e dell'ambiente su di esse. La direzione di monitoraggio garantisce il controllo sull'esecuzione dei servizi 24 ore su 7, XNUMX giorni su XNUMX; Forniamo anche il monitoraggio come servizio per gli sviluppatori. La direzione del flusso di lavoro fornisce ai team strumenti per gestire i processi di sviluppo e test, analizzare lo stato del codice e ottenere analisi sui progetti. Infine, la direzione webdev garantisce la pubblicazione delle versioni sui server di aggiornamento GUS e FLUS, nonché la licenza dei prodotti utilizzando il servizio LicenseLab. Per supportare la pipeline di produzione, impostiamo e manteniamo molti servizi di supporto diversi per gli sviluppatori (puoi ascoltare le storie su alcuni di essi nei vecchi incontri: и). Sviluppiamo anche strumenti di automazione interna, tra cui .
Negli ultimi cinque anni, il nostro lavoro ha accumulato molte operazioni dello stesso tipo e di routine, e i nostri sviluppatori di altri dipartimenti provengono principalmente dai cosiddetti compiti tipici, la cui soluzione è completamente o parzialmente automatizzata, non crea difficoltà agli esecutori e non richiede notevoli quantità di lavoro. Insieme alle aree principali, abbiamo analizzato tali compiti e siamo stati in grado di identificare le singole categorie di lavoro, o fasi di produzione, le fasi sono divise in passaggi indivisibili e più fasi si sommano catena del processo produttivo.
L'esempio più semplice di catena tecnologica sono le fasi di assemblaggio, implementazione e test di ciascuno dei nostri prodotti all'interno dell'azienda. A sua volta, ad esempio, la fase di compilazione consiste in molti passaggi standard separati: download di sorgenti da GitLab, preparazione di dipendenze e librerie di terze parti, test unitari e analisi statica del codice, esecuzione di uno script di compilazione su GitLab CI, pubblicazione di artefatti in un repository su Artifactory e generazione di note di rilascio tramite il nostro strumento interno ChangelogBuilder.
Puoi leggere le tipiche attività DevOps negli altri nostri articoli su Habré: ""E"'.
Si formano numerose catene produttive tipiche processo di fabbricazione. L'approccio standard per descrivere i processi consiste nell'utilizzare modelli funzionali IDEF0.
Un esempio di modellazione di un processo di CI di produzione
Abbiamo dedicato particolare attenzione allo sviluppo di progetti standard per un sistema di integrazione continua. Ciò ha permesso di realizzare l'unificazione dei progetti, evidenziando il cosiddetto schema di build di rilascio con promozioni.
Ecco come funziona. Tutti i progetti sembrano tipici: includono la configurazione di assembly che vanno al repository di snapshot su Artifactory, dopo di che vengono distribuiti e testati su banchi di prova, quindi promossi al repository di rilascio. Il servizio Artifactory è un unico punto per la distribuzione di tutti gli artefatti di build tra team e altri servizi.
Se semplifichiamo e generalizziamo notevolmente il nostro schema di rilascio, includerà i seguenti passaggi:
- assemblaggio di prodotti multipiattaforma,
- impiego sui banchi prova,
- lancio di test funzionali e di altro tipo,
- promozione di assembly testati per rilasciare repository su Artifactory,
- pubblicazione delle build di rilascio sui server di aggiornamento,
- consegna di assiemi e aggiornamenti alla produzione,
- avviare l'installazione e l'aggiornamento del prodotto.
Consideriamo, a titolo di esempio, il modello tecnologico di questo tipico schema di rilascio (di seguito denominato semplicemente Modello) sotto forma di modello funzionale IDEF0. Riflette le fasi principali del nostro processo di CI. I modelli IDEF0 utilizzano il cosiddetto Notazione ICOM (Input-Control-Output-Mechanism) per descrivere quali risorse vengono utilizzate in ogni fase, in base a quali regole e requisiti viene eseguito il lavoro, qual è l'output e quali meccanismi, servizi o persone implementano una particolare fase.
Cliccando sull'immagine la si aprirà a grandezza naturale.
Di norma, nei modelli funzionali è più semplice scomporre e dettagliare la descrizione dei processi. Ma man mano che il numero degli elementi cresce, diventa sempre più difficile capirne qualcosa. Ma nello sviluppo reale ci sono anche fasi ausiliarie: monitoraggio, certificazione del prodotto, automazione dei processi lavorativi e altre. È proprio a causa del problema del ridimensionamento che abbiamo abbandonato questa descrizione.
Nascita della speranza
In un libro ci siamo imbattuti in vecchie mappe sovietiche che descrivevano i processi tecnologici (che, tra l'altro, sono ancora utilizzati oggi in molte imprese e università statali). Aspetta, aspetta, abbiamo anche un processo tecnologico!.. Ci sono fasi, risultati, metriche, requisiti, indicatori, ecc. ecc.... Perché non provare ad applicare mappe tecnologiche ai nostri trasportatori di prodotti? C'era una sensazione: “Ecco! Abbiamo trovato il filo giusto, è ora di dargli una bella tirata!”
In una semplice tabella, abbiamo deciso di registrare i prodotti per colonne e le fasi tecnologiche e le fasi del trasportatore dei prodotti per righe. Le fasi sono qualcosa di grande, come la fase di assemblaggio di un prodotto. E i passaggi sono qualcosa di più piccolo e più dettagliato, ad esempio il passaggio di download del codice sorgente sul server di compilazione o il passaggio di compilazione del codice.
Alle intersezioni di righe e colonne della mappa, inseriamo gli stati per una fase e un prodotto specifici. Molti stati sono stati definiti per gli status:
- Nessuna informazione - o poco pratico. È necessario analizzare la domanda per una fase del prodotto. O l'analisi è già stata effettuata, ma la fase attualmente non è necessaria o non è economicamente giustificata.
- Rinviato - o non rilevante al momento. È necessaria una fase di preparazione, ma quest'anno non ci sono forze per l'attuazione.
- In programma. La fase è prevista per l'implementazione quest'anno.
- Implementato. La fase in cantiere è implementata nel volume richiesto.
La compilazione della tabella è iniziata progetto per progetto. Per prima cosa abbiamo classificato le fasi e i passaggi di un progetto e ne abbiamo registrato lo stato. Quindi hanno preso il progetto successivo, ne hanno registrato gli stati e hanno aggiunto fasi e passaggi che mancavano nei progetti precedenti. Di conseguenza, abbiamo ricevuto le fasi e i passaggi dell'intera pipeline di produzione e i loro stati in un progetto specifico. Il risultato è qualcosa di simile a una matrice di competenze per un trasportatore di alimenti. Abbiamo chiamato tale matrice mappa tecnologica.
Con l'aiuto della mappa tecnologica, coordiniamo metrologicamente in modo ragionevole con i team i piani di lavoro per l'anno e gli obiettivi che vogliamo raggiungere insieme: quali fasi aggiungiamo al progetto quest'anno e quali lasciamo per dopo. Inoltre, nel corso del lavoro, potremmo avere miglioramenti nelle fasi che abbiamo completato per un solo prodotto. Quindi espandiamo la nostra mappa e introduciamo questo miglioramento come una fase o un nuovo passaggio, quindi analizziamo ciascun prodotto e scopriamo la fattibilità di replicare il miglioramento.
Potrebbero obiettarci: “Tutto questo, ovviamente, è positivo, solo che col tempo il numero di passaggi e fasi diventerà proibitivo. Come essere?
Abbiamo introdotto descrizioni standard e abbastanza complete dei requisiti per ogni fase e passaggio in modo che all'interno dell'azienda fossero compresi da tutti allo stesso modo. Nel corso del tempo, man mano che vengono implementati i miglioramenti, un passaggio può essere assorbito in un altro stadio o passaggio, quindi crollerà. Allo stesso tempo, tutti i requisiti e le sfumature tecnologiche rientrano nei requisiti della fase o fase di generalizzazione.
Come valutare l'effetto della replicazione delle soluzioni? Utilizziamo un approccio estremamente semplice: attribuiamo i costi di capitale iniziali per l'implementazione di una nuova fase ai costi generali annuali del prodotto, quindi li dividiamo tra tutti durante la replica.
Parti dello sviluppo sono già mostrate come pietre miliari e passaggi sulla mappa. Possiamo influenzare la riduzione del costo del prodotto attraverso l'introduzione dell'automazione per le fasi tipiche. Successivamente, consideriamo i cambiamenti nelle caratteristiche qualitative, nei parametri quantitativi e nel profitto ricevuto dai team (in ore uomo o ore macchina risparmiate).
Mappa tecnologica del processo produttivo
Se prendiamo tutte le nostre fasi e passaggi, li codifichiamo con tag e li espandiamo in un'unica catena, risulterà molto lungo e incomprensibile (esattamente la stessa "coda di pitone" di cui abbiamo parlato all'inizio dell'articolo) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Queste sono le fasi di assemblaggio di prodotti [Build], distribuzione su server di test [Deploy], test [Test], promozione di assembly per rilasciare repository in base ai risultati dei test [Promote], generazione e pubblicazione di licenze [License], pubblicazione [Publish] sul server di aggiornamento GUS e fornitura di aggiornamenti FLUS ai server, installazione e aggiornamento dei componenti del prodotto sull'infrastruttura del cliente utilizzando Gestione della configurazione del prodotto [Installa], nonché raccolta di telemetria [Telemetria] dai prodotti installati.
Oltre a questi, possiamo distinguere fasi separate: monitoraggio dello stato dell'infrastruttura [InfMonitoring], gestione delle versioni del codice sorgente [SourceCodeControl], preparazione dell'ambiente di assemblaggio [Prepare], gestione del progetto [Workflow], fornitura ai team di strumenti di comunicazione [ Comunicazione], la certificazione del prodotto [Certificazione] e la garanzia dell'autosufficienza dei processi CI [CISelfSufficiency] (ad esempio, l'indipendenza degli assemblaggi da Internet). Non prenderemo nemmeno in considerazione decine di passaggi nei nostri processi, perché sono molto specifici.
Sarà molto più facile comprendere e osservare l'intero processo produttivo se lo immagini nella forma mappa tecnologica; Si tratta di una tabella in cui sono registrate in righe le singole fasi produttive e i passaggi scomposti del Modello, e in colonne la descrizione di ciò che viene fatto in ciascuna fase o passaggio. L'enfasi principale è sulle risorse che forniscono ciascuna fase e sulla delimitazione delle aree di responsabilità.
La mappa per noi è una sorta di classificatore. Riflette le grandi parti tecnologiche della produzione dei prodotti. Grazie ad esso, è diventato più semplice per il nostro team di automazione interagire con gli sviluppatori e pianificare congiuntamente l'implementazione delle fasi di automazione, oltre a comprendere quali costi di manodopera e risorse (umane e hardware) saranno necessari per questo.
All'interno della nostra azienda, la mappa viene generata automaticamente da un modello jinja come un normale file HTML e quindi caricata sul server GitLab Pages. È possibile visualizzare uno screenshot con un esempio di una mappa completamente generata .
Cliccando sull'immagine la si aprirà a grandezza naturale.
In breve, la mappa tecnologica è un quadro generalizzato del processo produttivo, che riflette blocchi chiaramente classificati con funzionalità tipiche.
Struttura della nostra road map
La mappa è composta da diverse parti:
- Area intestazione - qui viene fornita una descrizione generale della mappa, vengono introdotti i concetti di base e vengono definite le principali risorse e risultati del processo produttivo.
- Pannello informativo: qui è possibile controllare la visualizzazione dei dati per i singoli prodotti; viene fornito un riepilogo delle fasi e dei passaggi implementati in generale per tutti i prodotti.
- Mappa tecnologica: una descrizione tabellare del processo tecnologico. Sulla mappa:
- vengono fornite tutte le fasi, i passaggi e i relativi codici;
- vengono fornite descrizioni brevi e complete delle tappe;
- sono indicate le risorse ed i servizi in input utilizzati in ciascuna fase;
- sono indicati i risultati di ogni fase e singolo passaggio;
- è indicata l'area di responsabilità per ogni fase e passaggio;
- sono state determinate le risorse tecniche, ad esempio HDD (SSD), RAM, vCPU e le ore di lavoro necessarie per supportare il lavoro in questa fase, sia attualmente che in futuro;
- per ciascun prodotto è indicato quali fasi o passaggi tecnologici per lo stesso sono stati implementati, pianificati per l'implementazione, irrilevanti o non implementati.
Processo decisionale basato sulla mappa tecnologica
Dopo aver studiato la mappa, puoi intraprendere alcune azioni, a seconda del ruolo del dipendente in azienda (responsabile sviluppo, product manager, sviluppatore o tester):
- capire quali fasi mancano in un prodotto o progetto reale e valutare la necessità della loro implementazione;
- delimitare le aree di responsabilità tra più dipartimenti se lavorano su fasi diverse;
- negoziare i contratti per gli input e gli output delle fasi;
- integrare la fase di lavoro nel processo di sviluppo complessivo;
- valutare in modo più accurato la necessità di risorse per supportare ciascuna fase.
Riassumendo tutto quanto sopra
Il routing è versatile, estensibile e di facile manutenzione. È molto più semplice sviluppare e mantenere una descrizione dei processi in questa forma che in un rigoroso modello accademico IDEF0. Inoltre, una descrizione tabellare è più semplice, più familiare e meglio strutturata di un modello funzionale.
Uno speciale strumento interno, CrossBuilder, è responsabile dell'implementazione tecnica dei passaggi: uno strumento di stratificazione tra sistemi CI, servizi e infrastruttura. Lo sviluppatore non ha bisogno di tagliarsi la bici: nel nostro sistema CI è sufficiente eseguire uno degli script (il cosiddetto task) dello strumento CrossBuilder, che lo eseguirà correttamente, tenendo conto delle caratteristiche della nostra infrastruttura.
Risultati di
L'articolo si è rivelato piuttosto lungo, ma ciò è inevitabile quando si descrive la modellizzazione di processi complessi. Per concludere vorrei esporre brevemente le nostre idee principali:
- L’obiettivo dell’introduzione delle idee DevOps nella nostra azienda è ridurre costantemente i costi di produzione e manutenzione dei prodotti aziendali in termini quantitativi (ore uomo o ore macchina, vCPU, RAM, disco).
- Un modo per ridurre il costo complessivo dello sviluppo è ridurre al minimo il costo dell'esecuzione di attività seriali standard: fasi e passaggi del processo tecnologico.
- Un compito tipico è un compito la cui soluzione è completamente o parzialmente automatizzata, non causa difficoltà agli esecutori e non richiede costi di manodopera significativi.
- Il processo produttivo è costituito da fasi, le fasi sono suddivise in fasi indivisibili, che rappresentano compiti tipici di diverse scale e volumi.
- Da compiti tipici disparati siamo arrivati a catene tecnologiche complesse e modelli multi-livello del processo produttivo, che possono essere descritti da un modello funzionale IDEF0 o da una mappa tecnologica più semplice.
- Un diagramma di flusso è una rappresentazione tabellare delle fasi e dei passaggi di un processo produttivo. La cosa più importante: la mappa permette di vedere l'intero processo nella sua interezza, a grandi pezzi con la possibilità di dettagliarli.
- Sulla base della mappa tecnologica, è possibile valutare la necessità di introdurre fasi in un particolare prodotto, delineare aree di responsabilità, concordare contratti agli input e all'output delle fasi e valutare più accuratamente la necessità di risorse.
Nei seguenti articoli descriveremo più in dettaglio quali strumenti tecnici vengono utilizzati per implementare determinate fasi tecnologiche sulla nostra mappa.
Autori dell'articolo:
- — Responsabile del dipartimento di automazione (DevOps) presso Positive Technologies
- - vice Responsabile del dipartimento di automazione (DevOps) presso Positive Technologies
Fonte: habr.com