Multiple environments per site

Not sure what you mean here: what's the relation between the instances? Are they clones of each other?

This is definitely something we are looking into. The way I originally saw this was to have relations between multiple sites. So you clone A to B, and then you have a "clone of"/"has clone" relationship between A and B. You could also repeatedly clone site A over site B (and maybe the reverse?).

Finally, maybe you'd want to migrate only the database or the files, but I'm not sure it's actually useful to go that far...

Therefore, I think the proper feature here is twofold:

1. site relationships
2. repeated clone

Does that make sense?

I'm not sure how appropriate it would be for sites to share backups. I'd rather have those different and have the "clone" functionality the basic way of propagating changes between sites. Maybe we could have a clone "button" next to the backup listing so that we can clone previous versions of a site instead of just the current one, but that would be real candy on top. The basic functionality I see here are those two key issues:

* #699920: site relationships
* #699922: multiple clone support

Until that is done, I'm postponing the reflexion here, feel free to reopen or open dependent tickets and document it here.

Much progress on this has been built into DevShop. But, this won't make it into Aegir 2.

I've been giving this quite a bit of thought lately, and come up with some ideas. I started by looking into how we might be able to leverage devshop. However, conflating sites and platforms is a non-starter for me, as it undermines Aegir's principle feature set (easy, reliable maintenance of many sites at once).

#699920: site relationships are the key. The way people currently use Aegir for development, testing and staging is to make multiple clones of a site. Naming conventions seem to be the principle way to mark sites as related to one another. However, these relationships aren't made explicit, or available through the Aegir API. We need, for example, to know that it's valid to sync dbs between siteA and siteA1, but not siteB.

The Relation module appears to provide an API to define exactly such relationships.

The main feature of devshop that appealed to me was its concept of 'projects' that link sites together. However, at the end of the day, the goal of a 'project' is nothing more than the creation of a production site. So why not just keep the prod site as the root of these relationships, and obviate the need to add a new entity?

Most small- to medium-sized sites, in my experience, live on shared platforms, and get relatively frequent updates to core and contrib. However, after initial development, their config only gets modified when new features are desired, or a bug needs fixing. This is usually much less frequent than security updates.

I like the idea of making this a 'mode' we can turn on and off for sites. That is, when you want to develop on a production site, you run an 'enable dev mode' task. This would:

1. ensure there's a 'dev' platform that matches the current prod site's platform, and create one, if not.
2. clone the prod site twice:
   1. create a 'dev' site on the 'dev' platform
   2. create a 'staging' site on the live platform

This is pretty much what I already recommend, just automated, and made easier to manage. We would have relationships defined between them, pointing the dev site(s) at both the prod and staging sites. Relation allows for 1:n relations so we could have multiple dev sites, per feature branch, for example.

Using hosting_git, we could create a new branch per dev site, though this functionality may need to be added.

We could also tag sites as 'dev', 'staging', or whatever and filter most listings for prod sites. This could allow us to only automate nightly backups for prod sites, for example.

I think we should then be able to turn 'dev mode' off, and have automatic cleanup of dev/test sites. Otherwise, they'll quickly get out-of-date after a couple platform updates. Or entail a bunch more overhead, to keep them up-to-date too. The next time you want to work on the site, just turn dev mode back on and you get fresh clones.

Note that this assumes that what's in git is at the site level, as we do with Valkyrie already.

So, it bears mentioning that we've had a team of developers successfully using this workflow, running Valkyrie for local dev, for the better part of a year at Poetic Systems. It's largely what we built Valkyrie to support.

Also, this should mostly involve contrib modules that add new tasks and the dependency on relation.module. We'll probably have to add or implement some new hooks wherever we want to leverage the relationships we define. Such as filtering 'sync' sources, or modifying Views.

I like this and i need this. How can i help?
@gboudrias also asking about platform relationships

gboudrias> Platform relationships have been a pretty sweet idea for a long time
gboudrias> Especially some sort of indication that X is Y's "child platform"
gboudrias> Or successor or whatnot
gboudrias> But I've always seen it as more of a workflow thing (so, not a priority)
gboudrias> I just meant it in the sense that often when you create a platform, it's the next iteration of a current one
gboudrias> ie openoutreach 7.21 -> 7.22
gboudrias> It would be nice to have a way to make this relationship explicit
gboudrias> Both for documentation and development possiblities

platform relationships would be handled in #2555393: Simplify updates

As a follow-up to #11, what came out of that was the Distributions module. For Aegir 5, we're planning on baking this directly into core.

I believe the original issue here can be resolved by:

1. Having a separate Aegir instance per environment, and
2. Using Remote Import to copy/sync sites between them.

We should add this info to the documentation, somewhere in the Servers section.