Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Organizzazione e modalità di lavoro
Come tutte le strategie architettoniche, i microfrontend hanno implicazioni che vanno ben oltre la tecnologia che un'organizzazione sceglie di implementare. La decisione di creare applicazioni micro-frontend deve essere in linea con il business, il prodotto, l'organizzazione, le operazioni e persino la cultura (ad esempio, potenziare i team e decentralizzare il processo decisionale). In cambio, questo tipo di architettura micro-frontend supporta uno sviluppo veramente agile e basato sul prodotto, perché riduce significativamente il sovraccarico di comunicazione tra team altrimenti indipendenti.
Sviluppo agile
L'idea dello sviluppo agile del software è diventata così universale negli ultimi anni che praticamente tutte le organizzazioni affermano di lavorare in modo agile. Sebbene una definizione definitiva di agile non rientri nell'ambito di questa strategia, vale la pena esaminare gli elementi chiave rilevanti per lo sviluppo di microfrontend.
Il fondamento del paradigma agile è l'Agile Manifesto
Nel contesto dell'architettura micro-frontend, è importante adottare i seguenti principi agili:
-
«Fornite software funzionante frequentemente, da un paio di settimane a un paio di mesi, preferendo tempi più brevi».
Questo principio sottolinea quanto sia importante lavorare in modo incrementale e fornire software alla produzione il più regolarmente e il più spesso possibile. Da un punto di vista tecnologico, ciò si riferisce all'integrazione continua e alla consegna continua (CI/CD). In CI/CD, gli strumenti e i processi per la creazione, il test e l'implementazione sono parti integranti di ogni progetto software. Il principio implica anche che l'infrastruttura di runtime e le responsabilità operative devono essere di proprietà del team. Tale proprietà è particolarmente importante nei sistemi distribuiti in cui sottosistemi indipendenti potrebbero avere requisiti significativamente diversi per l'infrastruttura e le operazioni.
-
«Costruisci progetti attorno a persone motivate. Offri loro l'ambiente e il supporto di cui hanno bisogno e affidati a loro per portare a termine il lavoro».
«Le architetture, i requisiti e i progetti migliori emergono dai team che si organizzano autonomamente».
Entrambi questi principi enfatizzano i vantaggi della proprietà, dell'indipendenza e della responsabilità. end-to-end Un'architettura di micro-frontend avrà successo quando (e solo quando) i team possiedono veramente i propri microfrontend. La nd-to-end responsabilità, dall'ideazione alla progettazione e implementazione, fino alla consegna e al funzionamento, garantisce che il team possa effettivamente esercitarne la proprietà. Questa indipendenza è necessaria, sia dal punto di vista tecnico che organizzativo, affinché il team abbia autonomia sulla direzione strategica. Non è consigliabile utilizzare una piattaforma di micro-frontend in un'organizzazione centralizzata che utilizza un modello di sviluppo a cascata.
Composizione e dimensioni del team
Affinché un team addetto al software possa esercitare la propria responsabilità, deve autogovernarsi, comprese le modalità e i risultati del team, entro i limiti imposti dall'organizzazione.
Per essere efficaci, i team devono essere in grado di fornire software in modo indipendente e avere l'autorità di decidere il modo migliore per distribuirlo. Un team che riceve requisiti di funzionalità da un product manager esterno o progetti di interfaccia utente da un designer esterno, senza essere coinvolto nella pianificazione di questi elementi, non può essere considerato autonomo. Le funzionalità potrebbero violare i contratti o le funzionalità esistenti. Tali violazioni richiederanno ulteriori discussioni e trattative, con il rischio di ritardare la consegna e introdurre conflitti inutili tra i team.
Allo stesso tempo, i team non dovrebbero diventare troppo grandi. Mentre un team più numeroso dispone di più risorse e può far fronte alle assenze individuali, la complessità della comunicazione cresce esponenzialmente con ogni nuovo membro. Non è possibile stabilire una dimensione massima del team universalmente valida. Il numero di persone necessarie per un progetto dipende da fattori quali la maturità del team, la complessità tecnica, il ritmo dell'innovazione e l'infrastruttura. Ad esempio, Amazon segue la regola delle due pizze: una squadra troppo numerosa per essere nutrita con due pizze dovrebbe essere divisa in squadre più piccole. Questa può essere una sfida. La divisione dovrebbe avvenire lungo i confini naturali e dovrebbe dare a ciascun team autonomia e proprietà sul proprio lavoro.
DevOps cultura
DevOps si riferisce a una pratica di ingegneria del software in cui le fasi del ciclo di vita dello sviluppo sono strettamente integrate dal punto di vista organizzativo e tecnico. Contrariamente alla credenza popolare, DevOps riguarda molto la cultura e la mentalità e molto poco i ruoli e gli strumenti.
Tradizionalmente, un'organizzazione software avrebbe a disposizione team di specialisti, ad esempio per la progettazione, l'implementazione, il collaudo, l'implementazione e le operazioni. Ogni volta che un team completava il proprio lavoro, affidava il progetto al team successivo. Tuttavia, la fornitura del software attraverso silos di team specializzati causa attriti durante i passaggi di consegne. Allo stesso tempo, quando gli specialisti sono costretti a lavorare con un focus ristretto, non hanno conoscenze nei settori limitrofi e non hanno una visione sistemica del prodotto. Questi deficit possono portare a una scarsa coerenza del prodotto software.
Ad esempio, quando un architetto del software progetta una soluzione che deve essere implementata da qualcuno che fa parte di un team diverso, potrebbe trascurare aspetti intrinseci dell'implementazione (come una mancata corrispondenza delle dipendenze). Gli sviluppatori adottano quindi delle scorciatoie (come una monkey patch) oppure ne back-and-forth viene avviata una formalizzata tra l'architetto e il team di sviluppo. A causa del sovraccarico di gestione di questi processi, lo sviluppo non è più agile (nel senso di flessibile, adattivo, incrementale e informale).
Sebbene il termine DevOps si riferisca principalmente alla cultura, implica le tecnologie e i processi che lo rendono possibile nella pratica. DevOps DevOps è strettamente correlato alla CI/CD. Quando uno sviluppatore ha finito di implementare un incremento di software, lo invia a un sistema di controllo delle versioni come Git. Tradizionalmente, un sistema di compilazione creava e integrava il software, lo testava e lo rilasciava in un processo più o meno unificato e centralizzato. Con CI/CD, la creazione, l'integrazione, il test e il rilascio del software sono intrinseci e automatizzati. Idealmente, il processo fa parte del progetto software stesso attraverso file di configurazione adattati specificamente al progetto specifico.
Il maggior numero possibile di passaggi viene automatizzato. Ad esempio, le pratiche di test manuali dovrebbero essere ridotte, poiché quasi tutti i tipi di test possono essere automatizzati. Quando il progetto è configurato in questo modo, gli aggiornamenti di un prodotto software possono essere forniti più volte al giorno con la massima sicurezza. Un'altra tecnologia supportata DevOps è l'infrastruttura come codice (IaC).
Tradizionalmente, la configurazione e la manutenzione dell'infrastruttura IT richiedevano il lavoro manuale di installazione e manutenzione dell'hardware (installazione di cavi e server in un data center) e del software operativo. Ciò era necessario, ma presentava numerosi inconvenienti. L'installazione richiedeva molto tempo ed era soggetta a errori. L'hardware era spesso sovradimensionato o insufficiente, con conseguenti spese eccessive o un peggioramento delle prestazioni. Utilizzando IaC, è possibile descrivere i requisiti di infrastruttura per un sistema IT tramite un file di configurazione da cui è possibile distribuire e aggiornare automaticamente i servizi cloud.
Cosa c'entra tutto questo con i micro-frontend? DevOps, CI/CD e IaC sono i complementi ideali di un'architettura di micro-frontend. I vantaggi dei microfrontend si basano su processi di distribuzione rapidi e senza attriti. Una DevOps cultura può prosperare solo in ambienti in cui i team gestiscono progetti software con responsabilità. end-to-end
Orchestrazione dello sviluppo di microfrontend tra più team
Quando si ridimensiona lo sviluppo di microfrontend tra più team interfunzionali, emergono due problemi: in primo luogo, i team iniziano a sviluppare la propria interpretazione del paradigma, a fare scelte di framework e librerie e a creare le proprie librerie di strumenti e di supporto. In secondo luogo, i team completamente autonomi devono assumersi la responsabilità di funzionalità generiche come la gestione dell'infrastruttura a basso livello. Pertanto, è opportuno introdurre due team aggiuntivi in un'organizzazione di micro-frontend con più team: un team di abilitazione e un team di piattaforma. Questi concetti sono ampiamente adottati nelle moderne organizzazioni IT con sistemi distribuiti e sono ben documentati in Team Topologies.
Il diagramma seguente mostra il team di abilitazione che fornisce strumenti, librerie, standard e test a tre team di microfrontend. Il team della piattaforma fornisce infrastruttura, funzionalità di runtime condivise e servizi di dominio agli stessi tre team di microfrontend.
Il team della piattaforma supporta i team di microfrontend liberandoli dal sollevamento indifferenziato di carichi pesanti. Questo supporto può includere servizi di infrastruttura come runtime dei container, pipeline CI/CD, strumenti di collaborazione e monitoraggio. Tuttavia, la creazione di un team di piattaforma non dovrebbe portare a un'organizzazione in cui lo sviluppo è separato dalle operazioni. È vero il contrario: il team della piattaforma offre un prodotto ingegneristico e i team di microfrontend hanno la proprietà e la responsabilità di esecuzione dei propri servizi sulla piattaforma.
Il team di abilitazione fornisce supporto concentrandosi sulla governance e garantendo la coerenza tra i team di microfrontend. (Il team della piattaforma non dovrebbe essere coinvolto in questo.) Il team di abilitazione gestisce risorse condivise, come una libreria di interfaccia utente, e crea standard come la scelta del framework, i budget prestazionali e le convenzioni di interoperabilità. Allo stesso tempo, fornisce ai nuovi team o membri del team una formazione sull'applicazione degli standard e degli strumenti definiti dalla governance.
Implementazione
La stella polare dell'autonomia nei team di microfrontend è disporre di una pipeline automatizzata con un percorso di produzione indipendente dagli altri team di microfrontend. I team che seguono il principio «share-nothing» possono implementare pipeline indipendenti. I team che condividono librerie o dipendono da una piattaforma devono decidere come gestire le dipendenze nelle pipeline di distribuzione.
In genere, ogni pipeline esegue le seguenti operazioni:
-
Crea risorse frontend
-
Implementa le risorse nell'hosting per il consumo
-
Assicura che i registri e le cache vengano aggiornati in modo che le nuove versioni possano essere consegnate ai clienti
Le fasi effettive della pipeline variano a seconda dello stack tecnologico e dell'approccio alla composizione della pagina.
Per quanto riguarda la composizione lato client, ciò significa caricare i pacchetti di applicazioni in bucket di hosting e rilasciarli all'uso tramite la memorizzazione nella cache di un CDN. Le applicazioni che utilizzano la memorizzazione nella cache del browser con gli addetti all'assistenza dovrebbero inoltre implementare metodi per aggiornare le cache degli addetti all'assistenza.
Per quanto riguarda la composizione lato server, ciò significa in genere distribuire la nuova versione del componente server e aggiornare il registro del microfrontend per rendere la nuova versione individuabile. È possibile utilizzare modelli di distribuzione blu/verde o canarino per implementare gradualmente nuove versioni.
