Say you have a complex set of related apps that’s running your business. How do you ensure that someone making a change in some formula over here does not break some workflow over there?
I’m wondering whether there’s anything like integration tests, that ensure that everything is as expected on an ongoing basis.
(Asked for Coda, and got an interesting response.)
Hope you don’t mind, I moved the topic from the ‘ideas and features’ category, since it seemed more like an open-ended discussion topic, rather than a concrete feature for people to vote for.
I don’t have a definitive answer to the question, but I have some comments/thoughts:
First of all, I think it’s worth noting the distinction between changes to the workspace schema/formulas/automations and changes to the workspace content.
It’s quite likely that the majority of people in any organisation might be spending most of their time doing the latter, and a minority of people doing the former (probably in addition).
Fibery has version history for both sorts of changes, but it’s fair to say that rolling back to previous states is a non-trivial exercise.
Personally, I have experience of working in a regulated industry, where changes need to be well-controlled. But again, the two types of change are controlled differently.
Structural change
Changing the configuration of Fibery can be compared with upgrading of a tool. A subsequent validation exercise might be necessary to demonstrate that the upgraded tool is behaving as intended/required.
In this case, I might suggest that creating a duplicate workspace (without entities) and then validating changes on the duplicate ‘offline’ is a good strategy. Assuming the validation is successful, the changes can be rolled to production.
Of course, this doesn’t help much with the question of what the validation should entail, but I think that is something for each user/industry to determine.
Content change
Hopefully, structural change is infrequent, but content change is frequent. Fibery does not yet have sophisticated workflows for change management (e.g. role-based review and approval etc.) but it is possible to implement this. When coupled with ‘snapshotting’ (recording/archiving the state of an entity/document at a specific point in time) this can form part of a version control system that would be compliant with requirements in some regulatory frameworks.
In the coming days/weeks, I hope to post some ideas/templates about snapshotting and workflows, so perhaps these might prove useful/interesting.
Would love to hear other people’s thoughts…
My approach would be to use @Chr1sG’s suggestion (duplicating the Workspace before changing the structure) along with using a standard website validation suite (of which there are many).
But it might be tricky to “roll the [structural] changes to production” - depending on the changes 
Indeed. I would think that you would need to document very precisely the changes made in the sandbox workspace prior to validation, to ensure that you could make the exact same change to the production workspace when (if) the validation is successful.
I’d love to hear your thoughts on how to fake/achieve role-based review and approval. Does it involve automatically creating parallel/mirror entities in a different space, where only the approvers have edit permission?
It would be very powerful to be able to define permissions with relations. E.g. “this field can only be edited by user = CreatedBy.Manager” for things like mangerial sign-off (e.g. if you are using Fibery for expense tracking, or security review, or vacation requests, or other things like that).
There is the ‘contributor’ level of permissions, which only allows entities to be edited by assigned users. If you use automations to determine assignees (based on roles) you can implement what you are asking for (if I understand you correctly).
This would help with trialing changes, but it’s quite a lot of work and does not address ongoing integration tests. I.e. instead of having checks to make sure that constraints remain satisfied, you would need to think of anything that might go wrong while validating changes.
Perhaps you can explain how you might expect this to work (or how you have seen it work with other cloud SaaS platforms).