4
Versionierungstool für Softwareentwicklung
Hallo zusammen,
ich wurde damit betraut eine Versionierungssoftware für unsere Softwareentwicklungsteam zu finden, leider überhaupt nicht mein Gebiet.
Kurz umschrieben:
Wir sind ein CNC-Machinenhersteller, der unter anderem unsere Steuerungen auf Basis Heidenhain und Siemens entwickeln bzw. parametrieren.
Ca. 5 Personen die entwickeln, div. schauen sich die Quelltexte an.
Haben uns TortoiseSVN angeschaut, das war uns/denen zu umständlich. Haben uns eine Lösung von Auvesy angeschaut - die ist m.E. zu groß. Es soll ein einfaches Tool sein.
Im CAD-Bereich haben wir DBWorks (Mechworks), welches recht einfach gestrickt ist. So hätten wir`s auch in der Softwareentwicklung gerne. Leider können wir DBworks (läuft auf MSSQL) dafür nicht nutzen.
Hier ist es so: Teil/Zeichnung auschecken, derjenige kann nur bearbeiten, alle anderen reinschauen und bekommen den Hinweis: ausgecheckt von Mr. X.
Im CAD sind es jedoch einzelene Zeichnungen und Dateien bzw. Baugruppen. Bei der Software sind das Verzeichnisse in dem div. Module halt zusammen gehören.
Hat hier jemand anregungen bzw. Ideen was wir uns noch mal anschauen sollten?
Gerne etwas, welches über ein SQL-Server läuft!!
Oder kennt ihr Beratungshäuser, die mehrere Lösungen vertreiben und uns beraten könnten?
Vielen Dank für gute Anregungen/Lösungen!
greetz
ravers
P.S.: Suchfunktion schon genutzt, jedoch alles recht alte Beiträge!
ich wurde damit betraut eine Versionierungssoftware für unsere Softwareentwicklungsteam zu finden, leider überhaupt nicht mein Gebiet.
Kurz umschrieben:
Wir sind ein CNC-Machinenhersteller, der unter anderem unsere Steuerungen auf Basis Heidenhain und Siemens entwickeln bzw. parametrieren.
Ca. 5 Personen die entwickeln, div. schauen sich die Quelltexte an.
Haben uns TortoiseSVN angeschaut, das war uns/denen zu umständlich. Haben uns eine Lösung von Auvesy angeschaut - die ist m.E. zu groß. Es soll ein einfaches Tool sein.
Im CAD-Bereich haben wir DBWorks (Mechworks), welches recht einfach gestrickt ist. So hätten wir`s auch in der Softwareentwicklung gerne. Leider können wir DBworks (läuft auf MSSQL) dafür nicht nutzen.
Hier ist es so: Teil/Zeichnung auschecken, derjenige kann nur bearbeiten, alle anderen reinschauen und bekommen den Hinweis: ausgecheckt von Mr. X.
Im CAD sind es jedoch einzelene Zeichnungen und Dateien bzw. Baugruppen. Bei der Software sind das Verzeichnisse in dem div. Module halt zusammen gehören.
Hat hier jemand anregungen bzw. Ideen was wir uns noch mal anschauen sollten?
Gerne etwas, welches über ein SQL-Server läuft!!
Oder kennt ihr Beratungshäuser, die mehrere Lösungen vertreiben und uns beraten könnten?
Vielen Dank für gute Anregungen/Lösungen!
greetz
ravers
P.S.: Suchfunktion schon genutzt, jedoch alles recht alte Beiträge!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 307382
Url: https://administrator.de/forum/versionierungstool-fuer-softwareentwicklung-307382.html
Ausgedruckt am: 23.12.2024 um 18:12 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
Hab ich zwar noch nicht getestet aber der Team Foundation Server von MS?
Hab ich zwar noch nicht getestet aber der Team Foundation Server von MS?
Hallo,
wenn ihr mit Visual Studio arbeitet gibt es zum MS Team Foundation Server keine Alternative was die Integration angeht. Und bis 5 User ist das ganze sogar gratis.
Für alles andere macht es keinen großen Unterschied ob GIT oder Mercurial eingesetzt wird. Subversion hat sich für mich persönlich irgendwie "altbacken" angefühlt (ohne dass ich es rational begründen kann).
Für alle Systeme gibt es eine aktive Community die bei Problemen und Fragen schnell weiterhilft.
Gruß,
André
wenn ihr mit Visual Studio arbeitet gibt es zum MS Team Foundation Server keine Alternative was die Integration angeht. Und bis 5 User ist das ganze sogar gratis.
Für alles andere macht es keinen großen Unterschied ob GIT oder Mercurial eingesetzt wird. Subversion hat sich für mich persönlich irgendwie "altbacken" angefühlt (ohne dass ich es rational begründen kann).
Für alle Systeme gibt es eine aktive Community die bei Problemen und Fragen schnell weiterhilft.
Gruß,
André
Hallo ravers,
wenn ihr unbedingt eine Locking-Funktionalität für Dateien benötigt, kommt ihr um eine zentrale Versionsverwaltung (wie SVN) nicht herum. Solche Systeme nutzen einen zentralen Server, der die File Locks verwaltet. Dieser Server kann auch die Zugriffsrechte auf die Repositories über eine integrierte Benutzerverwaltung steuern.
Dezentrale Systeme wie GIT sind nicht dazu in der Lage, einzelne Dateien zu sperren, da es keinen zentralen Server gibt. Das gemeinsame Repository ist einfach ein Verzeichnis auf einem beliebigen Rechner, das zu Synchronisationszwecken z.B. über eine Samba-Freigabe, SSH, HTTP(S) oder auf anderen Wegen für die lokale GIT-Installation erreichbar ist.
Die Versionsverwaltung für eine einzelne Datei (in Eurem Fall CAD-Zeichnungen) lässt sich nicht wirklich mit der Versionsverwaltung in Softwareprojekten vergleichen. Die Komplexität in letzterem ist viel höher, entsprechend muss auch das Werkzeug dafür komplexer sein. Da hilft alles Jammern nichts, die Entwickler müssen sich damit auseinandersetzen. Bei zentralen Versionsverwaltungen sollte es am besten mindestens eine Person geben (besser zwei, wegen Krankheit, Urlaub, Kündigung usw.), die sich besonders gut mit dem jeweiligen System auskennt und den Server verwaltet.
File Locking ist m.E. kein zwingend notwendiges Feature. Durch organisatorische Maßnahmen (genaue Festlegung der Zuständigkeiten für jeden Entwickler) kann man die Fälle, wo zwei Entwickler an der gleichen Quellcodedatei arbeiten, auf ein Minimum reduzieren. Auch die Modularität des Codes spielt für eine gut funktionierende Versionsverwaltung eine große Rolle. Wenn eine kleine Änderung in einer Quellcodedatei sofort auch Änderungen in anderen Quellcodedateien notwendig macht, stimmt die Struktur des Codes nicht, die Verzahnung der Quellcodebereiche ist dann zu stark. Es ist allerdings schon so, dass diese Ratschläge erst ab einer gewissen Projektgröße wirklichen Nutzen haben. In kleinen Projekten passiert es natürlich viel eher, dass zwei Entwickler an der gleichen Datei arbeiten, dann wird File Locking interessant.
Sollte trotzdem der Fall auftreten, dass zwei Entwickler die gleiche Quellcodedatei ändern mussten, muss der Entwickler, der als letztes eincheckt, den Code mergen. Dazu benötigt man zunächst mal ein gutes Merge-Tool. Zusätzlich muss der Entwickler über ausreichend Erfahrung und Applikationswissen verfügen, um die Änderungen sauber integrieren zu können. Dafür kann ebenfalls ein Spezialist erforderlich sein bzw. die beiden ändernden Entwickler müssen bei einer Merge-Session zusammenarbeiten. Beachtet man obige Ratschläge (Festlegung von Zuständigkeiten und Modularität der Software), ist der Aufwand aber meistens minimal und von jedem beteiligten Entwickler zu leisten.
Weiterhin ist es noch wichtig, sich eine gewisse Sorgfalt beim Umgang mit den Quellcodedateien anzugewöhnen, um das Versionsverwaltungssystem nicht zu verwirren. Für SVN gilt: Eine neue Datei zur Versionierung hinzuzufügen oder eine bestehende Datei zu ändern und danach zu löschen (ohne vorheriges Einchecken) führt garantiert zu Problemen (Stichwort Tree Conflict). Vor dem Löschen sollte man immer den Ausgangszustand wieder herstellen (neue Datei aus der Versionierung herausnehmen bzw. ein Revert der geänderten Datei ausführen) und dann erst löschen. Zum Löschen auch nicht einfach die normale Löschfunktion der Benutzeroberfläche verwenden sondern die Löschfunktion des Versionsverwaltungssystems.
Als Versionsverwaltungssystem nutzen wir SVN und den TortoiseSVN-Client (bietet Integration der SVN-Funktionalitäten in das Kontextmenü des Windows Explorers) und als Diff- und Merge-Tool BeyondCompare in der Pro-Version, nur diese ist merge-fähig. Es gibt aber auch noch andere gute Tools für diesen Zweck. Das in TortoiseSVN integrierte Diff- und Merge-Tool ist bei uns nicht so beliebt. Eine Vergleichsmatrix für verschiedene Diff- und Merge-Tools findet sich z.B. hier.
Gruß
Friemler
wenn ihr unbedingt eine Locking-Funktionalität für Dateien benötigt, kommt ihr um eine zentrale Versionsverwaltung (wie SVN) nicht herum. Solche Systeme nutzen einen zentralen Server, der die File Locks verwaltet. Dieser Server kann auch die Zugriffsrechte auf die Repositories über eine integrierte Benutzerverwaltung steuern.
Dezentrale Systeme wie GIT sind nicht dazu in der Lage, einzelne Dateien zu sperren, da es keinen zentralen Server gibt. Das gemeinsame Repository ist einfach ein Verzeichnis auf einem beliebigen Rechner, das zu Synchronisationszwecken z.B. über eine Samba-Freigabe, SSH, HTTP(S) oder auf anderen Wegen für die lokale GIT-Installation erreichbar ist.
Die Versionsverwaltung für eine einzelne Datei (in Eurem Fall CAD-Zeichnungen) lässt sich nicht wirklich mit der Versionsverwaltung in Softwareprojekten vergleichen. Die Komplexität in letzterem ist viel höher, entsprechend muss auch das Werkzeug dafür komplexer sein. Da hilft alles Jammern nichts, die Entwickler müssen sich damit auseinandersetzen. Bei zentralen Versionsverwaltungen sollte es am besten mindestens eine Person geben (besser zwei, wegen Krankheit, Urlaub, Kündigung usw.), die sich besonders gut mit dem jeweiligen System auskennt und den Server verwaltet.
File Locking ist m.E. kein zwingend notwendiges Feature. Durch organisatorische Maßnahmen (genaue Festlegung der Zuständigkeiten für jeden Entwickler) kann man die Fälle, wo zwei Entwickler an der gleichen Quellcodedatei arbeiten, auf ein Minimum reduzieren. Auch die Modularität des Codes spielt für eine gut funktionierende Versionsverwaltung eine große Rolle. Wenn eine kleine Änderung in einer Quellcodedatei sofort auch Änderungen in anderen Quellcodedateien notwendig macht, stimmt die Struktur des Codes nicht, die Verzahnung der Quellcodebereiche ist dann zu stark. Es ist allerdings schon so, dass diese Ratschläge erst ab einer gewissen Projektgröße wirklichen Nutzen haben. In kleinen Projekten passiert es natürlich viel eher, dass zwei Entwickler an der gleichen Datei arbeiten, dann wird File Locking interessant.
Sollte trotzdem der Fall auftreten, dass zwei Entwickler die gleiche Quellcodedatei ändern mussten, muss der Entwickler, der als letztes eincheckt, den Code mergen. Dazu benötigt man zunächst mal ein gutes Merge-Tool. Zusätzlich muss der Entwickler über ausreichend Erfahrung und Applikationswissen verfügen, um die Änderungen sauber integrieren zu können. Dafür kann ebenfalls ein Spezialist erforderlich sein bzw. die beiden ändernden Entwickler müssen bei einer Merge-Session zusammenarbeiten. Beachtet man obige Ratschläge (Festlegung von Zuständigkeiten und Modularität der Software), ist der Aufwand aber meistens minimal und von jedem beteiligten Entwickler zu leisten.
Weiterhin ist es noch wichtig, sich eine gewisse Sorgfalt beim Umgang mit den Quellcodedateien anzugewöhnen, um das Versionsverwaltungssystem nicht zu verwirren. Für SVN gilt: Eine neue Datei zur Versionierung hinzuzufügen oder eine bestehende Datei zu ändern und danach zu löschen (ohne vorheriges Einchecken) führt garantiert zu Problemen (Stichwort Tree Conflict). Vor dem Löschen sollte man immer den Ausgangszustand wieder herstellen (neue Datei aus der Versionierung herausnehmen bzw. ein Revert der geänderten Datei ausführen) und dann erst löschen. Zum Löschen auch nicht einfach die normale Löschfunktion der Benutzeroberfläche verwenden sondern die Löschfunktion des Versionsverwaltungssystems.
Als Versionsverwaltungssystem nutzen wir SVN und den TortoiseSVN-Client (bietet Integration der SVN-Funktionalitäten in das Kontextmenü des Windows Explorers) und als Diff- und Merge-Tool BeyondCompare in der Pro-Version, nur diese ist merge-fähig. Es gibt aber auch noch andere gute Tools für diesen Zweck. Das in TortoiseSVN integrierte Diff- und Merge-Tool ist bei uns nicht so beliebt. Eine Vergleichsmatrix für verschiedene Diff- und Merge-Tools findet sich z.B. hier.
Gruß
Friemler
1
Moin zusammen!
Vielen Dank für eure z.T. ausführlichen Aussagen. Top!
TFS hab ich mir angeschaut, ist wohl primär für VisualStudio. Das nutzen wir nicht, und zum Thema Erweiterungen finde ich nicht viel. Primär S7-Projekte, WinCC, Schneider-Umrichter, Heidenhain und (vernachlässigbar) einige mehr.
Als Anforderung kam eigentlich nur das zentrale Management. Wobei selbst diese Anforderung evtl. zu hinterfragen ist.
Der Grund dieser Aufgabe war halt das verschiedene Entwickler die gleichen Quelldateien bearbeitet haben und dadurch größerer Schaden angerichtet wurde. Dies gilt es nun (bestmöglich) zu unterbinden.
Von daher kommt SVN wohl in die engere Auswahl.
Problem, welches ich gelesen habe, ist das Siemens S7-Projekte wohl etwas anders gehändelt werden. Hier soll es mit SVN etwas umständlich sein? Kann mir dazu jemand was sagen? (Werd mir die S7-Projekte mal genauer anschauen wie die aufgebaut sind)
Versionsdog ist dort wohl die "Eierlegende Wollmilchsau", haben wir uns auch angeschaut. Sah soweit sehr gut aus, jedoch m.E. etwas überladen. Da ich aber kein Entwickler bin mag ich mich da auch täuschen. Preislich aber auch nicht grad ein Schnapper.
Kennt bzw. arbeitet jemand mit Versionsdog? - und kennt vielleicht jener auch SVN und kann mir zu den unterschiedlichen Arbeitsweisen was erzählen?
Den TortoiseSVN-Client haben wir uns schon mal angeschaut, kam aber nicht gut an. Aber hier gibt`s ja noch alternativen, die könnte man sich ggf. anschauen.
greetz
ravers
Vielen Dank für eure z.T. ausführlichen Aussagen. Top!
TFS hab ich mir angeschaut, ist wohl primär für VisualStudio. Das nutzen wir nicht, und zum Thema Erweiterungen finde ich nicht viel. Primär S7-Projekte, WinCC, Schneider-Umrichter, Heidenhain und (vernachlässigbar) einige mehr.
Als Anforderung kam eigentlich nur das zentrale Management. Wobei selbst diese Anforderung evtl. zu hinterfragen ist.
Der Grund dieser Aufgabe war halt das verschiedene Entwickler die gleichen Quelldateien bearbeitet haben und dadurch größerer Schaden angerichtet wurde. Dies gilt es nun (bestmöglich) zu unterbinden.
Von daher kommt SVN wohl in die engere Auswahl.
Problem, welches ich gelesen habe, ist das Siemens S7-Projekte wohl etwas anders gehändelt werden. Hier soll es mit SVN etwas umständlich sein? Kann mir dazu jemand was sagen? (Werd mir die S7-Projekte mal genauer anschauen wie die aufgebaut sind)
Versionsdog ist dort wohl die "Eierlegende Wollmilchsau", haben wir uns auch angeschaut. Sah soweit sehr gut aus, jedoch m.E. etwas überladen. Da ich aber kein Entwickler bin mag ich mich da auch täuschen. Preislich aber auch nicht grad ein Schnapper.
Kennt bzw. arbeitet jemand mit Versionsdog? - und kennt vielleicht jener auch SVN und kann mir zu den unterschiedlichen Arbeitsweisen was erzählen?
Den TortoiseSVN-Client haben wir uns schon mal angeschaut, kam aber nicht gut an. Aber hier gibt`s ja noch alternativen, die könnte man sich ggf. anschauen.
greetz
ravers
