Prova il più possibile prima della distribuzione
La distribuzione non è economica. Anche se la distribuzione è completamente automatizzata e trasferita automaticamente dal commit, richiede ancora del tempo per la distribuzione, impedisce qualsiasi utilizzo dell'ambiente di sviluppo durante la distribuzione e se si distribuisce un'applicazione interrotta l'ambiente di sviluppo rimane bloccato fino a quando le cose non vengono riparate.
Dipende dal tipo di test di integrazione che hai, ovviamente. Un componente autonomo (ad esempio, un parser di messaggi che memorizza le cose in un database) non deve essere distribuito per l'esecuzione dei test di integrazione. Se si eseguono test dell'interfaccia utente, è ovvio che è necessario eseguire la distribuzione in un determinato ambiente per eseguire tali test.
Esegui quanti più test puoi durante la compilazione, e distribuisci solo per eseguire quei test che richiedono il vero sistema distribuito per poter essere eseguito.
I database in memoria sono ottimi per le unittests, non tanto per i test di integrazione
Il vantaggio dei database in memoria è che possono essere configurati e abbattuti rapidamente e hanno un alto tasso di inversione nei test. Molte persone preferiscono testare cose come ORM-mapping e repository con query su database in-memory ed eseguire test di integrazione su database reali. Penso che sia un approccio molto ragionevole, ma è una cosa molto personale. Se i tuoi test sono veloci, l'esecuzione su un server reale è migliore (perché più i test sono vicini all'ambiente di produzione reale, meglio sono).