Upgrading to new Fabric (FAST) releases

[OceanEnigma]

Hello, Thanks for your great work being done in the Fabric, it looks like FAST is solving many of common problems.
Currently experimenting with FAST to adopt for an organization with many teams and resources.

How Fabric FAST could be used while keeping up with bug fixes and updates seamlessly?

For example:

• Should the repository forked internally? and then keep merging with new releases?
• let's say a release v29 is used to apply FAST now to a new GCP org. Is it safe to just update to the new releases and re-run some stages? is that even make sense to you?

Any tips on how to properly work with FAST on long term would be much appreciated.

Thanks for your support !

[ludoo]

FAST is designed to be forked and owned internally, and once it supports production updates don't matter much as they mostly introduce new features or module-level interfaces.

What we generally suggest is to

• have a separate internal repo for modules, and use versioning in module sources (?ref-vxx.xx.xx)
• have a separate org dedicated to IaC tests

With the above in place, integrating module-level changes (either from us, or more probably for internal use cases) becomes possible, and the test org is used to assess changes to the infra.

[olvesh]

Wondering about the same thing - are there any examples showing how this structure could be organised?
Apologies if this already exists, it is a lot of documentation to pour through, so I might have missed a thing or two...