4. Releasemanagement unter C++ Builder möglich?

Releasemanagement unter C++ Builder möglich?

  • A

    DocShoe schrieb:

    Ich benutze Subversion zur Versionsverwaltung und erzeuge für jedes Release einen neuen Branch.

    Das kann ich auch nachdrücklich empfehlen.

    Für die SVN-Integration gibt es außerdem DelphiSVN, das aus der IDE heraus einfachen Zugriff auf grundlegende Befehle wie Commit, Update, Revert etc. sowie über das History-Tab eine Visualisierung von Diff und Blame bietet. Allerdings sollte man die aktuellste Version aus dem SVN-Repository laden, weil das Release-Branch schon vier Jahre alt ist.

    0
  • A

    (Wo wir gerade beim Thema sind: es würde mich interessieren, wie ihr Builds und Tests automatisiert. Builds mache ich derzeit mit einem kleinen handgemachten Skript und MSBuild, Tests mit dem ConsoleTestRunner von DUnit, aber das ist irgendwie nicht ideal.)

    0
  • ?

    Getrennte Kopien für die Testphase und für Release zu verwenden ist unsinnig, da sehr unübersichtlich. Die meisten Compiler - auch CBuilder - bieten da wenig brauchbaren Komfort, nur Debug- oder Release-Einstellungen. Das bringt aber nicht das, was man will. Ich mache das deshalb anders mit zwei einfachen Dingen:

    1. einer globalen BOOL-Variable (false = Test, true = Release)
    2. mit defines für eine bedingte Compilierung

    Das erfordert nur wenig Änderungen am Projekt und kann einfach plaziert werden. Wenn alles klar, entfernt man die ifs für die Testversion. Mit der bedingten Compilierung kann man zudem mehrere Neuerungen einzeln unterscheiden.

    Fazit: Suche nicht lange nach Hilfestellungen des Compilers oder anderen fremden Lösungen. Mache es einfach selbst in deinem Programmcode - man kann sehr gut damit leben und behält alles im Griff!

    0
  • A

    AlterProgrammierer schrieb:

    Getrennte Kopien für die Testphase und für Release zu verwenden ist unsinnig, da sehr unübersichtlich.

    Wenn du ein VCS verwendest, ist daran überhaupt nichts unübersichtlich.

    AlterProgrammierer schrieb:

    Die meisten Compiler - auch CBuilder - bieten da wenig brauchbaren Komfort, nur Debug- oder Release-Einstellungen.

    Ab C++Builder 2006 gibt es Build-Konfigurationen, mit denen du beliebig viele beliebig konfigurierte Optionskonfigurationen für Builds verwalten kannst.

    AlterProgrammierer schrieb:

    1. einer globalen BOOL-Variable (false = Test, true = Release)
    2. mit defines für eine bedingte Compilierung

    So etwas braucht man eigentlich nur in Ausnahmefällen, und es hat mit dem Problem an sich nicht sehr viel zu tun.

    AlterProgrammierer schrieb:

    Das erfordert nur wenig Änderungen am Projekt und kann einfach plaziert werden. Wenn alles klar, entfernt man die ifs für die Testversion.

    Achso, wenn alles gerade mal funktionierst, wirfst du deine Tests weg? 🤡

    AlterProgrammierer schrieb:

    Mit der bedingten Compilierung kann man zudem mehrere Neuerungen einzeln unterscheiden.

    Fazit: Suche nicht lange nach Hilfestellungen des Compilers oder anderen fremden Lösungen. Mache es einfach selbst in deinem Programmcode - man kann sehr gut damit leben und behält alles im Griff!

    Ich sehe nicht, wie das ein Ersatz für ordentliches Konfigurations- und Versionsmanagement sein soll. Was machst du, wenn du in der aktuellen Revision irgendetwas kaputtgemacht hast, aber ein Kunde schnell eine kleine Änderung in einer stabilen Version braucht? Ich nehme einfach den letzten Release-Branch und adaptiere ihn nach Bedarf. Du mußt erst deine Fehler beheben.

    0
  • B

    @audacia
    Stimmt alles, was du sagst. Macht dann aber abhängig vom Compiler und seiner Entwicklungsumgebung. Man braucht also CBuilder2006 oder neuer? Und diese Compiler sind leider sehr teuer! Wie auch immer, ein durchdachtes Releasemanagement ist sinnvoll. Musste man in früheren Zeiten alles selbst machen als es hierfür keinerlei Hilfestellungen gab. :p
    Die alten Konzepte bleiben einen Vorschlag wert, wenn man die neueren besseren Ansätzen nicht zur Verfügung hat oder damit nicht umgehen kann. Der Fragesteller wollte Ideen, keine fest vorgeschriebenen Lösungen. 🤡

    0
  • A

    berniebutt schrieb:

    Stimmt alles, was du sagst. Macht dann aber abhängig vom Compiler und seiner Entwicklungsumgebung.

    Wieso genau macht dich die Verwendung eines VCS abhängig von C++Builder?

    berniebutt schrieb:

    Und diese Compiler sind leider sehr teuer!

    Für Hobbyprogrammierer schon. Wenn du Geld damit verdienst, eigentlich nicht.

    0
  • B

    audacia schrieb:

    berniebutt schrieb:

    Stimmt alles, was du sagst. Macht dann aber abhängig vom Compiler und seiner Entwicklungsumgebung.

    Wieso genau macht dich die Verwendung eines VCS abhängig von C++Builder?

    berniebutt schrieb:

    Und diese Compiler sind leider sehr teuer!

    Für Hobbyprogrammierer schon. Wenn du Geld damit verdienst, eigentlich nicht.

    Ich kenne VCS nicht und die Preispolitik von Borland und den Nachfolgern war mir seinerzeit unverständlich geblieben. Ich wollte die horrenden Updates einfach nicht mehr bezahlen. Das hat mit Hobbyprogrammierung oder Profiprogrammierung wenig zu tun. Wenn du es brauchst, dann ist es gut. Aber das führt jetzt vom Thema weg.

    Man kann das alles sehr gut mit den alten Konzepten auch professionell machen. Hatte man früher so machen müssen und ist damit klargekommen. In deiner Vielzahl von Konfigurationen und Versionen kann man auch leicht den Überblick verlieren.

    0
  • W

    @berniebutt
    VCS =>
    http://en.wikipedia.org/wiki/Version_control_system

    0
  • A

    berniebutt schrieb:

    Ich kenne VCS nicht

    VCS ist kurz für Version Control System, also etwa Subversion.

    berniebutt schrieb:

    Man kann das alles sehr gut mit den alten Konzepten auch professionell machen.

    Versionsmanagement? Wohl kaum. Release-Management? Da sollten wir uns, glaube ich, erst einmal einig werden, was wir genau unter dem Begriff verstehen. Wenn es um automatisierte Builds und dergleichen geht, dann wirst du mit "den alten Konzepten" genauso wenig effizient arbeiten können.

    berniebutt schrieb:

    Hatte man früher so machen müssen und ist damit klargekommen.

    Das ist noch lange kein Grund, daran nichts zu ändern.

    berniebutt schrieb:

    In deiner Vielzahl von Konfigurationen und Versionen kann man auch leicht den Überblick verlieren.

    Wieso sollte man da den Überblick verlieren? Es gibt den Trunk, das ist die aktuell in der Entwicklung befindliche Version, und dann gibt es verschiedene Branches, die nach Releases numeriert sind (etwa: 1.0, 1.6). Sehe ich jetzt nichts unübersichtliches dran.

    0
  • B

    OK, ich wollte keine neue Diskussion um ein altes Thema auslösen. Jeder kann das machen wie er es will. Kommt auch darauf an, wieviele Leute mit welchen Erfahrungen an einem Software-Projekt beteiligt sind. Wenn das Gesamtkonzept eines Projektes schlecht ist, helfen auch noch so ausgefeilte Hilfsmethoden für Testphasen und Release wenig weiter. :p

    0
Anmelden zum Antworten