I have a suite of python Azure Function Apps that all together make up an integration, each containing multiple functions:
("SharedCode" is legitimately shared code, but it must be deployed with each Function App, per limitations of the platform.)
Typically, I'd make a single repo per function app that includes the entire folder structure for each. However, we are moving functions between function apps as we rearchitect and add features. (Our primary reasons for moving functions are to redistribute to balance out host resource contention on I/O-heavy tasks, but we're also experimenting with our mix of consumption plans vs premium plans.) With this additional need, it became cumbersome to move functions between function apps to test different structures, and we effectively lost git history and clean feature tracking on the individual functions.
So I switched to a git submodule-heavy setup where each function app is a repo with submodules containing the functions currently associated with it. However, with a gitflow-like branching structure, each little submodule has a gitflow loop, as does the parent function app.
I'm finding branch management to be a true nightmare. When I try to move between branches on the function apps and the set of submodules are different, I'm plagued with errors like:
fatal: not a git repository: ../../.git/modules/__app__/func2 fatal: could not reset submodule index
Plus, submodules tend to end up not on a branch, so I'm having to move into each one and put it on the branch I need it to be. It's... terrible. I'm at the point where when I need to do a hotfix, I just reclone the function app repo into a new location so that I can get at the
master branch, which is a red flag, full stop.
This definitely seems like it should be a solved problem in the function app/serverless app space, but I haven't found any clear guidance. What practices are folks finding that works? Is making this one large-ish repository a bad idea?
(I'm not married to the gitflow branching structure for this, but I will need to be able to distinguish local dev state versus what's deployed for testing versus what's live in production.)