Timeline for Reapplying Users and Related Content to Database During Pipeline Promotion
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 6, 2021 at 13:44 | vote | accept | Christopher Spence | ||
| Aug 6, 2021 at 13:17 | answer | added | MoritzLost | timeline score: 1 | |
| Aug 6, 2021 at 12:52 | comment | added | Christopher Spence | And I'm also not sure what the impact would be (we're using redis) for session storage for active/logged in users. | |
| Aug 6, 2021 at 12:46 | comment | added | Christopher Spence | I think the rationale here is that we can be guaranteed that the "core" product is identical across the different environments... so it's almost like we're migrating a template through the pipeline, and "dropping the users back in" at the end. Which sounds simple enough in theory, but seems risky and problematic, to me at least, in execution. | |
| Aug 6, 2021 at 12:44 | comment | added | Christopher Spence | My hunch is that the management team will see the risks inherent here, but I wanted to validate. I suppose if we had to automate it, we'd need to capture extant users and related data rows (across several tables) in a temporary store and script their "re-entry" into the database first as elements, then user rows, then.. then.. then.. It feels gnarly to me and, as you suggest, not well aligned with how Craft is meant to work. | |
| Aug 6, 2021 at 12:40 | comment | added | Christopher Spence | Thanks @MoritzLost! There will be four environments here, with a pipeline automating promotion between them. I believe the content team will be editing and validating entries on a middle stage (i.e., not dev / not prod). This published content won't be altered in production, users will register for the site, interact with it, favorite it, etc. The user elements, though, are subject to a similar scenario that you identify and it's what I'm trying to get my ahead around. We had presented migrations as a solution here already, but the above is the current focus of exploration. | |
| Aug 6, 2021 at 8:19 | comment | added | MoritzLost | Just to be sure ... you are using a deployment pipeline that goes from dev to production (possibly with a staging environment in between), right? If not, your management is absolutely right, you should have one. But don't mix code and config changes with content changes. If you are deploying changes that require simultaneous content changes, migrations are the way to go. | |
| Aug 6, 2021 at 8:16 | comment | added | MoritzLost | What problem are you actually trying to solve with this approach? Craft is built to strictly seperate content from configuration. By mixing them together you go down a rabbit hole of problems ... for dev and QA, absolutely use separate dev, staging and production environments. But why would you want to copy content from a staging environment to a live environment? Especially since that content might also have changes in the live environment. How would you tell (in an automated way) how to merge different content states from your production and staging environments? | |
| Aug 5, 2021 at 21:01 | review | First posts | |||
| Aug 5, 2021 at 21:51 | |||||
| Aug 5, 2021 at 20:56 | history | asked | Christopher Spence | CC BY-SA 4.0 |