developing unrelated PTE apps: single multi-project repository or one repo per PTE? #1492
Unanswered
SteveKrisjanovsD365
asked this question in
Q&A
Replies: 1 comment
-
Recommendation is that each repo consists of apps that are released together and each project consists of apps that are installed together. In the case of a customer specific developed customization, I would put them in a private repo in an organization owned by the customer (or shared with the customer). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Some background:
Primarily my employer is a product-driven company (we currently have several CFMD onprem BC apps, as well as several apps published to BC appsource).
more and more customers however are asking for custom-built PTEs for their ERPs. Some of these may extend our onprem product. Others are standalone for the customer's respective industry.
each customer would have only one PTE, and every PTE regardless of customer would all share the same 78000..90000 PTE object range.
We do not (at this time) allow customers to contribute their code to our github repos. all development is billable by our team when specs are gathered.
Given this scenario, should i explore a single multi-project repository where there is one project (where the project name is the cusrtomer name) for each app e.g.
OR....should we create ONE private repo per customer PTE e.g.
I am aware that al-go releases are at the repo level, so I'm aware we need be careful with our release naming in a multi-project repo e.g.
what scenarious should use a single multi-project repo vs. one PTE repo per customer? Since the "create release" workflow creates release artifact ZIPs for all projects, I can see how that be confusing to see customerB artifacts in release customerA-v1.0.0.0 (I know I can delete the unrelated artifact zip files from the release once itsa finished.
I've been reviewing https://github.com/microsoft/AL-Go/blob/main/Workshop/Projects.md and it doesn't go into great detail on the use cases for one app per repo vs multiple apps+projects per repo
(we take the multi-project-per-repo approach for our appsource product suite since all the apps are in the same shared app family)
Beta Was this translation helpful? Give feedback.
All reactions