BC21/22 Simultan Entwicklung MSPartner und Endkunde
10. November 2023 17:46
Hallo liebe Leute,
ich bin bereits eine ganze Zeit in der NAV-Welt und konnte mich in punkto BC/AL auch schon vor einiger Zeit schulen lassen. Leider hat es noch etwas gedauert, bis ich nun ausschließlich BC/AL mache und habe eine grundlegende Frage. Ich bin beim Endkunden beschäftigt und z. Zt. entwickelt unser MSPartner alles noch selbst. Das soll sich ändern. Seltsamerweise haben wir vom Endkunden keinen Zugriff auf das dortige DevOps.
Die Frage die ich Euch stellen möchte lautet: Wie kann es ermöglicht werden, dass ein Customizing vom MSPartner und Endkunden-Inhouse-Entwickler durchgeführt werden kann. Zu berücksichtigen ist hier ja, dass es ein gemeinsames Devops geben muss, einen gemeinsamen Masterstand - oder?
Beispiel: Der MS-Partner hat etwas entwickelt und ich soll das weiterführen.
Oder: Der MS-Partner und ich entwickeln zu unterschiedlichen Themen etwas.
Oder: Es befindet sich ein Schreibfehler in einer deutschen Caption, diese hat ursprünglich der MSPartner gesetzt. Ich soll dies nun korrigieren, damit auch Laufzeit und Kosten gespart werden.
Es geht hierbei ja um mehrere Themen, wie z.B. "ein gemeinsames Devops?", "App-Bezeichnung/Version", usw.
Habt Ihr Links oder weiterführende Ideen zu diesem Thema? Wie macht Ihr, die ihr beim MS-Partner arbeitet das mit den Inhouse-Kollegen beim Endkunden bzw. Ihr beim Endkunden das mit dem MS-Partner?
Beste Grüße
Steffen
ich bin bereits eine ganze Zeit in der NAV-Welt und konnte mich in punkto BC/AL auch schon vor einiger Zeit schulen lassen. Leider hat es noch etwas gedauert, bis ich nun ausschließlich BC/AL mache und habe eine grundlegende Frage. Ich bin beim Endkunden beschäftigt und z. Zt. entwickelt unser MSPartner alles noch selbst. Das soll sich ändern. Seltsamerweise haben wir vom Endkunden keinen Zugriff auf das dortige DevOps.
Die Frage die ich Euch stellen möchte lautet: Wie kann es ermöglicht werden, dass ein Customizing vom MSPartner und Endkunden-Inhouse-Entwickler durchgeführt werden kann. Zu berücksichtigen ist hier ja, dass es ein gemeinsames Devops geben muss, einen gemeinsamen Masterstand - oder?
Beispiel: Der MS-Partner hat etwas entwickelt und ich soll das weiterführen.
Oder: Der MS-Partner und ich entwickeln zu unterschiedlichen Themen etwas.
Oder: Es befindet sich ein Schreibfehler in einer deutschen Caption, diese hat ursprünglich der MSPartner gesetzt. Ich soll dies nun korrigieren, damit auch Laufzeit und Kosten gespart werden.
Es geht hierbei ja um mehrere Themen, wie z.B. "ein gemeinsames Devops?", "App-Bezeichnung/Version", usw.
Habt Ihr Links oder weiterführende Ideen zu diesem Thema? Wie macht Ihr, die ihr beim MS-Partner arbeitet das mit den Inhouse-Kollegen beim Endkunden bzw. Ihr beim Endkunden das mit dem MS-Partner?
Beste Grüße
Steffen
Re: BC21/22 Simultan Entwicklung MSPartner und Endkunde
10. November 2023 18:33
Herzlich willkommen im Forum!
Die Grundlage ist ein gemeinsames Repository für den gesamten Quellcode, welches heutzutage üblicherweise über den "Quasi-Industriestandard" Git verwaltet wird und bei GitHub für alle Beteiligten (auch unternehmensübergreifend
) zugänglich gemacht werden kann.
Links dazu hier.
Darauf aufbauend bietet Al-Go for Github praktisch alles, was man für DevOps, CI/CD usw. benötigt. Das benutzt MS mittlerweile auch selbst für die eigenen Apps.
Es gibt auch noch andere Möglichkeiten mit Azure DevOps und Drittanbietertools, die aber nicht wie die obigen kostenfrei verfügbar sind, und mehr unternehmensintern im Einsatz sind.
Die Grundlage ist ein gemeinsames Repository für den gesamten Quellcode, welches heutzutage üblicherweise über den "Quasi-Industriestandard" Git verwaltet wird und bei GitHub für alle Beteiligten (auch unternehmensübergreifend
) zugänglich gemacht werden kann. Links dazu hier.
Darauf aufbauend bietet Al-Go for Github praktisch alles, was man für DevOps, CI/CD usw. benötigt. Das benutzt MS mittlerweile auch selbst für die eigenen Apps.
Es gibt auch noch andere Möglichkeiten mit Azure DevOps und Drittanbietertools, die aber nicht wie die obigen kostenfrei verfügbar sind, und mehr unternehmensintern im Einsatz sind.
Re: BC21/22 Simultan Entwicklung MSPartner und Endkunde
13. November 2023 17:22
Hallo Kai,
vielen Dank für deine Antwort. Gemeinsames Repository - dass ist die Grundlage, ja. Nur hat ein oder dieser MS-Partner die Angewohnheit, dass er sein Customizing in "seiner" App hat - so auch die Benamung. Bzw. er hat sogar zwei Customizing-Erweiterungen bei uns im System. Das Problem, das sich vermutlich nicht lösen läßt ist, dass wenn etwas "nicht mehr funktioniert" oder "... da ist ein Fehler ..." das immer auf den gemünzt wird, der nicht beim MSParnter ist.
Aber es wird nicht anders gehen, denke ich. Aber super, dass du geantwortet hast.
Grüße
Steffen
vielen Dank für deine Antwort. Gemeinsames Repository - dass ist die Grundlage, ja. Nur hat ein oder dieser MS-Partner die Angewohnheit, dass er sein Customizing in "seiner" App hat - so auch die Benamung. Bzw. er hat sogar zwei Customizing-Erweiterungen bei uns im System. Das Problem, das sich vermutlich nicht lösen läßt ist, dass wenn etwas "nicht mehr funktioniert" oder "... da ist ein Fehler ..." das immer auf den gemünzt wird, der nicht beim MSParnter ist.
Aber es wird nicht anders gehen, denke ich. Aber super, dass du geantwortet hast.
Grüße
Steffen
Re: BC21/22 Simultan Entwicklung MSPartner und Endkunde
13. November 2023 17:55
Der normale Weg ist, dass die ISV-App des Partners keine Anpassungen hat und alles für die Endkunden in eine oder mehrere PTEs (Per-Tenant Extension) gepackt wird, mit Dependency auf die jeweiligen ISV-Apps. An den PTEs arbeitet man dann gemeinsam am Quellcode.
Al-Go for Github hat für beides Templates: Link
On-Premises sollte man so arbeiten, bei SaaS muss man es. Eine Migration dorthin, falls die irgendwann gewünscht ist, ist also nur möglich, wenn man das voneinander trennt.
Al-Go for Github hat für beides Templates: Link
On-Premises sollte man so arbeiten, bei SaaS muss man es. Eine Migration dorthin, falls die irgendwann gewünscht ist, ist also nur möglich, wenn man das voneinander trennt.