Come faccio a strutturare il codice e le build per la consegna continua di più applicazioni in un piccolo team?

Naviga le tue risposte
7

Sfondo:

3-5 sviluppatori che supportano (e costruiscono nuove) applicazioni interne per un'azienda non software. Usiamo TFS anche se non penso che importi molto per la mia domanda.

Voglio essere in grado di sviluppare una pipeline di implementazione e adottare tecniche di integrazione / implementazione continue.

Ecco come appare il nostro albero dei sorgenti adesso. Utilizziamo un singolo progetto di squadra TFS. 

$/MAIN/src/
$/MAIN/src/ApplicationA/VSSOlution.sln
$/MAIN/src/ApplicationA/ApplicationAProject1.csproj
$/MAIN/src/ApplicationA/ApplicationAProject2.csproj
$/MAIN/src/ApplicationB/...
$/MAIN/src/ApplicationC
$/MAIN/src/SharedInfrastructureA
$/MAIN/src/SharedInfrastructureB

My Goal (una pipeline di promozione piuttosto tipica)

  1. Quando viene apportata una modifica del codice a una determinata applicazione, desidero essere in grado di creare quell'applicazione e distribuirla automaticamente su un server DEV.

    • Potrebbe anche essere necessario creare dipendenze da componenti dell'infrastruttura condivisa.
    • Spesso ho anche alcuni script di database o modifiche

  2. Se il test degli sviluppatori passa, voglio avere una distribuzione automatizzata ma automatica di quella build su un server STAGING in cui gli utenti finali rivedranno le nuove funzionalità.

  3. Una volta approvato dagli utenti finali, desidero eseguire l'auto-distribuzione automatica in produzione

Domanda:

Come posso adottare al meglio le tecniche di implementazione continua in un ambiente multi-applicazione? Molti dei consigli che vedo sono più specifici per una singola applicazione, come si applica meglio a più applicazioni?

  • Per il passaggio 1, devo semplicemente impostare una compilazione di team separata per ogni applicazione?

  • Qual è l'approccio migliore per eseguire i passaggi 2 e 3 di promozione dell'ultima build in nuovi ambienti?

  • Ho visto questo funziona bene con le app Web ma per quanto riguarda le modifiche al database

posta kingdango 08.11.2012 - 19:45
fonte

3 risposte

2

Penso che Jenkins CI dovrebbe aiutarti a ottenere ciò che desideri.

  • Puoi anche gestire le dipendenze tra diverse applicazioni usando i plug-in di azione pre / post build di Jenkins.
  • Il plug-in Build Pipeline dovrebbe aiutarti a gestire la pipeline. L'ultimo plug-in consente di "riprovare" che dovrebbe aiutarti a tornare rapidamente alle build precedenti, se lo desideri.
  • Non ho usato TFS da solo, ma sembra che Jenkins abbia plug-in TFS disponibile.

Riguardo alle migrazioni del database, il DB di controllo versioni dovrebbe essere eseguito, in questo modo è possibile distribuire uno script di migrazione insieme alla distribuzione.

Jenkins + Build Pipeline ha funzionato bene per me da molto tempo. Quelle erano principalmente applicazioni web di piccole / medie dimensioni. L'ho provato anche per le piccole app iOS e Android.

    
risposta data 09.11.2012 - 06:58
fonte
2

Molti sistemi CI come teamcity o jenkins possono essere configurati per monitorare il sistema di controllo delle versioni e avviare i build quando vengono rilevati i check-in. La sequenza di eventi avviata dal sistema CI spesso si comporta così:

  1. Se la compilazione termina senza errori, l'unità esegue il test.
  2. Se l'unità esegue il test senza errori, la build viene distribuita nella gestione temporanea
  3. Se la distribuzione del server di staging ha esito positivo, vengono eseguiti test di integrazione (in questa fase le persone possono connettersi al server di staging e anche assicurarsi che il sistema funzioni)
  4. Se i test di integrazione passano tutti, la build viene copiata nell'area "good build"
  5. Una persona può quindi distribuire la "buona build" a proprio piacimento

Per quanto riguarda le modifiche al database, durante il processo di distribuzione è possibile ripristinare un backup dei dati sul server di staging e quindi avviare un processo di migrazione del database. I test di integrazione dovrebbero rilevare i problemi di migrazione e avvisare l'utente che ci sono stati problemi di distribuzione in staging, il che non consentirebbe la copia nell'area "good builds".

    
risposta data 09.11.2012 - 02:34
fonte
0

In un'azienda che ho lavorato per alcuni anni fa, avevamo TFS 2008 e gestivo le implementazioni attraverso le etichette di compilazione e un flusso di lavoro WF. Quando è stata modificata un'etichetta di build, un trigger distribuirebbe l'applicazione in un ambiente. Le modifiche al database sono state gestite tramite gli script di modifica selezionati in un progetto di database.

Se lo stavo facendo da zero, considererei TeamCity o un'altra soluzione di CI dedicata piuttosto che provare a migliorare TFS. Detto questo, forse la storia con TFS è migliorata al punto che è possibile provarlo con TFS.

    
risposta data 08.11.2012 - 23:02
fonte

Leggi altre domande sui tag

Approccio per lo sviluppo di software che dovrà essere trasferito su più piattaforme mobili in futuro Devo riscrivere la cronologia git di un progetto non GPL per rimuovere il codice GPL che è stato successivamente rimosso?