exe-Dateien unterscheiden sich bei jedem build

[rwachtel]

Zitat von HHick123:

Zitat:

Und wofür meinst du gibt es Versions- und Buildnummern

Ja ich weiss schon, für was die gut sind.
Aber irgendwie find ich die Möglichkeiten der Versionsnummern ziemlich schwach, da sie wieder von mir abhängen, nämlich dass ich nicht vergesse, sie zu erhöhen. Die Buildnummer ist ja auch nur eine Hausnummer, weil ich je nach Gegebenheiten die Sourcen auf verschiedenen PCs kompiliere. Ausserdem hängt es wieder von mir ab, ob' ich sie erhöhen lasse oder nicht. [...]

Himmel, mit einem vernünftigen Build-Management und dem Einsatz von Continuous-Integration-Tools steht man doch gar nicht erst vor solch einem Problem. Versions-, Revisions- und Buildnummern werden dann z.B. zentral und automatisch verwaltet.

Zitat:

[...] Ok, man könnte natürlich ein Versionsverwaltungssystem verwenden. [...]

Ja, das ist ein Bestandteil.

Zitat:

Man stelle sich folgendes Scenario vor: [Beispiel]

Das ist ein Paradebeispiel für ein unorganisiertes resp. gar nicht erst vorhandenes Build-Management. Wenn ich das im Zusammenhang mit "Firmennetzwerk" lese, rollen sich mir die Fußnägel hoch.

Zitat:

P.S.: Nochetwas fällt mir ein: Es wäre nicht schlecht, wenn es eine Möglichkeit gäbe, die .dcu-Dateien etc. nach dem Kompilieren automatisch zu löschen, sodass durch das Kompilieren wirklich nur die .exe entsteht, dann könnte man noch besser vergleichen (die stören mich auch regelmäßig beim Vergleich)...

Auch das lässt sich mit den entsprechenden Tools realisieren.

[HHick123]

Zitat:

dem Einsatz von Continuous-Integration-Tools

Welches Tool würdest Du denn da konkret vorschlagen?

Zitat:

Zitat:

Man stelle sich folgendes Scenario vor: [Beispiel]

Das ist ein Paradebeispiel für ein unorganisiertes resp. gar nicht erst vorhandenes Build-Management. Wenn ich das im Zusammenhang mit "Firmennetzwerk" lese, rollen sich mir die Fußnägel hoch.

Du wirst es nicht glauben, aber ich hab' einen ganz guten Ruf in der Fira bezüglich der Qualität meiner Programme (das muss ich zu meiner Ehrenrettung sagen). Vielleicht liegt das auch daran, dass ich so ziemlich der einzige bin, der Delphi verwendet...

Ja, ich bestreite ja auch gar nicht, dass ich meine builds nicht manage, denn ich schreibe meine Software so, dass die Funktionalität einfach nicht vom Datum des builds abhängt, sondern nur vom Quellcode. Glücklicherweise hat Delphi ja wenige Compilerschalter und die stehen bei mir halt einfach im Quellcode. Natürlich verwalte ich schon meine Versionen in bezug auf Funktionalität...

Ich sag' jetzt lieber nicht, bei welcher Firma ich arbeite, sie ist eh' negativ in den Schlagzeilen, aber: Du solltest erst mal unsere Leute sehen, die Testautomatisierungen mit Perl/Cygwin/MSDOS codieren und ihr Programmpaket - falls man das überhaupt so nennen kann - auf der ganzen Festplatte verstreuen... Da krieg ich echt die Kriese, denn die bekommen es trotz enormem Aufwand nicht hin, das ihr Skript auf mehr als einem einzigen bestimmten PC läuft!! Was das immer für ein Aufwad ist, wenn man es zum Laufen bekommen will... Auch unsere C++-Leute finden es ganz normal, wenn ihre Benutzeroberfläche nach 5-jähriger Enwicklungszeit immer noch laufend abschmiert - letzte Woche erlebt, hab' geglaubt, ich spinne... DIE bräuchten wirklich ein "build management"

Aber vielleicht brauch ich auch eines und weiss es nur noch nicht...
Lasse mich gerne auf den richtigen Weg bringen...

Viele Grüße,
Helmut

[rwachtel]

Zitat von HHick123:

Zitat:

dem Einsatz von Continuous-Integration-Tools

Welches Tool würdest Du denn da konkret vorschlagen?

Vorab erstmal bin ich froh, dass Du meine Kritik nicht in den falschen Hals bekommen hast...

Bei mir ist zentrales Tool der FinalBuilder in der Professional-Version (wegen dem mitgelieferten Server). Was zwar auf der einen Seite daran liegt, dass er sowohl u.a. Delphi als auch .NET-Sprachen unterstützt (ich entwickle in letzter Zeit sehr viel in C#), aber auf der anderen Seite halte ich ihn für eines der leistungsfähigsten Build-/Continuous-Integration-Tools, die noch bezahlbar sind.

Zitat:

Du wirst es nicht glauben, aber ich hab' einen ganz guten Ruf in der Fira bezüglich der Qualität meiner Programme (das muss ich zu meiner Ehrenrettung sagen). Vielleicht liegt das auch daran, dass ich so ziemlich der einzige bin, der Delphi verwendet...

Dass die Qualität Deiner Programme hoch ist wollte ich damit auch gar nicht bestreiten. Man macht sich meiner Meinung nach halt die Arbeit ohne vernünftiges Build-Management selbst schwer. So sind die (wiederverwendbaren) Build-Skripte z.B. so gestaltbar, dass die Änderungskommentare der in die Quellcodeverwaltung eingecheckten Revisionen automatisch in die technische Dokumentation aufgenommen werden.

Ich habe hier z.B. speziell für meine Delphi-Projekte eine virtuelle Maschine auf einem Server laufen, die jede(!) Nacht nach Änderungen im Subversion-Repository schaut und dann nach erfolgreichem Bestehen von Unit-Tests einen Build inkl. aktualisierter Dokumentationen gezippt auf einen FTP-Server ablegt und die entsprechenden Adressaten per eMail informiert. Geht irgendwas schief, bekommen nur die entsprechenden Entwickler eine eMail.

Zitat:

[...] hab' geglaubt, ich spinne... DIE bräuchten wirklich ein "build management" [...]

Oh ja, das kenne ich nur zu Genüge...

Zitat:

Aber vielleicht brauch ich auch eines und weiss es nur noch nicht...
Lasse mich gerne auf den richtigen Weg bringen...

Wie Joel Spolsky schon sagte: im Prinzip wird es bei professioneller Softwareentwicklung immer gebraucht. Ich persönlich benutze es aber ganz klar hauptsächlich aus Bequemlichkeit: es macht mir die Arbeit leichter und entbindet mich von (wiederkehrenden) unangenehmen und daher gerne (bewusst oder unbewusst) beiseite geschobenen Tätigkeiten, mit anderen Worten: es schafft mir Freiraum (sowohl im Kopf als auch zeitlich). Dass die Qualität der Builds steigt ist dabei ein angenehmer und gern mitgenommener Nebeneffekt...

[HHick123]

Joel Spolsky, der Schöpfer von Excel und Visual Basic ist halt nicht gerade mein Vorbild....
Aber ok...