Role are not OS Version

Legacy Uncategorised
1

Hello

in the documentation :
Roles are not Environments or OS versions

How do you advice to manage different OS for different project. Project A is running on windows 2008 only and project B is running on windows 2012 only. If we deploy project A and project B in 3 different platforms (dev, staging, production), do you advice to create two environments for each platform and have : dev_2008, dev_2012, staging_2008, staging_2012, prod_2008, prod_2012 ?

The drawback of that is we will have a lot of environment. and we cant easily use the dashboard to see the platforms.

So my question is how do you advice to handle machine requirements (in term of OS or in term of installed components) ?

thanks
sebastien

2

Sorry, by role in meant machine role

3

Hi Sebastien,

Thanks for the getting in touch! While we do say that as more of a guideline, it’s not enforced. But thinking about your scenario:

  1. You have two different projects, and easily 2 different Lifecycles
  2. Your machines do not share steps in a process due to their OS requirements, so you have no need for simultaneous deployments to these machines.

Keeping the above in mind I would have to agree that roles aren’t how to solve this, but the idea of OS environments sounds best. It will mean that on a project level they would use a different Lifecycle each, but each in the end would just be dev - staging - production. It also means you do not have to restrict roles for each step in the projects. Our steps with roles are OR and not AND inclusive, so roles might not actually work if you have steps that do more than contact a single machine for each process.

Your environments page will be a bit long but it will be the best for your process and management.

Hope this helps!
Vanessa