Codeverantwortlichkeit
-
earli schrieb:
Man schreibt einfach Code und git macht den Rest.
*lol* Git entscheidet also ob der Code durchdacht ist, ob er überhaupt compiliert, ob er fehlerfrei ist, ob er funktionell das macht was er soll?
Bei uns darf jeder überall wurschteln.
Wir haben allerdings auch Versionskontrolle (Mercurial), Unit tests, funktionelle tests, mit automatisiertem Build-System (continuous integration).
Und das führt dann zur berüchtigten "Blame-List" wenn mal was nicht mehr tut und der "schuldige" ist dann meist schnell gefunden.
-
In redmine werden Tickets verwaltet und dann zugewiesen. Gearbeitet wird nur anhand der Tickets und der dabei erstellten Analysen.
Die für ein Projekt eingeteilten Leute können auf das Repository uneingeschränkt zugreifen. Gearbeitet wird grundsätzlich nur auf einem Branch der dann vom Integrator auf die Mainline gebracht wird, sofern sich das ganze wenigstens bauen lässt.Abhängig vom Projekt werden minimal Tests definiert die der Integrator machen soll, um einen groben Überblick zu bekommen ob nach einer Integration nicht plötzlich nichts mehr funktioniert.
Gehts nach der Integration nicht oder sind zuviel Eingriffe nötig um einen branch zu mergen muss der Entwickler des Branch ran.
-
Was hat die Codeversionierung mit der Codeverantwortlichkeit zu tun?
Es geht doch eher um die fachliche Kompetenz, bei der Frage?
Und ja, ich arbeite alleine am Code. Andere Bürokollegen müssen im Team an einem Code arbeiten.
Ist doch ganz unterschiedlich. Aber ganz sicherlich nicht von GIT oder SVN abhängig...
-
scrontch schrieb:
earli schrieb:
Man schreibt einfach Code und git macht den Rest.
*lol* Git entscheidet also ob der Code durchdacht ist, ob er überhaupt compiliert, ob er fehlerfrei ist, ob er funktionell das macht was er soll?
Bei uns darf jeder überall wurschteln.
Wir haben allerdings auch Versionskontrolle (Mercurial), Unit tests, funktionelle tests, mit automatisiertem Build-System (continuous integration).
Und das führt dann zur berüchtigten "Blame-List" wenn mal was nicht mehr tut und der "schuldige" ist dann meist schnell gefunden.Genau darum geht es. Dank Git kann ruhig jeder an allem rumwurschteln, weil man am Ende immer sieht, wer es war, wenn was schief geht.
Bei uns haben auch alle Zugriff auf alle Verzeichnisse, das heißt aber nicht, dass jeder sich überall einmischt. Aber dank git muss man das nicht klären: Jeder lässt von sich aus die Finger von dem, wovon er keine Ahnung hat, und macht einfach.
Hängt natürlich auch von der Teamgröße ab. Wir sind mehr oder weniger 5 Leute.
-
Und wo ist das Problem mit Subversion? Benutzen wir schon ewig und sind nie auf irgendwas anderes umgestiegen. Da sieht man auch im Blame, wer was gemacht hat.
-
earli schrieb:
Genau darum geht es. Dank Git kann ruhig jeder an allem rumwurschteln, weil man am Ende immer sieht, wer es war, wenn was schief geht.
Worauf ich hinaus wollte ist: Man muss auch erkennen können wann etwas schief gegangen ist. Versionskontrolle allein reicht also nicht aus.
-
earli schrieb:
scrontch schrieb:
earli schrieb:
Man schreibt einfach Code und git macht den Rest.
*lol* Git entscheidet also ob der Code durchdacht ist, ob er überhaupt compiliert, ob er fehlerfrei ist, ob er funktionell das macht was er soll?
Bei uns darf jeder überall wurschteln.
Wir haben allerdings auch Versionskontrolle (Mercurial), Unit tests, funktionelle tests, mit automatisiertem Build-System (continuous integration).
Und das führt dann zur berüchtigten "Blame-List" wenn mal was nicht mehr tut und der "schuldige" ist dann meist schnell gefunden.Genau darum geht es. Dank Git kann ruhig jeder an allem rumwurschteln, weil man am Ende immer sieht, wer es war, wenn was schief geht.
Nein, wenn der Bug schon drin ist, sind die Kosten schon entstanden, da bringt es nichts, wenn man nachher feststellen kann wer es war.
Bei uns haben auch alle Zugriff auf alle Verzeichnisse, das heißt aber nicht, dass jeder sich überall einmischt. Aber dank git muss man das nicht klären: Jeder lässt von sich aus die Finger von dem, wovon er keine Ahnung hat, und macht einfach.
Dass das was mit git zu tun hat, ist wohl eine relativ alberne Begründung. Man kann bei fast jedem Sourceverwaltungssystem sehen, wer was geändert hat. Und einige Leute hält sowas von nichts ab.
-
Bei uns läuft's im Prinzip ähnlich wie bei simbad, mit einem kleinen Problem:
wir haben recht große Anteile von zu autocodierenden "Modellen", also Simulink, SysML-Kram, etc. Dann gibt es diverse "Listen" (Schnittstellen, Mapping, Konfiguration, etc.) -- in Excel oder handgebauten cfg-Files --, wo drinsteht, welche Modelle mit welchen Schalterstellungen dann bei der Integration in welches Projekt kommen, in welchen Zeitrastern sie zu laufen haben usw. Dazu noch irgendwelche aus den Modellen generierte Dokumentationen (pdf), Testfallbereichte (Excel) und Schlimmeres.
Das landet dann alles in einem Repository, aber man kann dort quasi keinen Änderungen tracen, weil selbst, wenn es im Prinzip Textdateien sind, die da eingecheckt werden, zB. wie mit Simulink-Modellen, ist ein diff einigermaßen sinnlos, weil sich Layout-Änderungen nicht von inhaltlichen Änderungen abgrenzen lassen. Von dem ganzen Binär-Kram ganz abgesehen. Jetzt hat man zwei Möglichkeiten: entweder, man holt sich ein spezialisiertes Diff und spielt in graphischen Modellen "finde zehn Unterschiede" oder, man probierts über den Checkin-Kommentar und ein Verweis auf das Arbeitsticket im System. Aber spätestens nach "ich habe meinen branch_x mal in branch_y rübergemerget, in branch_x sind Tickets A,B,C bearbeitet worden, in branch_y D,E und F, wobei beim merge Änderung E wieder von Änderung A überschrieben würde, was aber Absicht war und außerdem den Testreport von D, was keine Absicht war" blickt kein Mensch mehr durch.
In der ganzen Low-Level-Welt, wo anständig (= mit C und projektspezifisch) gearbeitet wird funktioniert das bei uns gut, aber mit der ganzen modellbasierten Entwicklung ... das skaliert irgendwie gar nicht (ca. 35 MBSE-Entwickler).
Jetzt die (verzweifelte) Frage: Jemand nen Tipp für mich?
-
Naja, also generierte Dateien (Testreports, Docs, Binaries) sollten nicht direkt in die Versionskontrolle, sondern auf einen Archiv-Server (natürlich getagged mit der Versionskontroll-revisionsnummer).
Bei den Simulink-Dateien kann ich das Problem natürlich nachvollziehen.
-
