In a nutshell what I need is a simple good practice for multiple (loosely coupled or tightly coupled), git repositories I would love to hear there is a good framework for that, but I have read a dozen other s.exchanges threads and most simply give a compromise solution, and only one suggested "have a good practice" ... just as an idea
A longer explanation would be :
We deliver distributed environments, i.e- many on-premises integrated SW solutions.
Let's assume these are my "code parts" :
Services : Service A Service B Service c Shared libs: db-lib logger-lib communication-lib FrontEnd: FrontEnd A FrontEnd B Android ios
On an SVN monolith repo it would probably look like this:
--libs
--db
--logger
--com
--service A
--assets
--tests
--
--service B
--assets
--tests
--
--service C
--assets
--tests
--
--FrontEnd A - html
--assets
--FrontEnd B - android app
--assets
--FrontEnd C - iphone app
--assets
--FrontEnd D - also html
--assets
the connection between services can be from interactive μServices, to a solution suite (such an internal organization portal, CMS , and 3rd party API)
Now, lets assume that I have just ran complete set of tests and integrated this environment into a client A on-premises site (his internal business portal).
after a success with this client we want to integrate client B . This client have some requests and we are now developing a new version, testing and pushing to site B. The fixes and features are in many of the above components inc. libs
Now client A has a bug and a minor request for change. And we need a complete set of the above code with the exact versions OR Push him to latest version (not always possible and/or cost effective)
After readings many threads on the s.exchange - dep management such as Git submodule , git subtree , subrepo are not intuitive, not easily configured and does not automatically change, and thus creates extra overhead and are error-prone .
Dep build/dependency tools are usually per-coding language and a mixed solution as the above will not use one solution to rule them all ,
I know there are external tools, and also researched some suggested hacks, most of those "admit" to be a partial solution for a deep challange.
So, regardless of the "tool" (or no tool),
What I would really love to learn is of a good and simple dependency management experience that will allow the developers to easily go back to "a point in time" , pull the right version of the code from each of the repos to a specific hotfix / feature branch(s) fix some code (2 lines of db lib, 3 lines of service B) , push the code , build, test and deploy,
and easily repeat this cycle with little pain as possible.
e.g., something like this:
http://nvie.com/posts/a-successful-git-branching-model/
but for dependent multiples repo flow.
