Strategie für Versionsverwaltung

[PatkIllA]

Wir haben eine schon nicht mehr ganz kleines Projekt in C#
Daran arbeiten ca 20 Entwickler Vollzeit und noch mal soviel die einen mehr oder weniger großen Teil ihrer Zeit daran arbeiten.

Das gliedert sich grob in folgende Teile:
Eine allgemeine Plattform mit Kernfunktionen
Eine handvoll Module.
Kundenerweiterungen über PlugIns und vorgegebene Schnittstellen.

Die Module und der Kern haben praktisch den gleichen Releasezyklus, da der Kern alleine nichts nutzt.
Die Kundenerweiterungen werden halt dann entwickelt oder aktualisiert, wenn der Kunde auf eine neue Version umsteigt.

Derzeit ist das alles in einem großen Subversion-Repository.
Das skaliert aber nicht mehr wirklich durch die immer mehr werdenen Kundenanpassungen.
Weitere Probleme sind das wir derzeit Bugfixes in einen branch für die Qualitätssicherung commiten und von da werden auch die Auslieferungen für alle Kunden erstellt. Es ist selten aber schon ein paar mal vorgekommen, dass für Bugfix a) in Modul b) auch eine neue Version von Modul c) bekommen hat in der durch einen Commit unabsichtlich was kaputt gegangen ist.

Außerdem wird derzeit meistens mit der Solution gearbeitet, wo alles drin ist. Da dauert das Kompilieren aber auch schon mal gerne eine Viertelstunde. Außerdem sollte man insbesondere für die Kundenerweiterungen gar nicht den ganzen Quellcode haben müssen.

Wir sind uns eigentlich schon einig, dass wir auf Git umsteigen, aber nicht so wirklich wie wir das strukturieren sollen.

[Berni]

Für mich hört sich das jetzt nicht unbedingt so an als ob allein der Umstieg von SVN auf GIT das beheben würde sondern man eher schauen müsste was am Code zu ändern. Vielleicht wäre es hier möglich, die Software noch weiter aufzuteilen so dass einzelne Teile wirklich komplett entkoppelt sind und unabhängig voneinander versioniert und kompiliert werden können? Und vielleicht auch irgendwie automatische Tests in die Paketierung mit einbauen?

[PatkIllA]

Für mich hört sich das jetzt nicht unbedingt so an als ob allein der Umstieg von SVN auf GIT das beheben würde sondern man eher schauen müsste was am Code zu ändern.Der Umstieg auf Git ist auch nur angedacht, weil es sich eben anbietet, wenn wir sowieso an der Struktur was ändern.
Am Code müssen wir hoffentlich nicht wirklich was ändern. Das ist schon ziemlich komponenten orientiert.

Vielleicht wäre es hier möglich, die Software noch weiter aufzuteilen so dass einzelne Teile wirklich komplett entkoppelt sind und unabhängig voneinander versioniert und kompiliert werden können? Und vielleicht auch irgendwie automatische Tests in die Paketierung mit einbauen?
Ist die Frage wie weit.
Wir wollen ja auch nicht in etlichen Repositories untergehen und es sollte auch noch halbwegs einfach möglich sein den Quellcode von Kern Modulen und Kundenanpassungen per Source nachzustellen um das ordentlich analysieren zu können.

[noid]

Für mich klingt das als ob euch eine continuous integration plattform mit test framework fehtl (jenkins fürs erste zB).
Auch solltet ihr mit den Branches sauber umgehen, dazu gehört eben auch ein gescheites automated Testtool welches am besten _jeden_ build drüberläuft.
Die 15min machen dann auch den Kohl nicht mehr fett, weil der Entwickler mit einem inkrementellen build sicherlich nicht so lange kompiliert.

Git wird auch nicht das Problem lösen, eine Restrukturierung sicherlich auch nicht.

edit: Testen, testen und nochmals testen - das gehört dazu.

[Marscel]

So als Idee, ich habs selbst noch nie verwendet: git subtrees (http://kapitel26.github.io/Git/2012/08/10/git-subtree---alternative-zu-submodulen/).

Und dann die Sichtweise umkehren: also je Kunde ein Repo und alles, was geteilt wird, als Subtree-Repo einhängen. Aber wahrscheinlich müssen eure VS-Projekte dazu auch umgebaut werden.

Mit git kannst du kein einzelnes Verzeichnis ziehen, sondern immer mind. einen Branch. Vielleicht geht es damit aber dann, nur die Kundenerweiterung zu ziehen und die Subtrees später ggf. nachzuladen.

[PatkIllA]

Für mich klingt das als ob euch eine continuous integration plattform mit test framework fehtl (jenkins fürs erste zB).
Es gibt schon so einige UnitTest, aber die decken auch nur einen kleinen Teil ab. Ein ordentlicher Teil ist auch GUI.
Auch solltet ihr mit den Branches sauber umgehen, dazu gehört eben auch ein gescheites automated Testtool welches am besten _jeden_ build drüberläuft.Ist auch geplant.
Bei jedem Build könnte etwas viel werden, da die automatisierten Tests jetzt schon einige Zeit laufen.

Die 15min machen dann auch den Kohl nicht mehr fett, weil der Entwickler mit einem inkrementellen build sicherlich nicht so lange kompiliert.Da wäre ja schon die Frage wie man den Build aufsetzt, wo er die herbekommt, wer da für neue Versionen sorgt usw.

Git wird auch nicht das Problem lösen, eine Restrukturierung sicherlich auch nicht.Git soll da nichts lösen. Alle Sourcen in einem Repository skaliert aber nicht wirklich.
Es ist auch absolut egal ob Kundenerweiterung in Version x läuft, wenn der Kunde eine andere Version einsetzt. Die meisten Kunden lassen auch die ein oder andere Version aus.

[noid]

Ich bin kein Freund davon, aber _Prozesse_ kann man in minimalem Umfang zur Qualitätssicherung einsetzen.
"Configuration Management" ist eben leider nicht nur Codebase in einem tool. Dazu gehört auch change control etc.
Leitet euch aus dem CMMI Geschichten was ab, was für euch noch beherrschbar ist. Zertifikat braucht man ja jetzt nicht unbedingt, aber ich als Kunde würde bei "Kaufsoftware"/Dienstleistung sowas schon vorraussetzen.

Aktuell macht ihr halt "Gefrickel", aus dieser Sicht heraus - ich spreche hier euch jetzt nicht eure Kompetenz in technischer Natur ab, aber ab einer gewissen Komplexität und Variantenvielfalt muss man eben die Schraube andrehen.

[PatkIllA]

Ist halt alles historisch gewachsen. Vor 5 Jahren waren es nur 3 Entwickler. Was da alles schon vorgekommen ist darf man gar nicht erzählen.

Ich glaube nach einer Zertifizierung hat noch kein Kunde gefragt. Es ist ja auch immer der Spagat zwischen Anpassungen dazwischenschieben, auf die nächste Major warten oder gar nicht machen. Wenn der Kunde wichtig genug ist (Genug zahlt) zählt das meistens. Zumal das ja auch eine Stärke ist, dass wir eben nicht zwangsweise auf Updates anderer angwiesen sind und vergleichsweise flexibel sind.

[noid]

Ist halt alles historisch gewachsen. Vor 5 Jahren waren es nur 3 Entwickler.
Ich glaube nach einer Zertifizierung hat noch kein Kunde gefragt. Es ist ja auch immer der Spagat zwischen Anpassungen dazwischenschieben, auf die nächste Major warten oder gar nicht machen. Wenn der Kunde wichtig genug ist (Genug zahlt) zählt das meistens. Zumal das ja auch eine Stärke ist, dass wir eben nicht zwangsweise auf Updates anderer angwiesen sind und vergleichsweise flexibel sind.

"Glück gehabt" - ihr müsst euch halt klar werden, dass das Produkt mit der Qualität steht und fällt. Kann mir nicht vorstellen, dass ihr so unersetzlich seid. Neben Flexibel steht btw. auch immer Qualität.

Wir haben zB schon von Lieferanten Softwarequalitätsaudits gemacht - es ist ja nicht so, dass ihr alleine mit eurem Problem sein. Man muss halt nur den Absprung schaffen um vom Gebastel der ersten Stunde in eine höhere Ebene kommen. Sonst kommt einer eurer Kunden ganz schnell auf Ideen sich andere Partner zu suchen. Je nachdem wieviel Schaden entstanden ist. ;(

Wenn ihr eine entsprechend "kleine" Prozesse habt, mit passender Verifizerung, dann könntet ihr quasi jeden build dem Kunden geben. Da muss aber von a bis o alles stimmen.

[PatkIllA]

Dass wir jetzt alle oder viele Kunden eine nennenswerte Zeit lahmlegen gabs jetzt auch noch nicht.

Die Kunden kriegen auch nicht täglich oder automatisch neue Builds und innerhalb der Versionsnummer ist und bleibt es auch "ziemlich" stabil. In 99,x % klappt das problemlos.

Der Entwicklungsleiter sorgt auch öfters dafür, dass Änderungen halt erst eine Version später verfügbar sind und nicht so wie der Vertrieb es versprochen hat. Aber das kann dann halt auch mal ein knappes Jahr dauern.

Und ganz vermeiden wird man es nicht können. Mein letzter Absturz produzierender war was mit Abbruch eines Prozesses auf bestimmten Daten zu bestimmten Zeiten mit Multithreading. Kam in meinen einfachen Tests praktisch nicht vor. In anderer Umgebung schon deutlich häufiger.

[noid]

Ich sag's nur ungern, der erste Schritt in die falsche Richtung ist leugnen und/oder kleinreden. Spätestens bei der nächsten "feature"-Erweiterung ergibt sich dann ein ungetestetes, unwartbares Teil was ihr dann mühsam durchforstet - weil euch die Basis für so etwas fehlt.

Deine Frage nach Versionsverwaltung muss also als Antwort nicht nur "git/svn/cvs" sein, aber dafür braucht es in der Regel halt Schmerzen... weil sonst will das keiner hören.

[PatkIllA]

Ich sag's nur ungern, der erste Schritt in die falsche Richtung ist leugnen und/oder kleinreden. Spätestens bei der nächsten "feature"-Erweiterung ergibt sich dann ein ungetestetes, unwartbares Teil was ihr dann mühsam durchforstet - weil euch die Basis für so etwas fehlt.Wir wissen ja auch um die Defizite und mehr oder weniger potentiellen Probleme.
Ich hab auch schon mit anderen Entwicklern aus anderen Firmen gesprochen und bei keinem gibt es wasserdichte Verfahren. Ich glaube auch gar nicht, dass es sowas gibt. Irgendeinen Tod muss man immer sterben.
Deine Frage nach Versionsverwaltung muss also als Antwort nicht nur "git/svn/cvs" sein, Das ihr darauf jetzt rumreitet. Es ist völlig klar, dass es absolut nebensächlich ist welches System eingesetzt wird. Es ging mir auch mehr darum was kommt wohin, wird wie und wann gebrancht. Wie kriegt man das alles wieder zusammen um reprozierbare Umgebungen zu haben usw.
aber dafür braucht es in der Regel halt Schmerzen... weil sonst will das keiner hören.Das muss man ja auch alles durchbekommen. Wenn man dann noch x Personen y Stunden für Prozesse organisieren und überwachen abstellen muss heißt es als erstes immer ob das alles nötig ist. Selbst wenn sonst durch allgemeines Chaos in der Summe noch mehr Arbeitszeit untergeht.

[noid]

Als "Prozess" kannst du auch Agile und/ode TDD deklarieren, ohne, dass damit jetzt tonnenweise unsinnig Stunden verbraten werden.
Nötig ist es, weil die Probleme, die du beschreibst, damit bei richtiger Handhabung verringert/vermieden/eliminiert werden - je nachdem wie strikt man es lebt.

Es hat bei mir auch gedauert, irgendwann merkt man, dass ein Projekt mit mehreren Entwicklern eine gewisse Methodik benötigt, die man in einem sehr kleinen Team nicht braucht. Und warum? Weil bei den richtigen Leuten zusammengeworfen das Ganze in peer-Manier abläuft. Ab 7+ Personen ist dieses Element aber nicht mehr gegeben und man muss das organisieren.

Habt ihr wenigstens einen Plan _woher_ und _warum_ eure Probleme kommen? Das mag unsinnig erscheinen, aber für eine Analyse unerlässlich.

btw. der Fisch stinkt vom Kopf. "Früher ging das auch so", "das haben wir früher in 4 Tagen gemacht - was braucht ihr eine Woche". Nichts neues.

edit: der Konslutant für ein irrsinnig hohes Honorar erzählt euch auch kaum was anderes. :)

[PatkIllA]

Hauptprobleme sehe ich bei der Weiterentwicklung dabei, dass wir da den gesamten Haufen an Software haben. Da kann man bei der Weiterentwicklung nicht auch noch die ganzen Kundenerweiterungen anpassen. Da muss auch gar nicht jede Erweiterung mit jeder Version laufen. Beim Wechsel auf neue Kernversionen sind die Kunden auch bereit die Aufwände zu bezahlen.

Und bei Releaseversionen kommen die die Änderungen sehr leicht in den Branch, der die Basis für alle Auslieferungen ist, ohne dass da ausreichend QS gemacht wird.

[Monger]

Die ganze Branch Thematik hat ja schon fast religiöse Züge. Da gibt es einige sehr unterschiedliche Denkweisen.

Ein Ansatz ist: Teile und herrsche. Isoliere jedes Feature in einem eigenen Branch, und sorge mit Integrationsbranches dafür dass die Qualität stimmt, und splitte daraus dann deine Release Branches.

Wir sind auf Arbeit mehr oder minder diesen Weg gegangen. Wir sind vor zwei Jahren auf ein neues Quellverwaltungssystem umgestiegen was insgesamt das Branching und den Build Prozess besser automatisiert als das vorige (von Rational Clearcase auf TFS)... jetzt haben wir unzählige Entwickler- und Integrationsbranches, und die Gesamtlaufzeit bis Änderungen bis ins finale Produkt durchschlagen ist ziemlich mies.
Merke: nur weil du etwas tun kannst, heißt es nicht dass du es tun solltest. Google arbeitet angeblich bei seinen Produkten nur auf zwei ständigen Branches: einem Development Branch und einem Release Branch. Dazu noch temporäre Shelves, und halt ein Qualitätsprozess der bereits beim Checkin greift, nicht erst im Release.

Was die Projektorganisation in .NET angeht: wir haben mal Experimente gemacht, wie sich die Build Zeit ändert wenn man den selben Quellcode aus mehreren Projekten in ein Projekt (und damit eine Assembly) zusammenträgt. Das wird mitunter drastisch schneller. Ich hab den Eindruck dass der Linker nicht besonders schnell ist. Microsoft selber empfiehlt ja auch, jedes Projekt als ein Produkt zu sehen. Ergo: wenn du zwei Assemblies logisch nicht voneinander trennen kannst, sollten sie wahrscheinlich eine einzige sein.

Ich bin deshalb selber eher ein Fan vom monolithischen Ansatz. Lieber alles im selben Repository, möglichst in sich geschlossene Projekte. Es gibt andere Möglichkeiten in einem Produkt für Ordnung zu sorgen als es in verschiedene DLLs zu zersplittern. Maximal eine Hand voll Branches, für jedes distinkte Produkt einen, dafür Gated Checkins mit einer ordentlichen Abdeckung an automatischen Tests.

Die Frage ist halt für euch, wie ihr mit den Kundenfeatures umgeht. Aus Build Sicht ist es möglicherweise einfacher, alles in einem zentralen Produkt zu bündeln, und halt nur gezielt (z.B. über Build Targets o.ä.) bestimmte Features zu deaktivieren, als dafür unzählige Branches und Unterprodukte aufzumachen. Kommt halt drauf an, wie klar sich die Kundenfeatures vom Produkt isolieren lassen.

[Asaraki]

edit: der Konslutant für ein irrsinnig hohes Honorar erzählt euch auch kaum was anderes. :)

Aber der kann die tollen Wörter einfach besser. You know...

Monger hat's schon auf den Punkt gebracht, das ganze ist eine Philosophie-Frage. Es gibt nicht DEN Weg - das wichtigste ist, dass der Weg klar auf der Karte erkenntbar ist und ALLE den gleichen Weg gehen.

@TS : Deine Argumente/Schutzhaltung kann hier jeder gut nachvollziehen, aber bringt absolut nichts. Keiner hier ist dein Chef also nimm's bloss nicht persönlich - sei offen und versuche die Fehler in eurem System zu erkennen und nicht die Symptome.

Jeder der mehr als 1-2 Jahre in der IT war weiss was "historisch gewachsen" bedeutet.
"Wir wissen schon, dass das eigentlich so nicht mehr machbar ist, aber wir haben's verschlafen damals zum richtigen Zeitpunkt das Konzept zu ändern".

Und bei Releaseversionen kommen die die Änderungen sehr leicht in den Branch, der die Basis für alle Auslieferungen ist, ohne dass da ausreichend QS gemacht wird. Versteh ich das richtig? Ich kann meinen Scheisscode einfach in deinen Releasebranch schmeissen OHNE dass dies abgesegnet wird? Ich glaube du weisst wo euer Problem ist.

Ich hatte lange Mühe mit den 'neuen' Prozessen und wenn ein Anzugfuzzi ohne Praxiserfahrung uns etwas von "schneller und agiler" erzählen wollte. Man muss aber aufpassen, da nicht in Ignoranz zu verfallen, denn selbst wenn sie selbst keine Ahnung haben, so ist der ein oder andere Punkt aus ihrem Studium schon gut durchdacht von einem schlauen Kopf ;) Und gerade so Dinge wie "100% Tested" muss man ernst nehmen. Das war 'früher' nicht nötig, weil die Entwickler eine viel höhere Eigenverantwortung hatten im Durchschnitt. Schliesslich war man oft selbst der, der dann Nachts raus musste um seinen Scheiss zu flicken.

Heute wo Entwicklung ein Fliessbandjob geworden ist leidet halt auch der persönliche Einsatz und du kannst nicht erwarten, dass jeder Entwickler zu 100% hinter seinem Code steht. Und wie in der Schule muss man dann die Kollektiv-Strafe auspacken und jede Zeile Code, auch von den besten Entwicklern, durchtesten/prüfen. Der Witz ist, dass die guten Coder damit nur sehr wenig Zeit verlieren, da sie keine Probleme haben und die ganzen Argumente daher hinfällig werden ;)

EDIT :Noch von wegen Monolith vs Vielgeteilt : Monolithic ist im Zweifelsfalle besser, weil safer. Eine start geteilte Applikation muss einfach von Anfang an (!!) sauber aufgebaut werden, da man sonst nach 80% Completion auf die chinesische Mauer stossen kann. Aber grundsätzlich ist nichts davon besser, auch hier ist die konsequente Umsetzung wichtiger als der eigentliche Plan.

[Monger]

Monger hat's schon auf den Punkt gebracht, das ganze ist eine Philosophie-Frage. Es gibt nicht DEN Weg - das wichtigste ist, dass der Weg klar auf der Karte erkenntbar ist und ALLE den gleichen Weg gehen.

Ne, da muss ich widersprechen. "Wir machen das jetzt so, basta!" ist keine gute Firmenpolitik. Und Monokulturen zu erzwingen, unter der Prämisse dass das ja "viel einfacher" für alle ist, ist auch Käse.
Und es mag zwar keine perfekten Lösungen geben, aber es gibt definitiv falsche. Wäre Blödsinn, Leute auf einen Weg zu zwingen die die Chance haben etwas besser zu machen.

Wichtig ist, dass jeder versteht warum jetzt diese oder jene Lösung eingesetzt wird, und dass regelmäßig überprüft wird ob noch die selben Rahmenbedingungen herrschen als man sich für eine Lösung entschieden hat.

[Asaraki]

Ne, da muss ich widersprechen. "Wir machen das jetzt so, basta!" ist keine gute Firmenpolitik. Und Monokulturen zu erzwingen, unter der Prämisse dass das ja "viel einfacher" für alle ist, ist auch Käse.
Und es mag zwar keine perfekten Lösungen geben, aber es gibt definitiv falsche. Wäre Blödsinn, Leute auf einen Weg zu zwingen die die Chance haben etwas besser zu machen.

Wichtig ist, dass jeder versteht warum jetzt diese oder jene Lösung eingesetzt wird, und dass regelmäßig überprüft wird ob noch die selben Rahmenbedingungen herrschen als man sich für eine Lösung entschieden hat.

Ne da hast du mich über-interpretiert. Ich meine das, was du auch im letzten Satz ansprichst. Man braucht ein gemeinsames Verständnis davon, wie man es machen will. Denn wenn jeder, der sich für "besser" hält, sein eigenes Süppchen kocht hast du am Ende nur noch Brei.

Zwingen und "alternativen interessieren nicht" ist definitiv falsch, jedoch ist auch dies ab einem gewissen Projektstadium manchmal richtig und besser, als jetzt doch noch das Konzept zu ändern.

Am Abend ist alles sehr vage und von Fall zu Fall verschieden und es gibt keine allgemeingültigen Regeln. Wichtig ist, aber dass alle am gleichen Strang ziehen, sonst verschwendet man riesige Mengen von Energie.

P.S: Ich finde Monokulturen wenn es um Code-Style und Versionierungs-Regeln geht sehr wohl gut. Natürlich soll man immer die Verbesserung suchen, aber ein paar Dinge müssen geregelt sein. Und dann kann man, für das nächste Projekt, die Regeln verbesseren/ändern. Aber es darf nicht immer und alles noch "interpretations-spielraum" lassen.

[PatkIllA]

Versteh ich das richtig? Ich kann meinen Scheisscode einfach in deinen Releasebranch schmeissen OHNE dass dies abgesegnet wird? Ich glaube du weisst wo euer Problem ist.Jup. Das geht im Moment noch. Ich bin immer noch erstaunt, dass es doch meistens gut geht ;)

Das steht aber schon auf der Liste, dass da nur noch eine kleine Gruppe darein commiten kann.
Das geht mit den verteilten Repositories von Git ja auch ganz gut. Da kann sich dann der zuständige was von einem anderen holen und das dann in das Hauptrepo packen.

Und wie in der Schule muss man dann die Kollektiv-Strafe auspacken und jede Zeile Code, auch von den besten Entwicklern, durchtesten/prüfen. Der Witz ist, dass die guten Coder damit nur sehr wenig Zeit verlieren, da sie keine Probleme haben und die ganzen Argumente daher hinfällig werden ;)Und das zieht wirklich wer durch?
Aus den Codereviews weiß ich, dass ich Stunden an Anmerkungen an wenigen hundert Zeilen Code machen kann.

[Marscel]

Und das zieht wirklich wer durch?
Aus den Codereviews weiß ich, dass ich Stunden an Anmerkungen an wenigen hundert Zeilen Code machen kann.

Ich überfliege alle Commit-Diffs von anderen für Projekte, die unter meiner Federführung stehen.

Und wie ich finde, macht das auch Sinn. Anmerkungen aber nur dann, wenn wirklich was brenzlig ist.

[Asaraki]

Ich überfliege alle Commit-Diffs von anderen für Projekte, die unter meiner Federführung stehen.

Und wie ich finde, macht das auch Sinn. Anmerkungen aber nur dann, wenn wirklich was brenzlig ist.

Jo bei uns lief's auch darauf hinaus, dass schlussendlich der Cheffe halt nix mehr tun konnte (bisschen übertrieben) als prüfen was die Leute so gebastelt haben, hat dann aber auch echt geholfen Fehler gleich zu finden und lösen die uns später nur aufgehalten hätten. Man glaubt's kaum, aber so ein reibungsloser erster Testlauf hat auch was ;)

[Shink]

Und das zieht wirklich wer durch?
Ja. Bei uns gibt es Spalten für "Peer Review" und "Review" am Scrumboard. Soll heißen: Von unserem Team kommt kein Code durch, der nicht von einem zweiten Entwickler und dem Teamleiter akzeptiert wurde.

Wobei wir aus Zeitgründen dazu über gegangen sind, kleinere Schnitzer gleich selbst im Zuge des Reviews auszubessern.