konsistente Versionsverwaltung / Merging?

Hallo liebe NAV-Gemeinde,

wir sind auf der Suche nach "der" Lösung zur konsistenten Verwaltung von Updates unseres Systems.
[NOTE]: Wir sind nicht auf der Suche nach Versions-Dokumentation in Objekten oder ausserhalb,
dies wird für unsere Zwecke bereits gut abgedeckt.

Wir benutzen 2 Server und 3 Datenbanken (DEV, TEST und LIVE) und es ist jedes mal sehr mühsam
einen korrekten und konstistenten Stand zwischen wenigstens 2 Systemen einzuspielen.
Gerne schilder ich euch die "Arbeit" die uns - und bestimmt vielen Anderen auch - auf die Füße fällt.

Im DEV-System wird selbstverständlich entwickelt, sprich, wir arbeiten ERP-Tickets ab, testen die
Funktionalität und schieben einen Teil von FOB-Paketen nach Absprache mit der Test-Abteilung
in unser TEST-System.
Selbstverständlich gibt es dort immer etwas auszusetzen, somit erstellen wir Bugfixes als txt-files
im TEST-System.
Sind die Tests abgeschlossen, schieben wird alle Pakete, inklusive Bugfixes von TEST nach LIVE.
Daraufhin folgt ein kompleter Vergleich zwischen TEST und LIVE, und gegebenenfalls muss noch
die ein oder andere Codestelle gemerged werden.

Erst dann können wir unser TEST-System wieder mit DEV-Paketen speisen.

Probleme bereiten uns vorallem die Bugfixes, da wir sie theoretisch ewig mit transportieren,
da sie bei der nächsten Welle von DEV nach TEST, im TEST, eventuell wieder "verloren" gehen
könnten...
_______________________________________

Ich habe bereits einiges über den Object Manager (Advanced) lesen dürfen..
aber wie es so oft ist,.. keine "Ressourcen" für solch eine Anschaffung verfügbar..
Somit fallen teure externe Tools weg.

Ich freue mich schon über eure Vorschläge oder Erfahrungsberichte.

Beste Grüße,

NAV-0-MAT

Hallo,

ja das klingt alles gut bekannt. Bei uns benutzen wir eine Kombination aus OpenSource - Produkten:

- Subversion Server auf Linux (wird gehostet über Apache und Anbindung an unser Windows AD - keine Ahnung wie)
- TortoiseSVN auf dem Entwicklungsrechner
- NAVObjectSplitter als Split /Join Tool
- Eine Reihe an schnöden .cmd Dateien für Dateioperationen
- FreeCommander als Kommandozentrale
- Eingebunden in Jira als Ticket-System, gekoppelt mit Confluence für größere Dokumentationen

In Subversion haben wir mehrere Teil-Repositories für Entwicklung (/dev/trunk), Test (/test/trunk), Produktion (/prod/trunk), und Monatsversionen (/prod/branches/Versionsname). Das ganze basiert auf den Text-Objekten.

Das arbeiten damit erfordert einiges an Disziplin, funktioniert aber ziemlich gut. Man kann Änderungen pro Ticket/Revision selektieren und in andere Bäume / Revisionen mergen, und alle Änderungen nachvollziehen.

Im privaten/freiberuflichen benutze ich den fast gleichen Setup (kein integriertes Jira), und ich benutze seit mehr als einem Jahr Mercurial statt Subversion. Die Arbeitsweise in Mercurial ist etwas anders, aber meiner Meinung nach eindeutig das leistungsfähigere System. Das mit der Disziplin gilt auch hier, es ist aber fehlertoleranter, und das Mergen von Änderungen quer über alle Bäume und NAV-Versionen (mein AddOn 2009R2 auf z.B. Kundendatenbank basierend auf NAV2013R2 mit ggf. anderen Sprachschichten) und zurück funktioniert auch relativ gut, besser als in Subversion.

Beim neu aufsetzen so eines Systems würde ich wohl zu Mercurial oder Git als Versionsmanagement raten. Eines haben all diese Systeme aber gemeinsam: Sie gehen über die Textdatei, man braucht also eine entsprechende Lizenz die es erlaubt Objekte als .txt zu importieren.

LG Jens

hi,

es gibt die OMA Tools von Idyn (Partnerlizenz 4000,-, Customer etwa 1000) und IFacto (etwa 3000,- für Partner) als "echte" Nav Versionsverw.tools.
Eventuell gäbs noch NavUtils/Navrepository, ist aber schon älter.

Sollen nur die exportieren Objekte (txt/fob) verwaltet werden ist die auswahl nat. größer.
Subversion ist sicher eine gute wahl.

so oder so ist viel diszplin erforderlich. dann noch die laufende dokumentation, ... naja

best regards

ps.: anbindung von linux ans windows AD geht über den Samba Server.

Moin,

wie sieht es mit dem TFS aus? Der hat eigentlich alle Möglichkeiten drin.

BG defiant701

Ich glaube, die Frage richtet sich weniger an das bzw. die Tool(s) als an den Prozess. Tools können da sicherlich unterstützen und auch die ein oder andere Kurve im Prozess leichter bzw. effektiver gehen, aber im Grundsatz muss erst einmal der Prozess klar sein. Dass sich dann nachher Teile des Prozesses durch den Einsatz von bestimmten Tools ändern können, ist auch klar, aber das kann man dann sicherlich betrachten, wenn entsprechend Budget vorhanden ist bzw. wenn man eine Kosten-Nutzen-Analyse zur Einführung eines solchen Tools machen kann. Das geht aber nur, wenn vorher der Prozess klar ist.

Aus meiner Sicht macht ihr hier einen entscheidenden Fehler: Ihr entwickelt in der Testdatenbank. Ich weiß, es ist manchmal hart, sich dazu zu zwingen jetzt doch wieder die Datenbank zu wechseln und einen ordentlichen Release-Prozess anzustoßen, besonders wenn es sich nur um eine "Kleinigkeit" handelt. Aber leider ist das nach meinem Dafürhalten die einzige Möglichkeit nachträgliche Schmerzen zu vermeiden.

Evtl. würde euch auch noch eine klare Arbeitsorganisation weiterhelfen. Damit meine ich, es sollte festgehalten und veröffentlicht werden, in welchen Abständen und zu welchen Terminen welche Entwicklungsanforderungen umgesetzt werden. Neuanforderungen werden ab einem gewissen Zeitpunkt eben nicht mehr schnell noch in das aktuelle Release integriert, nur weil es "dringend" ist.

Da kann es natürlich noch mehr geben, was man verbessern könnte, aber dafür müsste man sich eure Prozesse mal im Detail ansehen. Vieles kann man aus der Ferne einfach nicht sagen.