Answers: <p>Yes.  With no QA and wanting to have an internal environment separated from production this makes sense.  However, a couple comments:</p>
  
  <ul>
  <li>You should go for whatever is going to make your business money instead of going for an enterprise standard.  While some of the common practices may not be sensible yet, keep in mind that as your company grows (e.g. a dedicated QA role), they might eventually be very useful.</li>
  <li>If you get rid of any stages, you are essentially eliminating a development environment.  Straight to production can be great, or greatly harmful.</li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2019-12-18T20:04:09.690Z
Answers: 2019-12-18T20:04:09.690Z
Answers: Wesley Rolnick
Body: <p>I'm building some new infrastructure in AWS and plan on having separate accounts for dev, stage, and prod environments. I'd like to implement a blue/green deployment strategy at least for production, and I've seen a few different ways this could be done, an obvious one being CodeDeploy's built-in blue/green deployment capability.</p>
  
  <p>Someone suggested to me that the stage/prod environments could be thought of as the blue and green environments. They are, after all, supposed to be identical environments, but I hadn't thought of stage being something that could act as a production platform. I think stage is supposed to be for end-to-end testing, final verifications by QA, demos, etc.</p>
  
  <p>So, I believe stage should continue to be for internal purposes only. But we may need two production accounts. At any given time each of them would be expected to contain a combination of inactive and active services (blues and greens). DNS (Route 53) would be in a shared account, and when a release occurs it would switch routings from resources in one account to resources in the other one.</p>
  
  <p>Then, it kind of seems like having stage is less useful when you have blue/green. When a new release is in the inactive state and going through the most comprehensive tests, it's essentially what stage does. And we don't even really have QA--developers and our customers are the QA. So can we get rid of it? I have heard praises sung of having a straight-to-production strategy whenever automated testing is taken seriously enough.</p>
  
  <p>Is this sensible?</p>
  
Tags: <amazon-web-services><continuous-deployment>
Title: Relation/interplay of deployment pipeline stages (dev-stage-prod) with blue/green deployment mechanisms?
UserDisplayName: Lucas Ross
ThreadText: # Relation/interplay of deployment pipeline stages (dev-stage-prod) with blue/green deployment mechanisms?
  
  (Asked by: username_0 on 2019-12-18)
  
  I'm building some new infrastructure in AWS and plan on having separate accounts for dev, stage, and prod environments. I'd like to implement a blue/green deployment strategy at least for production, and I've seen a few different ways this could be done, an obvious one being CodeDeploy's built-in blue/green deployment capability.
  
  Someone suggested to me that the stage/prod environments could be thought of as the blue and green environments. They are, after all, supposed to be identical environments, but I hadn't thought of stage being something that could act as a production platform. I think stage is supposed to be for end-to-end testing, final verifications by QA, demos, etc.
  
  So, I believe stage should continue to be for internal purposes only. But we may need two production accounts. At any given time each of them would be expected to contain a combination of inactive and active services (blues and greens). DNS (Route 53) would be in a shared account, and when a release occurs it would switch routings from resources in one account to resources in the other one.
  
  Then, it kind of seems like having stage is less useful when you have blue/green. When a new release is in the inactive state and going through the most comprehensive tests, it's essentially what stage does. And we don't even really have QA--developers and our customers are the QA. So can we get rid of it? I have heard praises sung of having a straight-to-production strategy whenever automated testing is taken seriously enough.
  
  Is this sensible?
  
  **Tags:** amazon-web-services, continuous-deployment
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-12-18. Score: 1
  
  Yes. With no QA and wanting to have an internal environment separated from production this makes sense. However, a couple comments:
  
  * You should go for whatever is going to make your business money instead of going for an enterprise standard. While some of the common practices may not be sensible yet, keep in mind that as your company grows (e.g. a dedicated QA role), they might eventually be very useful.
  * If you get rid of any stages, you are essentially eliminating a development environment. Straight to production can be great, or greatly harmful.
  
  
  ---
  
  