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.
Can I get somebody to validate my dual role “Webserver” + “Prod” idea? I think this is the right solution, but want to make sure since most of the octopus examples use things like “Test” and “Prod” as environment examples only (and not as roles), I want to make sure I’m not missing something.
Thanks for getting in touch! I’m very sorry about the delay in getting back to you. Your question seems to have been lost in the shuffle.
When you say move a site from one production server to another, are you meaning to deploy a project one by one only to the second server, while slowly taking the first out of circulation by not deploying newer releases to it? That’s what I’m assuming, but let me know if I’ve missed anything there.
Your suggestion of roles to tackle this sounds like it should totally work, but it would require changing the scopes of your relevant variables as you’re already aware. One idea to take that a step further may be to essentially duplicate the relevant variables that are currently scoped to environments into a variable set, scope them to the new role that you gave to your new prod server, and then include it into the project. Since these new variables are scoped to a target role, they’re considered more specifically scoped and will get precedence when deploying to the new target.
You can also exclude or include specific machines at deploy time. This would allow you to target your new prod server only when deploying a new release, and essentially ignore the old server (see screenshot below). Once all of the required projects have been deployed to the new server in this way, take the old prod server out of commission.
Would something like that help meet your requirements? I hope this helps, and please don’t hesitate to reach out if you have any further questions or concerns moving forward.
Thanks for the thoughtful response. Yes your understanding is correct. I suppose we could continue to update the older server AND allow all deployments from any project going forward to update the new server, but I also don’t want to cause confusion if somebody looks at the server. I guess I just need to weigh that against the work to move the environment variables to role variables. I did not know about the “specific targets” on the release page so thank you. However, i didn’t see a way to make this stick for the project. But even if it existed, because I want to exclude an environment, I would actually need to update all the other projects too.
I guess just note my future feature options. Either being able to have variables target lifecycle phases OR if environment variables were boxed in by the lifecycle, those would both allow me to do this accomplish what I’m doing without polluting the role concept.
Thanks again Kenny.
P.S. I asked another question here that also never got an answer:
I just want a look, if my answer seems reasonable that’s all i need. I was just looking for any tips that I might not be thinking of like your “specific targets” suggestion here.
