Terminology: Blue-Green deployment

Question

Let's say your organization uses a blue-green deployment model. Simple question:

• After Blue has gone live, do you rename it to Green, and the server(s) formerly known as Green now becomes Blue?

Or to put it another way:

• Are "Blue" and "Green" the names of the physical environments? Or are they logical names, i.e. synonyms for "current primary" and "current secondary"?

P.S. I understand the methodology and the benefits; I asking this question because there is lack of consensus within my team on whether "blue becomes green" or vice versa. To me it makes much more sense that Blue and Green refer to physical environments, not current role.

Answer 1

The point of the “blue–green” terminology is that there is no permanent hierarchy between these environments. Either environment may currently have the role of the production system, with the other being a staging system. For example:

• blue is live, green is staging
• prepare new deployment on green
• switch over to green:
• blue is staging, green is live

Answer 2

You could trust my answer over ones that disagree with it simply because of the votes it receives but I think I owe you more than just giving the correct answer. I'll show evidence that it's correct.

Let's assume that Blue is always the name of live production. If that's true, do any of these make sense?

At any time one of them, let's say blue for the example, is live.
Fowler - Blue Green Deployment

 

At any time, only one of the environments is live, with the live environment serving all production traffic. For this example, Blue is currently live and Green is idle.
Cloud Foundry - Using Blue-Green Deployment to Reduce Downtime and Risk

 

BlazeMeter - 5 Blue-Green Deployment Best Practices for a Smooth Release

 

Duane McKibbin - Zero Downtime Deployments In An IIS World

Our assumption that blue is always live makes no sense in the face of these quotes and graphics. Assuming that green is always live fairs no better. This is not what they are saying.

If that evidence is not good enough for you, I submit that if you had some fancy renaming technology that would make it easy to ensure that even as you switch which system is live, you can rename so that whichever is the live production system will always have a set name, then for Gods sake why name it blue? We are enduring down time to give it a meaningless name? If you're going to do that then at least name it production when it's production!

No, Blue Green Deployment doesn't do that. There is no renaming. There is one thing pointing at one of two names. We're doing this because we don't like the problems caused by renaming the systems during the switch over. We'd rather decide what is live in one place. You can't do that if the names of two different things both get to decide.

Since we don't have a way to rename both instantly without any downtime we don't give them names that pretend to know their status. That's what blue and green represent. Not knowing. That's why the names must be meaningless with respect to this decision. That decision isn't being made here. If you want to know, go look somewhere else.

Answer 3

I think the term blue-green deployment can be seen as confusingly named from a certain point of view. In my opinion, where I live, green is often used to represent "on", or "go", where as blue is "cold", which plays against servers, caches etc being hot, or warmed up, which seems common terminology for machines ready to work.

I can't think of a better name for the strategy, but the individual servers or clusters etc, could be called anything that the team agrees on.

• Bert & Ernie
• Mulder & Scully
• Peas & Carrots
• Eggs & Ham
• Yin & Yang
• Zig & Zag

Whichever is live is arbitrary, flip a coin when you fist go live, and then alternate as you deploy. Nothing needs to be renamed during the normal deploy. Only maybe when it comes to upgrade / new server time.