Stiamo cercando di adottare l'approccio microservice alla nostra applicazione di nuova concezione.
Tuttavia, abbiamo scoperto che ci sono troppi repository, rami e versioni da gestire. Originariamente, abbiamo solo 2 ~ 4 repository da gestire per un'applicazione. Dopo aver adottato l'approccio microservice, potremmo avere 10 ~ 20 repository per un'applicazione con la stessa complessità.
Quindi, ci sono delle migliori pratiche su come gestire questi microservizi di una grande applicazione?
Inizialmente con i primi microservizi non è male. Diversi sviluppatori hanno le loro macchine configurate in modo diverso, il che presenta alcune sfide, ma di solito queste possono essere rapidamente risolte. Ma una volta superati i 3 o 4 servizi, le cose si complicano. Piccole differenze negli ambienti diventano un dolore costante. Assicurati che tutti abbiano lo stesso ambiente senza molto lavoro e la gestione del flusso di codice diventa molto gravosa come stai vedendo / hai trovato.
Gli approcci che ho visto per aiutarti a risolvere questo problema sono:
Definire il set di servizi. Definisci come funzionano. Definire su quali porte vengono eseguite le cose. Definisci alcuni standard e assicurati che vengano seguiti. Utilizza la virtualizzazione (sotto) per implementare questi standard universalmente senza sforzo.
Si desidera un passaggio (o il minor numero possibile di passaggi) per creare e aggiornare le procedure dell'ambiente. Potrebbero esserci 100 passaggi effettivi ma si desidera ridurli il meno possibile in modo che l'aggiornamento dell'ambiente con il flusso costante di modifiche sia molto semplice. Vuoi evitare di aver bisogno di procedure e seguendo i passaggi dettagliati. Dovresti essere in grado di aggiornare e far funzionare le cose in meno di 5 minuti e idealmente meno di 1 minuto.
Con questo, per esempio Vagrant, puoi essere sicuro che, a differenza dell'ambiente dei singoli sviluppatori locali (che può essere altamente personalizzato) le macchine virtuali (per lo sviluppo) danno l'opportunità di avere ESATTAMENTE lo stesso ambiente, stesse impostazioni, profili, file di punti, ecc. separati dagli ambienti personali degli sviluppatori.
L'utilizzo di quanto sopra non ridurrà necessariamente la quantità di repository, filiali, rilasci. Tuttavia contribuirà a renderlo facile da fare e non oneroso. Una cosa che sto vedendo con le organizzazioni che ho visto assumere questa sfida è che questa è una nuova area che richiede tempo e sforzi per avere ragione. Potrebbe essere necessario dedicare risorse specifiche per farlo correttamente e mantenerlo mantenuto.
Per i rilasci effettivi è necessario uno sforzo maggiore per definire come funzionano le cose in modo che il modello possa essere ripetuto. Avrai bisogno di dedicare più tempo e sforzi per ottenere questo risultato rispetto ad una configurazione di 1 repository. Generalmente, l'idea è che con repository più piccoli e modifiche più piccole, se si dispone di un processo di distribuzione ripetibile, sarà più facile distribuire singoli pezzi. Anche qui l'automazione dei processi è fondamentale.
Leggi altre domande sui tag project-management architecture microservices