Zerbrochenen Code an das Repository zum Zwecke der Sicherung übergeben

Question

Ich habe gerade mit einem anderen Entwickler (älter als ich) gesprochen und versucht, ihn davon zu überzeugen, dass wir kontinuierliche Integration über Cruise Control implementieren sollten. Er sagte mir, dass dies nicht funktionieren würde, weil er Code schreibt, der nicht ständig zum Repository kompiliert wird, um ihn zu sichern. Und diese automatisierten Builds, die uns von Fehlern benachrichtigen, wären nur Lärm.

Commit Müll zum Repo klingt schlecht für mich. Aber ich hatte keine Worte und wusste nicht, was ich sagen sollte. Was ist die Alternative? Wie empfiehlt es sich, den Code auf einem anderen Computer zu sichern, ohne dabei unnötige Revisionen hinzuzufügen?

BTW, unser Versionskontrollsystem ist SVN und das wird wahrscheinlich nicht so bald ändern.

Answer 1

In Zweigen entwickeln und bereit zu testen und hoffentlich arbeiten Zweige in die Hauptlinie. Lassen Sie den Server für die kontinuierliche Integration von der Hauptleitung (in Svn, die am häufigsten als Trunk bezeichnet wird) abhängig sein, damit neue Revisionen erstellt und validiert werden können.

Answer 2

Wie genau erstellt jeder andere in Ihrem Team, wenn er Code eincheckt, der nicht kompiliert?

Im Allgemeinen denke ich, es ist ein Faux-Pas, Code in Ihre Hauptzweig einzuchecken, der nicht kompiliert; es ist wirklich rücksichtslos gegenüber jedem anderen, der darauf hofft, dass er die neuesten Erkenntnisse aus der Quellcodeverwaltung und dem Build erhält.

TFS verfügt über einige nützliche Funktionen, um dieses Problem zu beheben (shelve/unshelve); nicht sicher, ob SVN oder nicht. Die meiste Zeit, wenn jemand an einer großen Veränderung arbeitet und sie in der Lage sein müssen, kaputten Code einzusehen, ist es besser, zu verzweigen und Änderungen an der Hauptlinie zusammenzuführen.

Answer 3

Wenn Sie defekten Code in einen Zweig einchecken, den andere Entwickler voraussichtlich verwenden werden, und nicht eine Kommunikationslinie über diese und tun es aus einem guten Grund tun ... nun, ist Ihr Kollege Isn 't folgen besten Praktiken. Ein für beide Seiten akzeptables Best Practice kann sein, dass "build the build" -Typ "backup" checkins in einem Entwickler-privaten Zweig des Codes passieren muss, und wenn Code in einem Zustand ist, der den Build nicht unterbricht oder Komponententests, wird es mit einem Leitungszweig verbunden, den Cruise Control überwacht.

Answer 4

Wenn er nicht der einzige Entwickler auf der Branche ist (was sich anhört, als wäre das nicht der Fall), dann sollte er sich nicht dazu verpflichten, Code zu brechen. Es gibt Dutzende von Lösungen zum "Sichern" von Code in der Entwicklung, einschließlich des Erstellens eines privaten Zweigs der aktuellen Zeile oder des Schreibens eines kleinen Skripts, das das Arbeitsverzeichnis auf einem Dateiserver sichert.

Answer 5

Verwenden Sie git für lokale Backups/History und git-svn tools, um nur die Arbeitsversionen einzuchecken.