We run a lot of sites. I would like the option of moving a site from one production server to another on an individual basis.
This means I can’t simply add another target with the same environment name because the lifecycle is tied to an environment and all projects using that lifecycle would also move or be duplicated when they got deployed. I could add another environment, ie Prod2, but that means I have to add that environment to every variable i have in octopus for that project.
As octopus is now, it looks like I would need to use roles for my environment names instead. Ie a server would be “Web Server” role AND and a “Prod” role. My variables would then target the role “Prod” instead of the environment “Prod” or “Prod2”, leaving those to environment names only used in the lifecycle.
Is this the only way I can move a site from one server to another?
From a feature opportunity perspective maybe variables need to be able to target lifecycle phases rather than environment names in deployment variables? My environments are named dev, stage, prod. My phases are also dev, stage, prod. But when I’m targeting a variable it is rarely machine specific and has more to do with where it is at in the lifecycle.
It seems that by picking the lifecycle which has environments assigned, that I’m sidestepping the lifecycle concept and going directly to the environments in the variable assignment. I was hoping i could just create an identical lifecycle with a different production server, but because environment names just seem to be target aliases and my variables are bound to those machine aliases, I can’t do that.
UPDATE: I later realized there is a problem with using roles instead of environments. In another case we wanted to setup a “beta” environment that was a stage site that connected to the production database. It made sense that we would run this from the same server as prod. However, this would mean that both the “beta” and “prod” role would be applied to the server in question…and there would be variables that would target both beta and prod…meaning there would be two variables values available for this single server. So I’m back to hoping that we can either someday target phases in a lifecycle, or if environments are context sensitive to lifecycle.