[gelöst]BC18: Extension mit mehreren Entwicklern

Hi allerseits,

das ist wahrscheinlich eine eher profane Frage. Das Problem hattet ihr wahrscheinlich alle irgendwann:

Bisher habe ich als einziger Entwickler an Dynamics gearbeitet. Jetzt kommt ein Kollege hinzu. Wie kriegen wir das hin, an einer Extension gleichzeitig zu arbeiten, ohne uns gegenseitig zu behindern?

Im alten Navision hat der jeweilige Entwickler das Objekt in der Version-List mittels seines Kürzels gesperrt.

Wenn wir gemeinsam im gleichen Projekt-Verzeichnis arbeiten, wie kriegen wir es hin, dass wir uns nicht gegenseitig den Code zerschießen? Zusätzlich gibt es das Problem, dass ja jedes mal die gesamte Extension kompiliert wird (im alten Navision wurde das auf Objekt-Ebene gemacht). Wenn also ein Objekt eines Entwicklers fehlerhaften Code enthält, dann kann der andere Entwickler die Extension nicht kompilieren, bis der fehlerhafte Code bereinigt ist.
Ergo scheint es besser, dass jeder Entwickler in einer eigenen Umgebung in einem eigenen Projekt-Verzeichnis mit einer eigenen Datenbank arbeitet.

Wenn wir in jeweils eigenen Projekt-Verzeichnissen arbeiten, wie kriegen wir das dann am besten ohne viel manuellen Aufwand zusammengeführt? Wie kriegen wir es hin, dass wir nicht die gleichen Objektnummern parallel vergeben?

Welche Konzepte wendet ihr so an?

Zuletzt geändert von elf am 1. November 2021 17:56, insgesamt 1-mal geändert.

Um im Team Kollisionen bei Object-IDs zu vermeiden, gibt es seit kurzem diese App.

danke Kowa, Object ID Ninja sieht gut und vielversprechend aus, um die Doppelvergabe von Object-IDs zu verhindern. Erschlägt aber nur einen kleinen Teil unseres Problems.

Wenn wir gemeinsam im gleichen Projekt-Verzeichnis arbeiten, wie kriegen wir es hin, dass wir uns nicht gegenseitig den Code zerschießen?

Das übliche Verfahren für alles andere läuft über ein gemeinsames Repository, meist verwaltet durch Git, samt Branches, Forks, Merge, Commits, Fetch, Pull requests usw. etc. pp².
Dokumentation zu Azure Repos Git
Git
GUI Clients für GIT
GitHub Desktop

Git - Book (git-scm.com)
Git Tutorial
AL Code Management with GIT (Part 1)
What are the differences between git branch, fork, fetch, merge, rebase and clone?
Using the Fork-and-Branch Git Workflow
git: fetch and merge, don’t pull
How To Resolve Merge Conflicts in Git, ein externes Tool dazu mit besserer GUI ist z.B. Meld (mit Integration für Git)
Tip: List-Commits

Extensions zu Git für VSC
Integriert: Using Git source control in VS Code

• GitLens
• Git Graph
• Git History

GIT.png

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Git for the win

ok, dann werden wir uns mit git beschäftigen

Hallo,

Ich denke, das was Edgar meint, ist die gemeinsame Entwicklung in einem Projekt.

D.h. einer kümmert sich um die Berichte, einer um das Pagedesign und jemand andres um die Schnittstellen nach außen. Aber alles basierend auf einer gemeinsamen Codebasis also nur einer App/Addon.
Spricht man das sauber ab, bekommen sich die Entwickler auch wenn Sie in einer C/SIDE- Datenbank arbeiten, nicht in die Quere.
Da hilft dir auch Git nicht weiter, weil es erst greift, wenn etwas schon fertig ist. Das ist es in diesem Fall aber nicht, weil alle parallel am gleichen Code arbeiten, also quasi alle im gleichen Visualstudio-Code, nur das jeder nur seinen Teil macht und auch testet.
Da man in AL aber die App immer nur komplett publishen kann, wird das für Tests nun zu einem Problem. Die einzige Option ist hier alle alle Arbeiten in unterschiedliche Apps pro Entwickler aufzuteilen, was dann aber wieder Probleme mit den Abhängigkeiten der Projekte untereinander schafft.

Das alles war mit NAV bisher kein wirkliches Problem wenn man sich auch absprechen musste.

Gruß Fiddi

Da hilft dir auch Git nicht weiter, weil es erst greift, wenn etwas schon fertig ist. Das ist es in diesem Fall aber nicht, weil alle parallel am gleichen Code arbeiten,

Natürlich hilft das weiter. Dafür gibt es ja Branches, Forks (nur bei GitHub), Clones usw. Alle Entwicklerteams haben diese potentiellen Konflikte grundsätzlich in allen Projekten, unabhängig von der Programmiersprache, und Git hat nicht ohne Grund mittlerweile die anderen Codeverwaltungstools weitgehend verdrängt.

Ich würde sogar empfehlen, selbst wenn man nur alleine entwickelt, sich intensiv damit zu beschäftigen und jedes Projekt damit zu verwalten. Sonderlich intuitiv finde ich Git nicht, und den Umgang damit lernt man auch nicht von heute auf morgen, aber der Aufwand zahlt sich in langfristigen Projekten immer aus.

Hallo,

Ich würde sogar empfehlen, selbst wenn man nur alleine entwickelt, sich intensiv damit zu beschäftigen und jedes Projekt damit zu verwalten. Sonderlich intuitiv finde ich Git nicht, und den Umgang damit lernt man auch nicht von heute auf morgen, aber der Aufwand zahlt sich in langfristigen Projekten immer aus.

Da bin ich voll bei dir, ist aber glaube ich nicht was er möchte.

Denn jeder muss im Grunde für sich alleine arbeiten. Der Austausch findet dann nur über den Quellcode statt, und man muss dann laufend das Projekt zwischen den Arbeitsplätzen synchronisieren, und wie mache ich das mit dem publishen?
Da alle an der gleichen App arbeiten, wird das mit dem publishen unterschiedliche Stände der gleichen App in die gleiche Datenbank wohl ein Problem. Oder verstehe ich da was falsch?

Gruß fiddi

Ich denke, das was Edgar meint, ist die gemeinsame Entwicklung in einem Projekt.

ja, genau das ist unser Problem. Zwei Entwickler arbeiten an einer App. Da sich die Anwendungs-Bereiche nicht so ohne Weiteres in mehrere Extensions aufteilen lassen (Abhängigkeiten etc.) habe wir das so entschieden.

Wir hatten den folgenden Plan:

- es gibt ein Master-Projekt, das immer den in die Live-Datenbank gepublishten Code enthält
- jeder Entwickler hat eine eigene Kopie des Projekts. In dieser Kopie wird entwickelt
- jeder Entwickler hat eine eigene Entwicklungs-Datenbank, in der er zur Entwicklungszeit publishen und testen kann
- wenn ein Projekt/Teilbereich fertig ist, dann wird der Code in das Master-Projekt überführt und in die Live-Datenbank gepublisht
- alle Entwickler holen sich den nun neuen Master-Code in Ihre Entwicklungs-Umgebung

kann uns git dabei helfen?

Hallo,

kann uns git dabei helfen?

Ich denke schon, auch wenn ich direkt mit git noch keine Erfahrung habe, Aber jedes Versionskontrollsystem beherrscht diese Funktion eigentlich.

Aber du musst dir darüber im klaren sein, das eine Absprache über den Schreibtisch: "Bau mal eben dieses Feld ein, ich möchte mal eben was testen" oder "ich habe den Inhalt von Feld XYZ geändert, du musst mal probieren, ob das bei dir nicht zu Problemen führt", wie du es in NAV gewöhnt warst, deutlich komplizierter wird.
Und auch die Reibungsverluste durch den notwendigen Merge zwischen den beiden Quellcodes, sofern sie sich überschneiden, solltest du nicht unterschätzen.

Gruß Fiddi

kann uns git dabei helfen?

Sicherlich, aber nur bei der Quellcodeverwaltung. Für das Deployment muss man leider für Extensions, egal was man plant oder machen muss, immer ein "Fass aufmachen", sei es lokal oder in der Cloud.
Sinnbildlich: https://twitter.com/JeremyVyska/status/1376525187462598660/
Waldo hat hier einiges dazu geschrieben:
DevOps Build Agents for Microsoft Dynamics 365 Business Central
Deploying from DevOps the right way: enabling External Deployment in OnPrem Business Central environments
Deploying from DevOps the right way (Part 2): Deploying to OnPrem Business Central environments with the automation API

[Nachtrag 2022] neues kostenloses DevOps-System von MS: AL-Go for GitHub

Kleine Einführung zum Arbeiten mit DevOps und Git
DevOps and Business Central

Artikel zum Branching
Managing Business Central Development with Git: Branching Strategy
Branching Workflow – CI / CD Part 6
Inside Git: Branches
Videolink dazu: Inside Git: Branches (aus YT Channel Vjeko Live)

Pipelines
DevOps Pipeline

In diesem Video von der letzten DynamicsCon erläutert Waldo, wie er sein Team organisiert.
How I Manage My Team for Product and Customer Development?

vielen Dank für diesen Link, das sieht vielversprechend aus...

Hallo,

das trifft es ziemlich genau.
Das Problem ist nur, das es jemanden braucht, der einschätzen kann was sinnvoll ist.

Bestimmte Dinge sollte man grundsätzlich lösen. Das ist auf die Dauer oft einfacher, fehlerfreier und flexibler ist, als eine Speziallösung zu schreiben wie z.B. Schnittstellen zu externen Systemen. (wird aber gerne vom Kunden gewünscht.)

Andererseits ist ein angepasstes Report- Layout oder eine Kundenauswertung für mich kein Grund ein Riesen- Projekt aufzusetzen.

Gruß fiddi

ja, das trifft es ganz gut. Man muss immer gut überlegen, ob man mit Kanonen auf Spatzen schießt, oder mit Pfeil und Bogen Drachen erlegen will.

Andererseits ist ein angepasstes Report- Layout oder eine Kundenauswertung für mich kein Grund ein Riesen- Projekt aufzusetzen.

Auch wenn es nur eine kleine Anpassung ist, muss man ja immer damit rechnen, dass jemand anderes die Arbeit fortführen muss, sei es nun zeitweilig wegen Urlaub oder Krankheit, oder permanent. Bei C/AL hat man die Objekte immer in der jeweiligen Datenbank, wo sie wirksam sind, und kann sich mit Datumsfilter usw. zumindest grob orientieren.
Bei AL weiß man im schlimmsten Fall noch nicht einmal, wo der aktuelle Quellcode für die App liegt. Deswegen ist ein Repository jetzt im Gegensatz zu früher viel wichtiger und sollte nach einem einheitlichen Schema verwaltet werden.

Katzenvideos haben wir hier ja nicht, aber hier wird die Arbeitsweise von Git mit Hilfe von vielen Katzen erläutert .