New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow a Target to Have Multiple URIs #135

Open
theory opened this Issue Jan 1, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@theory
Collaborator

theory commented Jan 1, 2014

I noticed that Git allows this. It’s an interesting idea: one might be able to deploy to multiple servers in parallel! Handy when managing lots of identical servers. It would take quite a bit of work to update all the commands that accept targets to notice multiple URIs and fork off processes for each, but not too bad. Would also need to consider what to do if one fails. For example, if you deploy to a target with three URIs, and one fails, should the other two revert?

May not be worthwhile to pursue, as folks can also usexargs -P to deploy to multiple targets in parallel.

@ghost ghost assigned theory Jan 31, 2014

@theory

This comment has been minimized.

Show comment
Hide comment
@theory

theory Oct 24, 2014

Collaborator

Putting this off for now. I think it will be complicated. Lots of code touches the URIs, an in particular:

  • Deploy would need to deploy one change at a time per URI.
  • Revert would need to revert one change at a time per URI.
  • Verify would need to verify one change at a time per URI.
  • Then there is rebasing and checkout; same story. All five of these would require new UI, too, to show progress.
  • How would we show the status and logs from multiple URIs?
  • When logging deploys and reverts, would we have to use the same timestamp for all databases deployed to?

Too much to think about, and no immediate demand, though I do think it would be super useful. So, sometime next year, maybe.

Collaborator

theory commented Oct 24, 2014

Putting this off for now. I think it will be complicated. Lots of code touches the URIs, an in particular:

  • Deploy would need to deploy one change at a time per URI.
  • Revert would need to revert one change at a time per URI.
  • Verify would need to verify one change at a time per URI.
  • Then there is rebasing and checkout; same story. All five of these would require new UI, too, to show progress.
  • How would we show the status and logs from multiple URIs?
  • When logging deploys and reverts, would we have to use the same timestamp for all databases deployed to?

Too much to think about, and no immediate demand, though I do think it would be super useful. So, sometime next year, maybe.

@theory theory removed this from the v1.0.0 milestone Oct 24, 2014

@theory theory modified the milestone: v1.1.0 Mar 27, 2015

@loganbentley

This comment has been minimized.

Show comment
Hide comment
@loganbentley

loganbentley Dec 14, 2016

Has this been brought up again recently? Sqitch looks like a great solution for database change management but we need a solution that can deploy in parallel.

Has this been brought up again recently? Sqitch looks like a great solution for database change management but we need a solution that can deploy in parallel.

@theory

This comment has been minimized.

Show comment
Hide comment
@theory

theory Dec 16, 2016

Collaborator

No, not recently, and I haven't had the chance to work on Sqitch for a while. Contributions warmly welcomed, though.

Collaborator

theory commented Dec 16, 2016

No, not recently, and I haven't had the chance to work on Sqitch for a while. Contributions warmly welcomed, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment