We are trying to empower our users to be able to deploy any version of our software, at any time, to a cluster of servers. The use cases are:
Appease users who are hesitant to upgrade their cluster “until everyone else has and all the bugs have been worked out”
The user who is “anxious to upgrade because they need the latest code which contains a bug fix to this problem they’ve had forever.”
The user who upgraded but then found a new bug and wants to downgrade (where as some other users just didn’t care)
The use case of “I need the latest development version so I can program my new app using the newest code, even if it’s a bit broken or untested.”
The use case of “our in-house team needs a development version/environment”
The problem I see is that these three use cases may progress at different rates - meaning we may have 4 release versions between the time that someone has the “latest development version” and the time when the hesitant user is ready to upgrade - so I don’t think dev / staging / production are sufficient.
I proposed having an environment for each version we release so that we can always deploy packages that match the configuration items stored in Chef. This means enviornment v1.40 would point to repo www.rpms.com/v1.40/ and would contain cookbooks which properly configured v1.40 (and may have changed later in v1.41, v1.42, v1.5, etc.). My assumption is a user, at any time, could change their environment to v1.40 and freshly deploy their servers and everything would come out correctly.
Is this a smart or bad idea? The worry on Ops is confusion - so many versions all over the place and it would seem difficult to maintain. But ultimately this could just be branches in git that power the cookbooks so I don’t know if it’s really that bad.
I’m looking for real-world experience, ideas or change-in-attitude suggestions from all of you. This is for an open-source project and we are catering to a very opinionated audience. We’d like to serve them well.
CEO / Co-Founder