5

From what I can tell, one can't change the Amazon RDS (RDS) endpoint of an existing Elastic Beanstalk (EB) instance?

If that is the case, than you can't have your code deployed to a stage server, stage DB, tested, then promoted to use the prod DB?

So how do you deploy stage without having to test against the prod db?

Given prod and stage, I thought the strategy would be something like this:

  • Snapshot prod RDS
  • Create stage with new code and point it at the snapshot
  • QA stage
  • Point stage to prod RDS
  • Change load balancer to send traffic to stage

bumped to the homepage by Community yesterday

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

0

I'm not familiar with Beanstalk, so take this with a grain of salt.

As I understand it, an A/B deploy strategy works kind of like this:

  1. A is in prod.
  2. B is in staging.
  3. Deploy to B until you like it.
  4. Make B Prod, turning A to Stage.
  5. GOTO 1

Databases are terribly stateful, and don't take well to swapping like that. As I've seen it done, step 3 up there is done kind of like...

  1. Snapspot A-prod into B.
  2. Run migrations on B.
  3. Run test series to validate it works.
  4. If tests, fail, GOTO 1 and repeat. Else, continue.
  5. During B-cluster promotion, apply known-good migration steps to prod database.

The tricky part here is the database indirection. For this, I suggest going Route53. During the deploy process:

  1. Stop all testing activity, and code-update the B cluster.
  2. Update the B-Database record to point to prod-database.
  3. During the deploy, run your migrations.
  4. Bring the B cluster into prod, which will be using the now-updated cluster.
  5. Stop the A cluster.
  6. Update A-Database record to point to Staging.
  7. Snapshot prod onto the test database.

You get the idea.

  • thanks for the detailed response. I think my main problem here is Beanstalk's (EB) RDS endpoint limitations. In your third section, you can't do step 2. This is because the EB instance was initially associated with the stage database, you can't update it to be associated with the prod database later. – Ryan Fisher Feb 1 '16 at 0:06
  • I guess you could spin up a 3rd EB instance once your code is tested, associate it with the prod DB, deploy code, run migrations and change the load balancer to route to this 3rd instance. Seems like extra work for no reason. – Ryan Fisher Feb 1 '16 at 0:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.