Feature Request: Choose servers to deploy to

[alsotop]

When pressing performing a deploy though the interface (and not webhooks) it would be nice if for a project that has multiple servers, you could choose to turn off certain servers you do not wish to deploy to. This could be presented as a list of checkboxes on the deploy modal, that only appears if there is more than one server, and by default all would be ticked.

If such a feature were to be implemented and in the future someone wanted the same functionality for webhook deployments, optional argument(s) could be provided to the webhook URL.

[REBELinBLUE]

Can I ask the purpose for this? I guess it would be so you can have different staging and production servers?

At work we have separate staging and production projects, the reason being some of the commands needed to run are different depending on whether your are deploying to staging or production, for instance on a production site you might need to run gulp --production. Of course you could have this as an optional command, but then you would have to remember that when you deploy to your staging server you don't tick that but when deploying to production you do which I think leaves a lot of room for errors

[alsotop]

Sure, we have the same set up too, with staging and production servers. However, we're running an ecommerce platform that is deployed to several production servers, but sometimes we might want to deploy to one of the two (or more) production servers.

However, I can see that this is more likely to cause issues than resolve them, so I think we could probably have two production projects for each server if we wanted to be able to deploy to two production servers separately.

[REBELinBLUE]

I guess that kind of makes sense, I guess I could make it on option on the project although it will take a bit of thinking about

[axeloz]

In my case, I would be very glad to be able to choose to push either to staging or to prod using the same deployer tool. That means having many servers, some for staging and some for prod, and of course different settings between them.
Technically speaking, it means creating an "environments" table (id, name, ...), and attach servers, commands, deployments, project_files, shared_files and variables to a given environment. Then, a user will be able to run a deploy on a given environment. Quite some work I guess.

[REBELinBLUE]

At work (which is what I originally wrote this for) we had separate projects for staging and production, because the commands would be slightly different (for example CSS/JS could be compiled with sourcemaps on staging and minified on production)

[axeloz]

@REBELinBLUE yes exactly, I understand this. It could also be two branches for the same project (master and dev). But still, adding an environment table on the deployer could solve this by attaching related objects to environment instead of projects. Commands, servers, logs etc... will depend on the environment.

So in your case, your must create two projects in the deployment tool for the same projet?

Anyways, I understand this is a big work to do, this is just an idea but I'm pretty sure this could be convenient for a lot of people.

[aiddroid]

@axeloz Yes, I agree with you.If the project servers have an additional attribute of "environment",deployments can be sent to different server group. And in my opinion, the other servers' commands should be as same as the production servers',it's not a bad thing.But if different server has different commands can be more flexible.

[bbashy]

For staging or non-production deployments, I'd look into something like https://kubernetes.io which can be used with GitLab to auto deploy staging sites without calling a deployer (this).