Quindi, se ho capito bene, l'approccio del tuo team è quello di creare binari inizialmente, poi spingere per testare, pre-produrre e alla fine produrre con quegli stessi binari, e l'approccio dell'altra squadra è usare i rami per riflettere i vari ambienti ed eseguire continui build da quei rami?
Considera che mentre sono d'accordo con te, poiché queste cose vanno sempre, ci sono punti a favore e contro questa idea. Se spingi la tua idea, dovresti essere consapevole dei problemi del tuo approccio e dei punti a tuo favore:
Pro:
- Il comportamento del programma non cambia, ne sei garantito. Se ciò che cambia sono file di configurazione o database, puoi garantire una correzione per qualcosa che funziona nella preproduzione semplicemente assicurando che i file di configurazione ei parametri del database siano gli stessi (non un piccolo vantaggio).
- Questo approccio è leggermente più robusto. Suppongo che anche il sistema di filiali abbia la sua parte di configurazioni e parametri di database che utilizza, ma può anche modificare il codice di ramo stesso per applicare le correzioni. Questo ha i suoi vantaggi, anche se contrariamente al sistema di build una volta, può rendere la valutazione della fonte del problema in produzione un vero dolore nella valutazione poiché qualsiasi può essere diverso.
Contro:
- I bug di produzione sono fastidiosi per le correzioni rapide. Supponendo che il problema richieda una modifica effettiva del codice, è necessario ricompilare e passare il test alla preproduzione e dalla pre-produzione alla produzione. Questo non è interamente una cosa cattiva , perché è più sicuro, anche se la gestione tende a ignorare completamente la sicurezza a favore della soluzione rapida, e potresti sperimentare momenti imbarazzanti con la gestione in cui devi spiega che il cliente dovrà attendere fino a quando non avrai completamente testato la correzione prima di rilasciarla. Non lo consiglio.
- Il test delle unità è tanto una possibilità quanto lo è nella soluzione build-per-environment, anche se è un po 'più complicato da configurare. Non è possibile utilizzare semplicemente i binari in altre parole, è comunque necessario taggare quella versione nel trunk del repository di origine e utilizzarla come riferimento.
Mi sembra che i punti critici qui siano la robustezza e la sicurezza rispetto all'efficienza di rilascio e che è più importante per la tua azienda. Probabilmente potresti ragionare sul fatto che se le scorciatoie sono permesse usando il sistema build-per-environment (e sai bene e probabilmente finiranno per aggiornare direttamente il ramo di produzione per le correzioni rapide), gli eventuali problemi costeranno di più all'azienda nei problemi futuri di quanto sarebbe costato alla società inizialmente dedicare più tempo a una correzione, e certamente non danneggerebbe la reputazione dell'azienda di prevenire i bug in modo retroattivo.
Se ciò fallisce, potresti dare l'humor alla possibilità di costruire direttamente alla pre-produzione per una soluzione rapida in caso di emergenze che consentirebbero di eseguire ancora il test, senza semplicemente avviare l'ambiente di produzione.
Soprattutto, non vale la pena creare attriti per questo problema, quindi sii flessibile e ascolta gli altri punti. In definitiva, vuoi solo ciò che è nel miglior interesse dell'azienda, e offrire troppa resistenza non è molto produttivo per l'azienda e in ogni caso non ti rispecchierà bene.
Spero che ti aiuti!