Seeding Production Repositories Recommendations

[ranger-zero]

In reading several for the projects README's it is suggested to "clone then fork stages" for possible teams to manage. This guidance does not make immediate sense to me. I have forked the cloud-foundation-fabric repository and I think it would be beneficial to break the stages I need into independent repositories. I have been researching options like git submodules, git subtree, --filter-branch, etc. I am wondering what guidance the community could give on if I was to take FAST into a mid-size or Enterprise where specific teams might own Stages, how might I segment out the mono repo but still maintain ability to commit history and ability to fetch and synchronize updates?

[ludoo]

The design we target and usually adopt is one repository per stage, as those typically belong to different teams (core cloud, networking, security, etc.) and their pipelines map to specific service accounts. Plus one repository for modules consumed by all the others via git refs and version tags.

It's not the first time this question comes up, so we're probably doing a bad job at communicating this. :) Where in your opinion should we make this clearer, and provide some info and diagrams?

And thanks for raising this of course!

[ranger-zero]

@ludoo thank you for your response. In reading the README's it is referenced in a couple of locations so it does have some coverage. I believe I have gotten wrapped up or confused about whether I should use a technique like git submodule or git subtree to maintain synchronization with my fork.

I believe my technique should use a git filter-branch on a stage sub-directory to create a staged specific repository. Then verify the modules git refs and version tags are linked back to my fork where I can maintain a sync to Cloud Foundation Fabric.

Please advise if this technique is sound?

[ludoo]

@juliocc might be better suited to understand your approach, I tend to get lost in git nuances :)

One word of caution though: syncing to our master is dangerous, as we tend to break backwards compatibility between major revisions pretty often...

[juliocc]

tl;dr don't overthink it and don't try stay in sync with us.

@ranger-zero I understand that you want to have separate repositories for each stage, but you also want to be able to port upstream changes (with history) to your forked versions. Is that correct?

As Ludo mentioned, we do not recommend this approach because we introduce breaking changes between major versions. Our recommended approach is to snapshot the repository and then manually backport any module or stage changes that you need. This will save you the headache of dealing with merges/rebases, and it will also give you more control over the changes that are actually deployed to your landing zone.

In my opinion, none of submodules, subtrees, or filter-branch are required for a successful FAST deployment. In fact, I would argue that they will likely make your life more difficult in the long run. I would recommend sticking with plain, independent repositories for each stage. After your initial deployment, you can simply cherry-pick the changes that you need.