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

[nachti1505]

Zitat von 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

Erklär mal warum!? Weil diese Info haben wir bis dato noch nie gebraucht...! (Ok, statistisch ist es schön nachzusehen, wer wann welche Änderungen vorgenommen hat - aber inhaltlich waren diese Infos für uns eher unrelevant, da jeder Entwickler mehr oder weniger "seine" Module hat)

[shmia]

Man so ganz grundsätzlich:
Wer im Team programmiert und damit sein Geld verdient aber keine Versionsverwaltung hat,
der handelt fahrlässig unprofessionell!!
Das ist ungefähr so wie wenn ein Handwerker auf dem Bau ohne Elektrowerkzeug arbeiten würde.
Selbst Einzelkämpfer (Freelancer) sollten eine Versionsverwaltung verwenden.

Es stellt sich also nur noch die Frage, welche Software eingesetzt werden soll.
Wir verwenden z.B. Jedi-VCS und ich bin sehr zufrieden damit.

[HeikoAdams]

Das sehe ich ähnlich. Alleine schon aus dem Grund, das man schnell und relativ einfach zu einem funktionierenden Stand zurückkehren kann, falls man sich mal total verrannt hat, sollte man (auch als Einzelkämpfer) besser eine moderne Versionsverwaltung nutzen.

Um beim Thema zu bleiben: Ich kenne so ein Vorgehen, wie es der OP beschreibt, aus eigener Erfahrung und ich weiß, das es immer sehr "spaßig" war, falls mal 2 Entwickler gleichzeitig eine Unit bearbeiten wollten. Das ist dann im immer in wildem hin und her kopieren der Datei(en) geendet. Vielleicht wäre das auch ein Argument, das man für eine Versionsverwaltung ins Feld führen könnte.