Minimalist staging support [#828428]

On fairly static sites, hosted within Aegir, a simple dev/prod process could be accomplished by cloning a site, making changes to the clone, then copying the clone over the original site. However, the current workflow is fairly cumbersome:

1) Clone site: www.example.com --> dev.example.com
2) Fiddle with dev.example.com settings, add new modules, etc.
3) Rename www.example.com --> backup.example.com
4) Rename dev.example.com --> www.example.com

One problem with this process, is that between steps 3 and 4, www.example.com won't resolve (nor have a "site under maintenance" message) until the next run of the queue.

It seems to me that allowing 3 & 4 in the same queue run would minimize this.

Comments

Comment #1

adrian CreditAttribution: adrian commented 21 June 2010 at 03:36

just so you know.

aegir isnt about managing modules. so step 2 is irrelevant.
you should be making use of something like drush make to do your build management

In HEAD atm, it is technically possible to migrate a site OVER another one, although it isnt enabled from the UI

Comment #2

ergonlogic

he/him

English

Montréal, Québec 🇨🇦

CreditAttribution: ergonlogic commented 23 June 2010 at 19:48

Thank you, adrian.

Step 2 was just for illustrative purposes (i.e., make some changes to the site), but you're quite correct.

I'll switch to HEAD and check it out.

Comment #3

adrian CreditAttribution: adrian commented 23 June 2010 at 19:59

Priority:

Minor

» Normal

So the major change in HEAD i made, was i took the special logic in restore (which was the ability to deploy a site over an existing site), and integrated it with deploy. I then gave migrate the ability to do so too, specifically so you can migrate a site onto a new database server. : http://skitch.com/vertice/djb4q/migtest7.dev-t

The clone command needs to also do this detection still, because it will be responsible for removing the old database if the deployment was successful.

Even if the functionality can be triggered in the backend, we then need to provide a user interface and the necessary plumbing for this. This is probably a partial answer #699920: site relationships

Comment #4

adrian CreditAttribution: adrian commented 23 June 2010 at 20:11

If the above items were implemented, the workflow would look like :

1. clone the live site over the dev site
2. do some changes
3. clone the dev site over the live site

Although to be fair, in reality the process wouldnt have you cloning a site to live.
it would rather involve finalizing the platform build for the new release, and migrating the live site to the new release.

Live would be copied onto dev, dev would be copied onto staging, and one the changes are approved you would create
a new platform based on the staging codebase and migrate the live site to the new release. At that point you should
have all your updates codified using features or what not.