Assign Servers for Pre-Deployment? (or a nice workaround to achieve the same)

[Michael Gebhardt]

Hello everyone,

 

today I come to you with an interesting question: is it possible to assign servers to the pre-deployment step?

 

The short answer is most likely "no", because the roc assign servers action only allows to assign servers to the deployment and post-deploy phase and also you would assign servers to a process that is already running.

 

So, I know this might sound insane and you're asking yourself, why I am asking this here, when I already know the answer. Well, the thing is, we're facing a problem now, for which I need a solution and maybe some of you faced this as well and might have an answer.

 

The problem is the following:

we have two server types assigned to our pre-deployment, "utility" and "environemnt servers". Uitily only includes one server that is allowed to run in parallel, "Envirnment Servers" got all the target servers of one environment assigned and these servers are NOT allowed to run in parallel, because we might run into trouble during the installation. The Environment Servers are in the pre-deployment, because we're running pre-checks on the servers, to see if the deployment can succeed (permission checks etc.). So, for a small application this wouldn't really be a problem, but we have a big one with several sub-projects and if all sub-projects (or at least two) are being deployed at the same time, the deployments block each other, because the pre-deployment will run one after the other. I know this is because CA-RA checks what server types and so which servers are needed for the process to run and reserves those servers, so as long as they are not allowed to run in parallel other deployments, that use the same servers, will be blocked.

This wasn't as much of a problem up until now, I mean, it wasn't nice, to have to wait, but it was only because they deployed several projects of the same application to the same environment. But the problem now is, that one of these servers might be used in several environments, which means that someone is deploying to Env A he is blocking a deployment to Env B, although the server itself might not even be used for the deployment itself and it is only reservered for the pre-deployment, because the server is part of the environment servers server type.

 

If I allow this one server to run in parallel, the blocking shouldn't happen, right?

 

Nevertheless, I'm really curious about if there is any possible way to define/assign the servers for a server type for the pre-deployment

 

best regards

Michael

[Michael Gebhardt]

argh, I forgot that the parallel execution is set on the server type and not on the server itself

[Chip Rabinowitz]

Michael, i'm not quite sure what you're asking here......there are a group of actions that allow you to modify server assignments.....check in the ROC group under "Server Assignment".....

 

If none of these actions will solve the problem, maybe you can describe it in more detail so i understand what you need to do?

[Michael Gebhardt]

Hey,

 

in all of these actions the step's stage is limited to deployment und pre-deployment, although it is not listed in the json one, but I assume it is the same for this one as well.

 

I'll try to make myself a bit clearer:

 

The setup is as follows

• Server Types:
  • Utility (parallel execution allowed): one server for the general stuff to do
  • Environment Servers (NO parallel execution allowed): a server type that includes all servers for a specific environment, so that we can run cleanups and prechecks
• Process
  • Predeployment with Utility and Environment Servers assigned.
• The application with this setup has multiple subprojects that share servers/environments

 

What are we doing?

In the Predeployment we're running some general parameter configuration and server assignment for the deployment steps. After that we are also doing some prechecks on the environment servers if the deployment is even able to succeed.

 

What is the problem?

CA RA behaves in a way, that it blocks/reserves all servers that are assigned to a process, which means for our current setup that we can't run several pre-deployments in parallel for one environment. This was "ok" so far, as the blocking was limited to one environment but now the project considers sharing one server for several environments, which would lead to the fact, that in the worst case a pre-deployment to a dev environment blocks one to production, if they are run at the same time, even if the server itself might not even be needed, but as it is assigned to the environment servers server type, it gets blocked anyway because CA RA can't know if it is needed or not. So I was wondering if it is possible to assign servers to the pre-deployment or even "unassign" servers, that are not used. Of course they still would be blocked until the part of the predeplyoment is reached, where this is handled, but at least they wouldn't be blocked for the whole predeployment.

 

What I found out so far:

I don't see a way of achieving it with server assignment handling, as they appear to be limited to the deployment and post-deployment stage. So our only way of avoiding a blocking of serveral environments if the project decides to share one server, would be to create a new server type with this shared server included and allow it to run in parallel.

 

I hope this time it is more understandable.

 

thanks,

michael

[Chip Rabinowitz]

I won't comment on the practice of having shared environments on a single server to include both Dev and Production.

 

But they shouldn't be blocked very long, unless your predeployment tasks on the env level servers take a long time.

 

I typically use PreDeply for health checks, and they certainly don't take a long time on each physical server.......and that's where the blocking takes place, not on the server type, but on each physical server -- so as soon as the tasks on the server complete, if there are tasks from a different process waiting, they will execute immediately.

 

So i'm not quite sure what the issue is....

[Michael Gebhardt]

we have a complex predeployment because it does build the deployment in a generic way...but nevermind, I will "close" the question

 

and yes, sharing a server is...well...lets say we don't like it either, but it isn't our decision to make

[Chip Rabinowitz]

Maybe we should discuss offline to come up with a better way, Mike……

 

Chip Rabinowitz

Senior Enterprise DevOps Architect

A&I Solutions

702-443-7520

[Michael Gebhardt]

what do you mean offline?

 

I already accapted, that there isn't a really nice solution to this problem and if the project really wants to share this server, they have to live with the consequences

 

(luckily they didn't do it yet, so maybe our words against that helped)