Mit diesem Formular können Sie fehlende, unklare oder fehlerhafte Inhalte in der Dokumentation melden und Verbesserungsvorschläge machen. Ihr Feedback hilft uns, die Qualität und Vollständigkeit kontinuierlich zu verbessern.
Azure DevOps
Azure DevOps ist das zentrale Tool in der AL-Entwicklung. Für jedes Kundenprojekt werden auf der Plattform der Quellcode und alle Entwicklungsaufgaben verwaltet. Darüber hinaus werden in der Regel auch Automatisierungen wie Build- und Releasepipelines auf der Plattform gesteuert. Die verwendete Azure DevOps Organisation wird von GOB bereitgestellt und verwaltet.
Wichtig
Um einheitliche Arbeitsweisen und Zugriffe zu ermöglichen verwenden wir in allen Projekten Azure DevOps in Verwaltung durch GOB. Andere Plattformen und/oder andere Verwaltung unterstützen wir für die Abwicklung nicht. Ebenfalls unterstützen wir keine abweichende Strukturierung innerhalb des Azure DevOps Projekts. Dies betrifft die AL-Entwicklung, unbenommen bleibt weiterhin unitop4sure das Portal für das management des gesamten Projekts und beide Plattformen werden parallel eingesetzt.
Kunden- und Projektstruktur
Für jeden Kunden wird eine Azure DevOps-Organisation angelegt. Für jedes Kundenprojekt wird in der Organisation ein Projekt angelegt. Dabei entspricht die Projektstruktur nicht ggf. mehreren kaufmännischen Projekten, sondern der Kunde hat in der Regel genau ein Projekt für AL Code. Zusätzliche Projekte sind ggf. dann sinnvoll, wenn für den Kunden parallel Entwicklungsprojekte in nur lose verwandten Bereichen abgewickelt werden (z. B. ein losgelöstes Sharepoint-Projekt).
Für Kundenprojekte in Azure DevOps besteht eine Namenskonvention:
| Art | Name | Beispiel |
|---|---|---|
| Azure DevOps Organisation | [Suchbegriff/Kundenkürzel]-[Kunden-Kontaktnummer] | GOB-K11111 |
| Azure DevOps Projekt | [Suchbegriff/Kundenkürzel]-[Art] | GOB-ERP |
Repositories
In der Regel existiert in dem Kundenprojekt genau ein Repository für AL-Code. In diesem Repository werden alle Business Central Extensions entwickelt, die der Kunde von GOB erhält. Es dürfen für diesen Zweck nicht mehrere Repositories angelegt werden.
Eine Abweichung ist dann erlaubt, wenn für die Mitarbeit von Kundenmitarbeitern und/oder Partnern und durch entsprechende Abstimmung mit dem Kunden eine volle Trennung der Entwicklung beschlossen wurde. Siehe dazu auch Mitarbeit von Kunden und/oder Dritten.
Für die Ersterstellung des Repository wird ein Template verwendet. In dem Template sind bereits etliche Grundlagen enthalten. Unter anderem wird darüber die .gitignore und ein AL-Workspace-Template mitgeliefert. In diesem Template werden bereits einige zwingende Einstellungen für die AL Entwicklung mit vorgegeben und daher ist die Verwendung des Template verpflichtend.
Work Items/Aufgaben
Alle Aufgaben in Azure DevOps sind sogenannte "Work Items". Hierbei gibt es eine Reihe unterschiedlicher Typen, deren Anwendungsgebiete hier erläutert werden:
| Art | Verwendung | Hinweise | Zuständige Rolle |
|---|---|---|---|
| Epic | Die höchste Organisationsebene für Work Items. Ein Epic entspricht jeweils einer Extension. | Ein Epic bleibt dauerhaft bestehen. | PL bzw. Teil-PL |
| Feature | Einem Epic sind ein oder mehrere Features zugeordnet. Ein Feature entspricht einer Teilfunktionalität einer Extension. | Die Beschreibung eines Feature sollte den Leistungsumfang darstellen. | PL bzw. Teil-PL |
| Product Backlog Item (PBI) | PBI sind Aufgaben, die zur Herstellung oder Weiterentwicklung eines Feature erledigt werden müssen. | PBI sind die höchste Ebene, auf der Quellcodeänderungen abgewickelt werden. | PL/Teil-PL (vor Übergabe) Entwickler (nach Übergabe) |
| Bug | Ist einem Feature zugeordnet und steht auf derselben Ebene wie ein PBI. Bugs dürfen von allen Projektbeteiligten angelegt werden, die Priorisierung und die Festlegung wann er behoben werden soll liegt in der Hand des PL/Teil-PL. | Soll die folgenden Informationen enthalten:
|
PL/Teil-PL (vor Übergabe) Entwickler (nach Übergabe) |
| Task | Unterteilen ein Product Backlog Item oder einen Bug in einzelne Arbeitsschritte, um den Programmierer bei der Entwicklung zu führen. | Tasks werden vom Entwickler selbst angelegt und definiert. Je nach Gesamtaufwand des übergeordneten Work Item kann es viele oder gar keine Tasks geben. | Entwickler |
Der PL/Teil-PL stellt mit Epics und Features die verschiedenen Extensions mit ihrem jeweiligen Leistungsumfang dar. Über neue angelegte PBI definiert er Arbeitspakete, die von den Entwicklern umgesetzt werden.
Ein Entwickler verwendet Tasks um ihm zugewiesenen PBI oder Bugs in für ihn sinnvolle Arbeitspakete zu unterteilen. Die Anlage von Branches kann je PBI bzw. Bug Task erfolgen. In komplexeren Fällen kann aber auch ein Branch je Task angelegt werden. Letzteres dient z. B. dazu größere PBI bei Bedarf auf mehrere Entwickler oder mehrere Entwicklungsschritte aufzuteilen.
Es ist zwingend erforderlich für eine Entwicklungstätigkeit ein passendes Work Item in Azure DevOps zu verwenden. Entwicklung rein in Branches ohne Zuordnung zu einem Work Item ist technisch möglich, aber nicht gestattet. Der für die Entwicklung führende Branch ist mit Policies versehen, die die Verknüpfung mit einem Work Items erzwingen. Siehe dazu auch die Seite zu git.
Hinweis
Die Struktur von Work Items und deren Abarbeitung ist entscheidend für den reibungslosen Ablauf in der Entwicklung! Entwicklungsaufgaben sollten nie mehr als einige wenige Tage erfordern. Größere Arbeiten sind entweder in einzelne Work Items aufzuteilen oder wenigstens in Tasks herunterzubrechen. Die Bearbeitung mehrerer Work Items in einem Branch ist möglichst zu vermeiden, da die klare Zuordnung zu git Branches aufgeweicht wird und die Handhabung der Pull Requests im Lebenszyklus einer Entwicklungsarbeit erschwert wird. Siehe auch git merge fast, merge often
Teams
In Azure DevOps werden Projektbeteiligte für fast alle Belange der täglichen Arbeit in Teams unterteilt. An den Teams hängen jeweils die Organisation und Bearbeitung der Work Items und zusätzlich weitere Teile des Berechtigungssystems. Zusammen mit den Areas (s. u.) wird gesteuert wie der Lebenszyklus konkreter Aufgaben abläuft.
Für Kundenprojekte wird normalerweise jeweils ein allgemeines Team eingerichtet und verwendet. Dies ist dann ausreichend, wenn nur generell für das Projekt berechtigte GOB-Mitarbeiter für den Kunden tätig sind.
Sobald der Kunde selber und/oder Dritte mitarbeiten, müssen ggf. detailliertere Teamstrukturen und entsprechende Berechtigungen eingerichtet werden. Dies erfolgt in Abstimmung mit dem Kunden. Siehe dazu auch Mitarbeit von Kunden und/oder Dritten.
Areas
Zu den unterschiedlichen Work Items in Azure DevOps gehört zum einen eine durchgängige Klassifizierung als auch eine Zuordnung zu den zuständigen Teams.
Die Klassifizierung erfolgt über sogenannte Area Paths, die dann Work Items auf der einen Seite und Teams auf der anderen Seite zugewiesen werden können. Für Kundenprojekte wird keine einheitliche Vorgabe gemacht, ob und wie mit Areas zu arbeiten ist.