We are using Squidex as a headless CMS in our application which has 3 different environments. The approach we use is the following: develop application & content on dev environment, once it’s ready to be tested deploy everything on test and once everything is fine there - go to prod.
I’ve investigated how the CLI works and it seems like automating the process of syncing the content of one app (dev for example) and another (test) is kinda complicated. For example, we cannot simply migrate one app to another with CLI (schemas, content, assets and so on).
What approach can I use to satisfy the requirement with 3 different environments? Can we adjust the versioning of the content app-wide? For example, have 3 multiple stages for each type of content without introducing a redundant field for each of them.
Have you checked the sync command of the CLI?
I was planning to use this command. I was actually wondering if there is a functionality to migrate entities from one app to another using UI (a manually triggered rule maybe) on same self-hosted Squidex.
No, the reason is that this operation would be long running and I want to prevent UI for these kind of operations
Hi, for a quick solution to your problem you can backup an app and then restore it (same or different environment) with a new app name and it’ll take all the schema and contents.
We have squidex setup for multitenancy across multiple environments and so schema synchronization has been a big issue for us as all ‘apps’ must have the exact same schemas. We’ve now managed to fully automate this process and it seems to be working quite well but it’s taken us a long time to get to this point.
The process goes like this:
- Fine tune the schema in a specific app in our dev environment
- Export the JSON for the schemas and save into a ‘schemas’ git repo
- Update the ‘schemas’ git sub module in our squidex wrapper repo (where we define the code we inject into squidex at deploy time) to use this latest commit
- Our squidex extensions, the squidex release tag and our schemas commit are bundled together under a release number
- Deploy squidex from docker hub into our k8s cluster and run a post deployment script using the squidex cli to sync the schemas using the json files from the schemas commit.
- The schema sync doesn’t run if the current deployed version has already synchronized. We extended squidex to expose an additional API to return the schema commit so we can check at deploy time.
The more apps you have the longer this takes but so far so good!
Hello, thank you for your reply!
You’ve chosen a good approach. As of now due to simplicity of our application we decided to simply create manual rules that would trigger an export of data from one environment to another.
One more quick question, let’s say we’ve been doing some testing on our test environment and decided to deploy everything to prod using CLI and sync command. Given we have some specific rules set up on prod (Slack / Twitter messages) and we migrate published content from test to prod will the publishing rules work and take into account only new content or these rules will run from scratch for each record we have?
Why do you need this? The sync command does not change anything if nothing has been changed.
The rules will also run for synced content. I will provide a “fix” for that. Good point.
Thank you for quick update!
One more question though. After running sync in command a couple of times we’ve got copies of folder in assets. So we actually got 1 folder with content and 2 empty folders with same name.
Thanks, could be a bug. Can you open a ticket for that?
Unfortunately I couldn’t tell say as we’ve not sync’d content, sorry.
We could have invoked the cli as nothing would have changed, but we wanted to keep the deploy time to a minimum. Since we can have 100’s of apps we decided it was more efficient to perform a single api request compared to hundred of cli commands.
1 Like
If you want you can provide a PR for that.
