Glad to hear this is working out - I came up with a similar solution
for our deployments
(using the same colour terms to stop people thinking 'a'/'b'/'c' or
'1'/'2'/'3' somehow indicated
an order of importance) but haven't implemented it yet.

Hadn't heard it mentioned elsewhere before. Have since googled
'blue/green' deployments
and realized there's nothing new under the sun :D

On 18 June 2015 at 17:42, Martin <[email protected]> wrote:
> I'd choose a red/blue/green approach.
>
> Basically it boils down to rotating the three environments (red, blue,
> green). The application is served from either separate hosts, directories,
> processes. Whatever your isolation level is
>
> The basic assumption is that, just like your application codebase, your
> codebase for configuration management is in version control so that you can
> jump back in time. It is up to you (or rather the assumptions and
> constraints of your business to find a workflow based on branches or
> whatever floats your boat)
>
> * red: Old "production version
> * blue: Current "production" version
> * green: Current "development" version -- this does NOT mean that
> development happens here. This DOES mean that the rollout and actual
> verification runs against this version (most probably the people who make
> the call of releasing a new version have access to it)
>
> As you are ready to release you will simply switch the thing that routes
> your traffic (it does sound an awful lot like a service that is reachable
> via a network connection) to the "green" environment.
>
> You end up with this state:
>
> * blue: Old "production version
> * green: Current "production" version
> * red: Current "development" version
>
> After the next deployment:
>
> * green: Old "production version
> * red: Current "production" version
> * blue: Current "development" version
>
> Now go forth and rotate :)
>
> Yeah it's pretty general, but I can't give you a more specific answer since
> your question was stated that way or it could be me simply misunderstanding
> what you want.
>
>
> On Thu, Jun 18, 2015 at 9:02 AM Yassen Damyanov <[email protected]>
> wrote:
>>
>>
>>
>> On Monday, June 15, 2015 at 3:38:49 PM UTC+3, skg wrote:
>>>
>>> How would you get ansible to deal with the following use case:
>>>
>>> An application, X version 1,  is installed with it's configuration
>>> variables for version 1.  Subsequently X version 2 is released with a
>>> differnt config variable set. I want to upgrade to X version 2 and preserve
>>> old configuration from X version 1. I also want the option to rollback to X
>>> version 1 at a later date restoring it to the configuration state it had
>>> prior to upgrading to X version 2.
>>>
>>> How would you go about ensuring this using Ansible?
>>
>>
>>
>> Where the installed app goes into? (what folder(s)?) What is the target
>> OS? Where/how are your version-dependent configuration variable sets kept?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ansible Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ansible-project/85636d21-048f-473d-92cd-7abf404a17e5%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> http://www.xing.com/profile/Martin_Marcher
> http://www.linkedin.com/in/martinmarcher
> Mobil: +43 / 660 / 62 45 103
> UID: ATU68801424
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/CAK1mKEQQW%3DY2A3-06YMgzTi0MuAkOnaEK01N37M3BetsmfH-GA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CAK5eLPQz9AQhJmYoE7kix7jj%2BtdbfVg2Oe%3DdFdjT1gBVpSau5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to