search

ansistrano / deploy

Ansible role to deploy scripting applications like PHP, Python, Ruby, etc. in a capistrano style
https://ansistrano.com
MIT License
2.37k stars 342 forks source link

Add support for not allowing two deployments in parallel #21

Closed carlosbuenosvinos closed 9 years ago

carlosbuenosvinos commented 9 years ago

We can use .lock files but any suggestions is welcome

teaforthecat commented 9 years ago

if you say --fork 1 on the command line that will do it right?

ricardclau commented 9 years ago

@teaforthecat --forks 1 will make Ansible connect to 1 host at a time, but the goal for this issue is preventing 2 people deploying at the same time.

Imagine for instance a distributed team deploying to 100 nodes in groups of 10... this is a relatively long process and we should prevent a second deployment until the first one has finished in all the nodes

teaforthecat commented 9 years ago

ah I see sorry. ok well how about this - wait_for: path=lock state=absent but since we have an atomic change with the current symlink is this really valuable? I guess if the inventory did not have a consistent order, some hosts could end up with a different release. This seems strange though. I'm thinking the responsibility should be at a higher level. I'm thinking the lock should live in Jenkins or Rundeck or... (do you have any other suggestions for an execution manager?)

ricardclau commented 9 years ago

I have thought a bit about this and I think there is no easy way to achieve it.

If all the deployments are originated from the same box (a Jenkins machine or something similar) the lock file strategy would possibly work but if a team is allowing any developer to deploy from any location the only way to do a common distributed lock is to have something like Zookeeper or Redis doing that function.

And I honestly think this is beyond the scope of a deployment tool and it really depends on every organisation policies.

We can add the lock file as a best effort but I am not sure it is worth it. Thoughts? @teaforthecat @carlosbuenosvinos @theUniC @ajgarlag

teaforthecat commented 9 years ago

I agree. If this is a problem, you probably have enough resources to spin up a deployer node. (I'd recommend Rundeck so far)

ajgarlag commented 9 years ago

I agree too. For me, this feature is beyond the scope of the tool.

cbrunnkvist commented 9 years ago

Totally agree with @ricardclau, it is a deployment process / organizational problem, not something that can be solved by a lockfile.

While it could save someone's donkey during a simple single-node deployment, I am quite sure that such a feature would cause much more inconvenience (in the form of stale/leftover locks) for others than what is gained.

You'll get into all sorts of other parallelism problems (DB migrations, LB configs) that are way out of scope for this "deploy" role, that are better solved at the playbook level.

ricardclau commented 9 years ago

Closing the issue according to the discussion