<p>IMO opinion your issue isn't with Elastic Beanstalk in that scenario, it's with Jenkins, or at least the way you're using it. You should really concentrate on building "a thing" only once, regardless of what that thing is. </p>

<p>Full Disclosure: I work for ThoughtWorks and am incredibly biased to GoCD. I'll try to spell out what I mean in as neutral was as I can. I will use our tool's docs are examples, but hopefully people can extrapolate to their systems.</p>

<p>Somewhere early in your <a href="https://www.gocd.io/getting-started/part-1/#concept2" rel="nofollow noreferrer">pipeline</a> you're building "artifacts". This could be binaries representing all or part of your application, or they could be output from any number of tools such as testing tools. These artifacts should be <a href="https://www.gocd.io/getting-started/part-2/#using_artifacts" rel="nofollow noreferrer">stored by the system</a> and never built again. The system should then fetch the artifact from the proper revision when needed.</p>

<p>For example...</p>

<ol>
<li>I build a .jar file and run some unit tests on it, basic C/I stuff. If it passes, that .jar file and the output of the tests gets uploaded to that specific <a href="https://www.gocd.io/getting-started/part-1/#concept4" rel="nofollow noreferrer">pipeline job</a>.</li>
<li>The next pipeline could be your deployment to a more complex testing environment. It should fetch the <em>exact</em> jar from the <em>exact</em> job that built it. It then executes Elastic Beanstalk to deploy that jar to the correct environment.</li>
<li>The next pipeline is your staging deployment. It goes all the way back to the first pipeline and fetches the <em>exact</em> jar from the <em>exact</em> job that built it. In then executus Elastic Beanstalk to deploy that jar to the correct environment.</li>
</ol>

<p>These are each separate pipelines because that allows you to <a href="https://continuousdelivery.com/implementing/patterns/" rel="nofollow noreferrer">run more in parallel</a> or on demand without blocking.</p>

<p>You could use Elastic Beanstalk, Chef, Puppet, Ansible, uDeploy or any number of other tools to do the actual deployments. That's not where your issue is coming from. Continuous Integration servers weren't built originally to do this. Of course there are lots of plugins you can use to get to the same place if that's your preference. </p>

<p>Continuous Delivery servers like <a href="https://www.gocd.io/" rel="nofollow noreferrer">GoCD</a>, <a href="https://www.chef.io/automate/" rel="nofollow noreferrer">Chef Automate</a> and <a href="https://concourse.ci/" rel="nofollow noreferrer">ConcourseCI</a> were built specifically to solve things like this.</p>

CC BY-SA 3.0
2017-03-04T16:47:28.100Z
Yes, my goal is to build once and promote to production. My question is whether beanstalk is suited to this type of usage. From what I can tell, it really doesn't seem to be; for example, the recommended method of deploying a .NET application is to do so from visual studio, which is just about the worst practice I can think of.
Adrian
CC BY-SA 3.0
2017-03-04T17:02:10.557Z
I haven't used it personally, but it seems like it would be if you change the word "promote" to "deploy". Your CD systems calls beanstalk to deploy to testing, runs some tests and then reports success / failure. If it succeeds, your CD system calls beanstalk to deploy to staging, and so on. 

So, the **promotion** is done by your orchestration tool, the **deployment** is done by your deployment tool. ( FYI, this is why companies like Chef have Hibernate (the thing), Automate (promote the thing) and Chef (deploy the thing).
Ken Mugrage
CC BY-SA 3.0
2017-03-04T17:08:59.987Z
FYI, it looks like you could script it (infrastructure as code is a "good thing") http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-getting-started.html - but again, absolutely 0 personal experience.
Ken Mugrage
CC BY-SA 3.0
2017-03-04T17:34:39.243Z
No matter what word you use, beanstalk doesn't appear to do it, as far as I can tell. It seems to be geared toward deployment from source, not from artifacts. From the page you linked: "When you run eb deploy, the EB CLI bundles up the contents of your project directory and deploys it to your environment." I appreciate the answer but my question is specific to beanstalk so hopefully someone who does have beanstalk experience can chime in.
Adrian
CC BY-SA 3.0
2017-03-04T17:43:22.863Z
Ah, sorry about that. I was interpreting 

`~/eb$ eb deploy
Creating application version archive "app-150630_014338".
Uploading elastic-beanstalk-example/app-150630_014338.zip to S3` to mean any zip file you stuck in that directory. Good luck!
Ken Mugrage
CC BY-SA 3.0
2017-03-04T18:31:36.870Z
Constructive intended comment ... your answer already contains "am incredibly biased to GoCD" (which is good). But in my experience a slightly reworded version of that is often used in any answer on any SE sites. I.e. by explaining "your" relationship to (in this case) GoCD (which BTW sounds intriguing ...), something like "(disclosure: I'm a developer/co-author/whatever-fits of it). Eg: I often add "I'm a (co-)maintainer of it" in any answers on Drupal.SE for any modules I refer to (and for which I'm a co-maintainer). Just a suggestion, ok?
Pierre.Vriens
CC BY-SA 3.0
2017-03-04T16:09:54.403Z
2017-03-04T16:09:54.403Z
Ken Mugrage
<p>I'm working with a project that's using Jenkins to build and deploy microservices to Elastic Beanstalk. We deploy an integration branch to a test environment, release branches to a staging environment, and then a final master build to production. I have a couple of concerns with doing it this way: first, it means we end up with a matrix of one build per project per environment, duplicating efforts; and two, it means we aren't deploying the same build artifacts to production that were validated in staging.</p>

<p>I'm inclined to abandon Beanstalk and move to plain ASGs using something like Chef for deployments. That would leave us with one build per project, producing a build artifact, and we could deploy the same artifact to production that was approved in staging. Transitioning has a not-insignificant up-front cost, however. Is there some way to use Beanstalk better that would allow for more reliable, easier-to-manage CI/CD?</p>

<p><strong>Note</strong>: Promoting the same build artifact is exactly what I want to do, but from the docs I don't see any clear way to do that; it explains how to deploy to EB from your app source, but not how to promote an existing version to another environment, unless I managed to scroll right past it. If it is available in EB itself, there may be a limitation in the Jenkins EB deployment plugin that prevents it from being done in Jenkins specifically, but I haven't seen a way to do it at all.</p>

CC BY-SA 3.0
2017-03-04T04:36:32.483Z
Is it your Jenkins environment that is posing the single build per environment restriction? I use Elastic Beanstalk to deploy applications and the uploaded application artifacts can be promoted (deployed) to multiple environments just fine. So, I am not really seeing the limitations you are describing. It sounds like there _may_ be a way you can utilize Elastic Beanstalk to do what you want. But this question is fairly broad as it currently stands.
Andy Shinn
CC BY-SA 3.0
2017-03-04T10:32:04.273Z
Why are you rebuilding your assets instead of promoting the same asset to other environments after testing?
Evgeny Zislis
<jenkins><amazon-web-services><continuous-integration><continuous-delivery>
Is Elastic Beanstalk suitable for enterprise-grade CD?
Adrian
# Is Elastic Beanstalk suitable for enterprise-grade CD?

(Asked by: username_0 on 2017-03-04)

I'm working with a project that's using Jenkins to build and deploy microservices to Elastic Beanstalk. We deploy an integration branch to a test environment, release branches to a staging environment, and then a final master build to production. I have a couple of concerns with doing it this way: first, it means we end up with a matrix of one build per project per environment, duplicating efforts; and two, it means we aren't deploying the same build artifacts to production that were validated in staging.

I'm inclined to abandon Beanstalk and move to plain ASGs using something like Chef for deployments. That would leave us with one build per project, producing a build artifact, and we could deploy the same artifact to production that was approved in staging. Transitioning has a not-insignificant up-front cost, however. Is there some way to use Beanstalk better that would allow for more reliable, easier-to-manage CI/CD?

**Note**: Promoting the same build artifact is exactly what I want to do, but from the docs I don't see any clear way to do that; it explains how to deploy to EB from your app source, but not how to promote an existing version to another environment, unless I managed to scroll right past it. If it is available in EB itself, there may be a limitation in the Jenkins EB deployment plugin that prevents it from being done in Jenkins specifically, but I haven't seen a way to do it at all.

**Tags:** jenkins, amazon-web-services, continuous-integration, continuous-delivery

> **Comments:**
> **username_1**: Is it your Jenkins environment that is posing the single build per environment restriction? I use Elastic Beanstalk to deploy applications and the uploaded application artifacts can be promoted (deployed) to multiple environments just fine. So, I am not really seeing the limitations you are describing. It sounds like there _may_ be a way you can utilize Elastic Beanstalk to do what you want. But this question is fairly broad as it currently stands.  
> **username_2**: Why are you rebuilding your assets instead of promoting the same asset to other environments after testing?  

---

## 1 answers

### Answer by username_3 on 2017-03-04. Score: 4

IMO opinion your issue isn't with Elastic Beanstalk in that scenario, it's with Jenkins, or at least the way you're using it. You should really concentrate on building "a thing" only once, regardless of what that thing is.

Full Disclosure: I work for ThoughtWorks and am incredibly biased to GoCD. I'll try to spell out what I mean in as neutral was as I can. I will use our tool's docs are examples, but hopefully people can extrapolate to their systems.

Somewhere early in your [pipeline](https://www.gocd.io/getting-started/part-1/#concept2) you're building "artifacts". This could be binaries representing all or part of your application, or they could be output from any number of tools such as testing tools. These artifacts should be [stored by the system](https://www.gocd.io/getting-started/part-2/#using_artifacts) and never built again. The system should then fetch the artifact from the proper revision when needed.

For example...

1. I build a .jar file and run some unit tests on it, basic C/I stuff. If it passes, that .jar file and the output of the tests gets uploaded to that specific [pipeline job](https://www.gocd.io/getting-started/part-1/#concept4).
2. The next pipeline could be your deployment to a more complex testing environment. It should fetch the *exact* jar from the *exact* job that built it. It then executes Elastic Beanstalk to deploy that jar to the correct environment.
3. The next pipeline is your staging deployment. It goes all the way back to the first pipeline and fetches the *exact* jar from the *exact* job that built it. In then executus Elastic Beanstalk to deploy that jar to the correct environment.

These are each separate pipelines because that allows you to [run more in parallel](https://continuousdelivery.com/implementing/patterns/) or on demand without blocking.

You could use Elastic Beanstalk, Chef, Puppet, Ansible, uDeploy or any number of other tools to do the actual deployments. That's not where your issue is coming from. Continuous Integration servers weren't built originally to do this. Of course there are lots of plugins you can use to get to the same place if that's your preference.

Continuous Delivery servers like [GoCD](https://www.gocd.io/), [Chef Automate](https://www.chef.io/automate/) and [ConcourseCI](https://concourse.ci/) were built specifically to solve things like this.

> **Comments:**
> **username_0**: Yes, my goal is to build once and promote to production. My question is whether beanstalk is suited to this type of usage. From what I can tell, it really doesn't seem to be; for example, the recommended method of deploying a .NET application is to do so from visual studio, which is just about the worst practice I can think of.  
> **username_3**: I haven't used it personally, but it seems like it would be if you change the word "promote" to "deploy". Your CD systems calls beanstalk to deploy to testing, runs some tests and then reports success / failure. If it succeeds, your CD system calls beanstalk to deploy to staging, and so on.   So, the **promotion** is done by your orchestration tool, the **deployment** is done by your deployment tool. ( FYI, this is why companies like Chef have Hibernate (the thing), Automate (promote the thing) and Chef (deploy the thing).  
> **username_3**: FYI, it looks like you could script it (infrastructure as code is a "good thing") http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3-getting-started.html - but again, absolutely 0 personal experience.  
> **username_0**: No matter what word you use, beanstalk doesn't appear to do it, as far as I can tell. It seems to be geared toward deployment from source, not from artifacts. From the page you linked: "When you run eb deploy, the EB CLI bundles up the contents of your project directory and deploys it to your environment." I appreciate the answer but my question is specific to beanstalk so hopefully someone who does have beanstalk experience can chime in.  
> **username_3**: Ah, sorry about that. I was interpreting   `~/eb$ eb deploy Creating application version archive "app-150630_014338". Uploading elastic-beanstalk-example/app-150630_014338.zip to S3` to mean any zip file you stuck in that directory. Good luck!  
> **username_4**: Constructive intended comment ... your answer already contains "am incredibly biased to GoCD" (which is good). But in my experience a slightly reworded version of that is often used in any answer on any SE sites. I.e. by explaining "your" relationship to (in this case) GoCD (which BTW sounds intriguing ...), something like "(disclosure: I'm a developer/co-author/whatever-fits of it). Eg: I often add "I'm a (co-)maintainer of it" in any answers on Drupal.SE for any modules I refer to (and for which I'm a co-maintainer). Just a suggestion, ok?  

---

