La build dell'applicazione ha bisogno di "risorse" esterne per funzionare: questo è cattivo o ... normale?

2

Stavo parlando con alcuni colleghi della build dell'applicazione e abbiamo alcune divergenze su ciò che ognuno considera una buona pratica o qualcosa di cui preoccuparsi.

Ho appreso che una buona applicazione build è autosufficiente , indipendentemente da quante dipendenze e test abbia, la build si prenderà cura di loro ed eseguirà la costruzione liscia.

Ad esempio, se ho un'applicazione che usa Maven, mi aspetto che un mvn clean install funzioni con i requisiti minimi: Java, lavorando su Internet e maven installato (se usi mvnw nel progetto, anche maven installato è facoltativo).

In questo scenario, non importa se la build esegue l'unità oi test di integrazione con MongoDB, Oauth2, RabbitMQ ... è il lavoro del programmatore simulare / stub queste dipendenze per i test eseguiti e la compilazione essere indipendente da servizi / database esterni / code / etc in esecuzione.

Per essere più chiari, quando parlo di test di integrazione , sto parlando di quelli "stretti": link , che in genere viene eseguito con il plug-in Maven failsafe nel mondo Java.

Ma alcuni colleghi non vedono alcun problema se una build dell'applicazione dipende da un MongoDB, un server Oauth2, RabbitMQ ed ecc avviati sul computer degli sviluppatori solo per la build. Anche usando la finestra mobile per aiutare, per me questo è l'approccio sbagliato, perché:

  • La compilazione è più lenta.
  • Aggiungi complessità nel processo di generazione.
  • Hai bisogno di una Wiki / guida solo per spiegare come funziona la build.
  • Consuma più memoria, perché le dipendenze esterne non vengono prese in giro.
  • Devi "resettare" la dipendenza esterna da ogni build.

Quando parliamo dei test di sistema (o dei test di integrazione "ampi" ), sì, abbiamo bisogno di tutti queste dipendenze esterne sono attive e in esecuzione, ma questo tipo di test non si verifica durante la compilazione.

Penso che la resistenza a creare una build autosufficiente derivi dalla complessità per gestire queste dipendenze dai test di integrazione. Anche usando Spring, non è facile bypassare un'autenticazione RabbitMQ e Oauth2, per esempio.

Sebbene sia chiaro per me qual è l'approccio giusto, non riesco a trovare alcuna discussione su Internet su questo argomento. Cosa ne pensate?

    
posta Dherik 17.01.2018 - 22:13
fonte

1 risposta

1

Non è raro avere test che richiede l'esecuzione di sistemi esterni, ma penso che sia raro avere una build che richiede l'esecuzione di sistemi esterni. Questa è una distinzione importante. La maggior parte dei team dispone di un server di integrazione continua che viene utilizzato per applicare tutte le modifiche al codice attraverso i propri passi, ma non è necessario che lo sviluppatore esegua l'intera suite di test.

The Build

Quando uno sviluppatore crea codice in locale, dovrebbe essere in grado di avviare la build e finire con un binario ragionevolmente testato:

  • Viene creato tutto il codice generato
  • Tutto il codice è compilato (incluso il codice di prova)
  • Tutti i test dell'unità vengono eseguiti
  • Il pacchetto finito viene generato

Questa build dovrebbe essere veloce . Più lento e complicato è il build, meno frequentemente sarà fatto. Più i test sono fragili, più è probabile che vengano disattivati o semplicemente rimossi.

I test di integrazione sono costruiti e pronti per essere eseguiti su richiesta, ma non vengono eseguiti con la build da riga di comando standard.

Integrazione continua (CI)

I server CI come Jenkins, TeamCity, AppVeyor e simili sono lo strumento utilizzato per eseguire costantemente i test con mano pesante. Il tuo ambiente di integrazione dovrebbe essere completamente configurato, con il server CI che può sostituire in modo sicuro parti di esso.

Questo è il posto dove verrebbe eseguito:

su ogni check-in.

Il motivo per cui i server CI sono necessari al giorno d'oggi è dovuto alla complessità di un ambiente pienamente funzionante. Se la tua app fosse completamente autonoma, allora i test unitari sarebbero tutto ciò che è necessario.

Detto questo, se qualcuno rompe la build, la tua squadra ha bisogno di un impegno che la correzione venga trovata in 15 minuti o che la modifica venga ripristinata ... altrimenti non è un'integrazione continua.

Dev Ops

Più automatizzi la generazione e l'implementazione, più è probabile che i problemi rilevati possano essere ricondotti a una modifica del codice. Quanto più è possibile osservare il modo in cui la tua applicazione viene eseguita e l'ambiente integrato, tanto più le tue decisioni saranno informate per le nuove funzionalità.

DevOps è una catena di strumenti che ti consente di fare proprio questo. Poiché la tua catena di build / deployment / test / report dovrebbe essere fatta con un'integrazione continua adeguata, l'unica cosa che rimane è strumentare la tua applicazione. Fornendo informazioni su come funzionano le cose, è possibile limitare i problemi di prestazioni sia negli ambienti di integrazione che negli ambienti di produzione. Il feedback dalla strumentazione può aiutare a guidare o migliorare i requisiti per la tua applicazione.

    
risposta data 18.01.2018 - 01:49
fonte

Leggi altre domande sui tag