Environments and site life-cycle
I want to be able to introduce the idea of environments to Aegir. By environments I mean like development, staging, production etc. The idea is that servers are configured to host specific environments. New sites are always deployed to the development environment. At specific points in the sites development life-cycle it may be cloned to staging, and then production. At some point the site may be cloned back to development and the cycle begins again.
Sites may exist in some or all of the environments at once, so the normal Aegir clone wont work, as it will only copy to new sites.
I have begin work on two modules using the available APIs from the hosting module and it's sub-modules. One is called 'environment' which creates the node type and allows a site to be associated with an environment. The other is called 'deploy' and is basically clone with the ability to copy over existing sites.
Before I go to far here I'm wondering if anyone else is working on anything like this, or have some ideas to contribute about how this should work and the best way to go about it.
Thanks,
Paul
#1
I have added a diagram that explains this a little better.
#2
Nice
There had been more talk about supporting workflows in Aegir... unfortunately no definitive solution has emerged.
Some examples:
#3
Another related site: http://dcycleproject.org/
#4
Thank you for the feedback. I'm looking at these other projects now. The Hostmaster APIs seem like they provide everything that is needed to make this work. I'll keep you posted.
#5
Thinking about the difference between the problem I am trying to solve and this post http://community.aegirproject.org/discuss/further-questions-multi-server... , I realized I am talking more about content development rather than features, themes, or modules. Obviously I need a similar workflow for the latter as well, but in this case I am more focused on site building / content loading. So in my environment each instance of a site would be running on a copy of the same platform, with the same set of modules, themes, etc. The only exception to this would be during an upgrade to a new platform, where we would migrate the dev instances first before the staging or production.
#6
First, if you are talking about "Content Development" I suggest you build staging and approval processes into your site. Workbench Moderation handles the ability to create new drafts of unpublished content and publish them when they are ready.
Second, our project for Aegir called DevShop handles this exact feature. You can now create a project node from a Git repository URL and DevShop will automatically create 3 platforms with one site each (for dev, test, and stage).
These platforms are grouped together by project, and have their "environment type" flagged so that we can make useful tasks available, like "Commit Features" from Dev, "Sync Content" to test, and "Pull Code" to live.
It is still in rapid development, but our patches to hostmaster have been committed so it should be very simple to get it up and running in aegir 1.20.
#7
Thanks for the info on DevShop. This sounds like just what I'm looking for. I will let you know how it works.
#8
DevShop looks like it will be very useful. I was able to install it on 6.19 with no problems. There are a few things I'm not convinced about, like having the entire platform in Git. Normally I use drush make to pull stuff in from multiple repositories. Also one site per platform isn't going to work for us. We have hundreds of sites running on each distribution. I'm sure these issues can be addressed.
#12
In reply to lieb:
Every shop is different in that regard, and I want devshop to be flexible as possible. I know aegir is usually used to host a large number of sites per platform, I am just not sure at the moment how devshop should handle those situations...
At the moment, we build devshop_projects to group sites and platforms together. In the database table, you can save as many sites and platforms to a "project" as you want... so it is possible to build a UI to assign and existing site or platform to a Project, and in fact, that was one of our initial ideas in terms of an interface (a select list of projects on a site or platform.)
Now, when you create a project, we create the three dev/test/live platforms for you, automatically. Once those verify, we present you with a simple select list of your install profiles, you choose it, and we create one site per platform. I wanted to automate and standardize these environments to make it easier for teams of developers to work on multiple projects. Standard URLs for projects is something you have to fight for in some teams!
On another note, I just committed some changes and made a new release for provision_git, so now, if you use a site alias, it calls "git pull" etc in the site folder. If you use a platform alias, it calls "git pull" in the platform root.
With that, I think you should be able to use some of the devshop tasks right now without creating project nodes and with using one git repo per site, not per platform.
Thanks for your feedback, it really is valuable, our goal is to make it work for everyone, or at least workable! ;)
#9
I'm glad to see some activity on devshop.
I was afraid the project had perished since I saw little activity. Even the two issues in the provision_git queue didn't get any follow up. (http://drupal.org/node/1561536 & http://drupal.org/node/1561540)
#10
Sorry about those! I got so distracted with everything else...
Those no longer apply to 6.x-1.x, but they look great, so I'd be happy to commit them. I won't have time until monday, but if you get a chance to re-roll, I'll commit them as soon as they apply!
Thanks for your interest.
#11
Nevermind, I went ahead and did it, and cleaned up a couple of other things while I was at it! alpha4 is on its way