Create "Deployment" Task

This is working really well!

See the dev-deploy branches in devshop_hosting and devshop_provision.

The "deploy" task, provision-devshop-deploy, replaces the pull task. This makes it really easy to put an environment at a tag or branch.

The only task left is to save the new git_ref for the environment within both the project context drush alias and the project node in hostmaster.

I think I need help to get this to just work with provision-devshop-deploy, I'm not sure how to re-saving the project context (drush alias)!

Deployment task work has been merged!

This means we also have a nifty "Deploy branch/tag" dropdown for environments right next to their branch selector! Couldn't be easier to switch an environment between branches or tags.

We still have work to do, like removing the "Pull Code" task, and making git webhooks trigger "Deployment" tasks instead.

This opens the door for removing the poorly conceived "environment settings form".

Marking this fixed.

I am reopening.

I am not happy with how this is setup. I now realize all tasks should be on sites themselves.

Devshop now treats the site nodes as the "environment" . When you are editing the environment settings, you are editing the site node.

With the new UI, each environment indicates if it has a process running on it. It is based on the site (and soon platform) nodes tasks.

We should move the few remaining project tasks back to sites.

Someone has already done this with Sync. Next is "Pull Code", which should be refactored to a "deploy task" on sites. This should go into hosting_git.module, not in devshop. Then "Commit Features" task will go back to the hosting_features module, which is incredibly ironic, since that was the very first aegir module I wrote, and all of devshop followed.

So I kindof went on a tangent here, but this is where I got the idea.

So let's work on creating this task in hosting_git.module. I actually think we can do more than "Git Pull". Git Pull is really useful when in development. Lots of people want to create new platforms to update, for good reason.

Let's enhance the "Deploy" task to be really robust. We could make it optional to just pull or....

Deploy

1. Clone & verify new platform with the chosen git ref.
2. Trigger a migrate task for the site to the platform. Fail if it's not compatible.
3. Run the desired drush calls (or recipes) on the site post-migrate.
4. Once the migrate task completes, optionally delete the platform.
5. Save a log of the platforms a site has been on over time.

I'm closing this. We've had the deploy task working on sites for a while.

This is less about "safely updating sites" and more about quickly deploying new code either pulling on the same branch or checking out a new one.