Revisionssystem einführen

[ThYpHoOn]

Moin,

ich programmiere derzeit Beruflich in einer kleinen Softwareschmiede mit ca. 6 Programmierern. Wir haben im Prinzip mehrere von einander unabhängige Projekte + (gemeinsame) Library - wir arbeiten alle auf Delphi5 als IDE. Das "Merging" passiert derzeit händisch ohne feste Zeiten, dann wenn es eben für ein hotfix benötigt wird o.ä. in dem man in einem Netzwerkordner entsprechend die neuen Sourcen rein schiebt und diese dann per Vergleichsprogramm gemerged (das Tool was bei Total Commander dabei ist - ALT+D+V).

Das diese Methode Chaos mit sich bringt bzw. recht unproduktiv ist sollte eigentlich klar sein und ich habe mich privat auch schon des öfteren mit SVN sowie Mercurial beschäftigt. Da ich diesen Zustand schon länger bemängelt habe und seit knapp einem Jahr einen Vortrag über die Vorteile von SVN rumliegen habe der aber nicht angesehen werden möchte von den entscheidenden Leuten wollte ich Euch zum einen fragen was Ihr für Revisionssysteme produktiv (kommerziell) einsetzt und wie man die Chefs am besten dazu überredet bekommt so etwas einzuführen.


Greetz, ThY

[nachti1505]

Wir benutzen SVN... hatten aber auch die Erfahrung dass das Überzeugen der BigBosses sehr mühselig ist... man könnte denen vorrechnen, wieiviel Zeit für das Mergen drauf geht (was SVN bsp. alleine macht)!

[Bummi]

Argumente eine Chef gegenüber:
1.) Datensicherung in allen (Sub)Versionsständen
2.) quasi kostenlos
3.) automatisches Mergen mit Kontrolle wer wan was geändert hat.
4.) Je nach Einrichtung und Verwaltung Zugriff von jedem Platz der Welt
5.) Kunden können, wenn dies vereinbart ist immer die aktuellsten Sourcen ziehen
6.) Einfachere Verwaltung von Branches
7.) Zeit und dadurch Kostenersparnis

[Dezipaitor]

Man sollte nicht die Technik anpreisen, sondern die Lösung. Schreib doch mal auf, wieviele und welche Probleme es gibt und wie lange es jeweils braucht, so ein Problem im Durchschnitt zu lösen (SVN Konflikte, Mergekonflikte, Buildbreaks). Dann kannst du immernoch deine Lösung präsentieren in welcher Form (SVN) auch immer. Aber bedenke, dass Werkzeuge alleine keine Lösung sind. Dazu gehören immer auch Prozesse und letztendlich Menschen. Mitarbeiter müssen überzeugt werden (wenn auch von oben), dass dies auch sinnvoll ist, sonst rennt man gegen geschlossene Türen. Welche Prozesse/Vorgehensmodelle nutzt ihr überhaupt? Wasserfallmodell? Extreme Programming? Gibt es einen Ablauf für ein Fix-Commit-Test Zyklus? Wie wird getestet? uvm.

Letztendlich wird es DIE Lösung wohl garnicht geben. Es ist daher immer sehr sinnvoll die derzeitigen Strukturen und Abläufe in der Firma zu analysieren und darauf aufzubauen oder sie anzupassen. Grundlegend alles zu ändern ist sehr schwierig und kann auch nach hinten losgehen. Kleine Veränderungen, die gut propagiert werden helfen da oft vielmehr, besonders wenn die Leute begeistert mitmachen.

Weiterführende Literatur (habe ich auch):

Software Engineering, Jochen Ludewig et al., dpunkt.verlag
Lehrbuch der Softwaretechnik, Helmut Balzert, Spektrum
Abenteuer Software Qualität, Kurt Schneider, dpunkt.verlag
Managment von Softwareprojekten, Andreas Henrich, Oldenbourg

[ThYpHoOn]

Vielen Dank schon mal für Euer Feedback.

Das Vorrechnet ist denke ich mal vor allem für die BWL'ler wichtig, die wollen nun mal meistens nur die "nackten" Zahlen. Das kann ich aber auch nur rudimentär, ein Semester BWL auf der Uni hat mir gereicht, ich bin Programmierer Aber ich denke für eine kleine Tabelle mit Zeit bzw. Arbeitsstunden die pro Woche drauf gehen sowie den Konflikten wenn z.b. unser "Maintainer" krank ist bzw. Urlaub hat (und die aktuellsten Sourcen auf dem Laptop auch physisch nicht vor Ort sind) hatten wir schon öfters die Situation keine aktuelle Version, trotz kritischer Bugs, zu deployen.

Ich werde es auch denke ich erst mal allgemein halten, muss aber dann sicherlich auch konkretisieren und entsprechende Vorschläge bringen, da ist es natürlich wie Dezipaitor schon sagte immer sehr individuell. Ich fokusiere im Moment Mercurial an, da es doch am einfachsten zu verstehen ist und vor allem mit TortoiseHG ein Windows-Gui gibt womit man recht intuitiv arbeiten kann (sofern man das System dahinter verstanden hat). Mal schauen ob ich mir noch ein passendes Software-Engineering Buch kaufe, danke für die Buchempfehlungen!


Greetz, ThY

[Phoenix]

Das Totschlagargument ist meiner Meinung nach die Sicherung und der Team-Weite Zugriff. Was, wenn einer im Team der kurz vor der Vollendung eines Features steht, plötzlich Krank wird (Autounfall, fällt für mehrere Wochen aus, Das Notebook im schlimmsten Fall im Auto dabei und nicht mehr rettbar)?

[hoika]

Hallo,

Totschlagargument
< Sicherung und der Team-Weite Zugriff >

Nein.

Das Totschlagargument ist die Nachvollziehbarkeit von Änderungen (changelog),
wer hat wann was geändert.



Heiko

[DelphiBandit]

Zitat von ThYpHoOn:

Das "Merging" passiert derzeit händisch ohne feste Zeiten, dann wenn es eben für ein hotfix benötigt wird o.ä. in dem man in einem Netzwerkordner entsprechend die neuen Sourcen rein schiebt und diese dann per Vergleichsprogramm gemerged..
..seit knapp einem Jahr einen Vortrag über die Vorteile von SVN rumliegen habe der aber nicht angesehen werden möchte von den entscheidenden Leuten wollte ich Euch zum einen fragen was Ihr für Revisionssysteme produktiv (kommerziell) einsetzt und wie man die Chefs am besten dazu überredet bekommt so etwas einzuführen.

Hört sich vom Ablauf etwas kontraproduktiv an Und fehlerträchtig, da man so sicher keine "abgeschlossene" Version zustande bekommt.

Erfahrungsgemäss ist es verlorene Liebesmüh einen Chef zu überreden etwas Neues einzuführen. Es hilft imho auch nichts, wenn mal wieder eine Version "buggy" gemerged wurde anzumerken, mit einer Versionskontrolle wäre das nicht passiert (obwohl es meist so ist!). Ich stimme mich bei solch weitreichenden Änderungen im Vorfeld hier bei uns mit meinen Kollegen ab, zeige Ihnen das vorher mal demonstrativ am lebenden Exempel in zwei virtuellen Maschinen usw.. Wenn alle an einem Strang ziehen, ist es meist einfacher gemeinsam beim Chef zu argumentieren "Wir brauchen unbedingt".

Und eigentlich könnt Ihr nur massenhaft Vorteile daraus ziehen. Kein Problem auf dem Rechner mal eben die Version xy wieder herzustellen oder mit dem Notebook mal eine Woche offline @home zu arbeiten. Das Zurückdrehen von SubVersion beschränkt sich auf die Löschung aller .svn Verzeichnisse und der Deinstallation des Clients - und Ihr seid wieder da wo Ihr jetzt seid. Da wollt Ihr nach einer gewissen Einarbeitungszeit aber sicher nie wieder hin!

Wir haben ebenfalls mit FreeVCS/JediVCS angefangen, wobei uns das Locking und wie schon angeführt die harten Pfade gestört haben. Seit einem 3/4 Jahr sind wir jetzt auf Subversion umgestiegen und sind super zufrieden damit.