Elastic Beanstalk è adatto per CD di livello enterprise?

Sto lavorando a un progetto che utilizza Jenkins per creare e distribuire microservizi su Elastic Beanstalk. Distribuiamo un ramo di integrazione in un ambiente di test, rilasciamo i rami in un ambiente di gestione temporanea e quindi un master finale per la produzione. Ho un paio di preoccupazioni nel farlo in questo modo: in primo luogo, significa che finiamo con una matrice di una build per progetto per ambiente, duplicando gli sforzi; e due, significa che non stiamo distribuendo gli stessi artefatti di build alla produzione che sono stati convalidati nella stadiazione.

Sono propenso ad abbandonare Beanstalk e passare a semplici ASG usando qualcosa come Chef per le distribuzioni. Ciò ci lascerebbe con una build per progetto, producendo un artefatto di build, e potremmo distribuire lo stesso artefatto alla produzione che è stato approvato nella messa in scena. Tuttavia, il passaggio ha un costo iniziale non trascurabile. Esiste un modo per utilizzare meglio Beanstalk che consentirebbe CI / CD più affidabili e più facili da gestire?

Nota : promuovere lo stesso artefatto di build è esattamente quello che voglio fare, ma dai documenti non vedo alcun modo chiaro per farlo; spiega come distribuire su EB dalla sorgente della tua app, ma non come promuovere una versione esistente in un altro ambiente, a meno che non riesca a scorrere oltre. Se è disponibile nello stesso EB, potrebbe esserci una limitazione nel plug-in di distribuzione EB di Jenkins che ne impedisce specificamente l'esecuzione in Jenkins, ma non ho visto alcun modo per farlo.

Opinione dell'IMO che il tuo problema non è con Elastic Beanstalk in quello scenario, è con Jenkins o almeno nel modo in cui lo stai usando. Dovresti davvero concentrarti sulla costruzione di "una cosa" solo una volta, indipendentemente da cosa sia quella cosa.

Divulgazione completa: lavoro per ThoughtWorks e sono incredibilmente di parte per GoCD. Proverò a precisare cosa intendo nel modo più neutro possibile. Userò i documenti del nostro strumento come esempi, ma speriamo che le persone possano estrapolare i loro sistemi.

Da qualche parte all'inizio della tua pipeline stai costruendo "artefatti". Potrebbe trattarsi di file binari che rappresentano in tutto o in parte l'applicazione oppure potrebbero essere generati da qualsiasi numero di strumenti come gli strumenti di test. Questi artefatti dovrebbero essere archiviati dal sistema e mai più ricostruiti. Il sistema dovrebbe quindi recuperare l'artefatto dalla revisione corretta quando necessario.

Per esempio...

1. Costruisco un file .jar ed eseguo alcuni test unitari su di esso, roba C / I di base. Se passa, quel file .jar e l'output dei test vengono caricati in quel processo di pipeline specifico .
2. La prossima pipeline potrebbe essere la distribuzione in un ambiente di test più complesso. Dovrebbe recuperare il barattolo esatto dal lavoro esatto che lo ha creato. Esegue quindi Elastic Beanstalk per distribuire quel vaso nell'ambiente corretto.
3. La pipeline successiva è la distribuzione della gestione temporanea. Torna indietro fino alla prima pipeline e recupera il vaso esatto dal lavoro esatto che lo ha creato. In seguito execus Elastic Beanstalk per distribuire quel vaso nell'ambiente corretto.

Queste sono pipeline separate perché ciò consente di eseguire più in parallelo o su richiesta senza bloccare.

È possibile utilizzare Elastic Beanstalk, Chef, Puppet, Ansible, uDeploy o un numero qualsiasi di altri strumenti per eseguire le distribuzioni effettive. Non è da qui che viene il tuo problema. I server di integrazione continua non sono stati originariamente creati per questo scopo. Ovviamente ci sono molti plugin che puoi usare per raggiungere lo stesso posto se questa è la tua preferenza.

I server di consegna continua come GoCD , Chef Automate e ConcourseCI sono stati creati appositamente per risolvere cose del genere.