I have a suite of python Azure Function Apps that all together make up an integration, each containing multiple functions:

  1. FunApp1
    1. func1
    2. func2
    3. SharedCode
  2. FunApp2
    1. func3
    2. func4
    3. SharedCode
  3. FunApp3
    1. func5
    2. func6
    3. SharedCode

("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.)

1 Answer 1


How much gets put in a repository depends on the scope of changes. As you have discovered, when the scope of necessary changes requires code beyond the repository, then things get complicated. That doesn't mean everything needs to be in the same repository. If code changes frequently, then "complicated" becomes "painful" — a fact you have undoubtedly discovered.

In this case, changes are frequent and large in scope. The mere fact that history is being lost on individual functions tells me all of these repositories should be merged into one Git repository. You do not have separate, isolated Azure functions. You have a process, and all the code in that process requires frequent, coordinated code changes, and therefore should live in the same repository.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.