Drupal 10, the latest version of the open-source digital experience platform with even more features, is here.So I finally did it... not sure why it took so long.
I'm calling the task "Upgrade Drupal" since the "update" command is already taken by the "updb" task/drush command.
This task simply passes to `drush pm-update`.
Additional Steps:
- Triggers a verify task on the platform so the front-end knows the new versions of drupal. DONE.
- Trigger updatedb tasks on other sites on the platform.
- Proposed: Optionally put all sites on the platform into maintenance mode first.
- Give a strong warning on the confirmation page describe what is about to happen.
- Show the list of sites that will be updated on the confirmation page.
- Figure out a rollback functionality: perhaps it should exist in the drush command.
- Figure out if there would be a way to have a "new platform" + "migrate" mechanism.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 2707129-upgrade-drupal.patch | 2.36 KB | Jon Pugh |
| #2 | 2707129-upgrade-drupal.patch | 1.66 KB | Jon Pugh |
Comments
Comment #2
Jon PughComment #3
ergonlogicThis would affect all other sites on a common platform, no?
Comment #4
Jon PughYup, it's just a first step.
Passes right to pm-update, which runs updb as well on the chosen site.
Since we have the "updb" task, perhaps we queue up one for all other site on the platform?
Comment #5
Jon PughNew patch includes permissions and a post upgrade hook to enable a verify on the platform.
Comment #6
ergonlogicPlatforms are meant to be immutable. At least, most of Aegir core's workflows were built with that in mind. This would not only change that, but make it so that, from the context of one site, you'd be modifying the codebase under potentially lots of others.
Comment #7
gboudrias CreditAttribution: gboudrias at Praxis Labs Coop commentedI agree with ergonlogic's comment, I think distributions would be a safer way to do this: https://www.drupal.org/node/2704799
As far as I can tell there's no rollback mechanism here, which is a major advantage of migrations.
If we wanted to do this without distributions, I think a safer way would be to take the platform's makefile and make a new platform from it after automatically updating it, though the platforms would still not be "formally" linked which is why I prefer distributions.
Comment #8
Jon PughI understand that the "standard" aegir workflow recommends immutable platforms, however not everyone uses aegir in that way.
The very fact that there is an "Update Database" task indicates that platforms do indeed change sometimes. If every site followed the "new platform + migrate" workflow you would never need to use the "Update Database" task.
If a user wants to keep their platforms immutable, and block "Upgrade Drupal" tasks, all they have to do is not enable the permission.
To mitigate concerns of breakage we can:
This feature has been a major request from many people I have spoke to over the years.
"Tools. Not Policy."
Right?
Comment #9
ergonlogic"Update database" is also useful in the case where you have modules installed in the site dir. So it isn't really an argument for breaking with platform immutability.
When we have to choose between safety and ease-of-use, safety should always win. This is a natural tension between the reliability requirements of production hosting, and the efficiency desired for development.
That said, I'm fine with adding such tasks, as long as we:
The steps suggested in #8 already address a number of these. With that in place by default, we could then
form_alter()out the confirmation steps in Devshop, for example, to smooth the DX. For that matter, I'd even be fine with a master "I know what I'm doing, stop nagging me" checkbox.Comment #10
Jon PughComment #11
Jon PughThanks for your inputs, Christopher and Guillaume!
I had temporarily forgotten about the sites folder modules.
I've updated the issue with a TODO list with everything mentioned here.
Regarding overall strategy for Aegir...
I totally agree, but I think aegir provides us with the opportunity for not having to choose.
The atomic nature of aegir's deployment system is why it's been so successful hosting 100s or 1000s of sites in many major organizations. For that use case, you can't beat it.
For others, developing and deploying your full stack in a git codebase is perfectly acceptable and production ready: Acquia and Pantheon have been doing fine without immutable platforms and atomic deployments for some time.
I think Aegir has the opportunity to grow to fit all use cases and keep everyone happy, as long as we keep up healthy communication and open mindedness.
In other words, keep the advice coming! By talking all of this out, we will figure out how to design a system with the flexibility to fit all of these use cases.
I am going to put this code into a submodule in devshop for release for now, it will be a good way to iron out more kinks. I've already got other modules in there that are prepped for individual release for aegir like aegir_commit (UI for viewing diffs and committing files) aegir_download (UI for downloading modules) and aegir_features (UI for recreating features, soon to be renamed aegir_config for drupal8 config-export and config-import)
I will maintain this patch here when I add functionality to it over there (https://github.com/opendevshop/devmaster/tree/0.x/modules/devshop)
If someone else wants to go ahead and add it to aegir extras, that's fine by me too. I'd be happy to make more improvements in this project.
Thanks!
Jon
Comment #12
helmo CreditAttribution: helmo as a volunteer and at Initfour websolutions commented