Delphi für mehrere Entwickler installieren

[OlliWW]

Hallo Zusammen,

Ich bin auf der Suche nach ein paar Tipps oder best practises wie man in einer wachsenden Firma, die mit Delphi entwickelt, die einzelnen IDE's für alle Entwickler gleich hält.

Momentan hat jeder Entwickler einen eigenen PC mit einer eigenen Delphi Installation. Unser Softwareprojekt ist ziemlich umfangreich und benötigt einige Komponenten.

Jedes mal wenn ein neuer Entwickler eingestellt wird ist es fast eine tagesfüllende Aufgabe die IDE einzurichten (alle Abhängigkeiten zu erfüllen etc.). Das selbe Problem tritt auf, wenn man ein Update einer Komponente installieren möchte. Dafür muss ein Mitarbeiter zu jedem Entwickler an den Arbeitsplatz und die Installationsschritte ausführen. Durch diese individuellen Lösungen kommt es natürlich auch dazu dass jede Installation unterschiedlich sein kann und so schleichen sich leicht Fehler ein.

Gibt es einen Weg mit Delphi die Installationen für alle Entwickler gleich zu halten? Ich dachte bereits daran, Delphi auf einem Terminalserver zu installieren, jedoch auch dort muss für jeden Benutzer Delphi separat eingerichtet werden. Hat jemand Erfahrungen, wie das in größeren Firmen gehandhabt wird?

Vielen Dank im Voraus.

[Der schöne Günther]

Oh, das würde mich langsam auch mal wirklich interessieren. Embarcadero hatte in einer Umfrage ja mal danach getastet, wie die Akzeptanz für eine Art "Embarcadero Component Store" wäre. So etwas könnte ja schonmal automatisch für aktuelle Fassungen der Komponenten auf jedem PC sorgen...

[jaenicke]

Wir haben Projektgruppen mit den zu installierenden Packages usw. und ich habe eine Anleitung erstellt was in welcher Reihenfolge installiert werden muss. Die Komponenten selbst usw. liegen natürlich im Repository, so dass jeder einfach nur auschecken und das betreffende Package neu installieren muss.

Wenn das alles sauber eingerichtet ist, hat auch jeder den gleichen Stand. Und wenn die Anzahl größer ist, könnte man das auch per Skript automatisieren, bei uns ist das nicht nötig.

Die Frage ist natürlich was das für Komponenten sind. Wir versuchen möglichst wenige Fremdkomponenten einzusetzen, so dass die Anzahl der Abhängigkeiten relativ gering ist. Und wenn wir externe Komponenten nutzen, dann ausschließlich mit Quelltexten, so dass auch die im Repository liegen.

[Der schöne Günther]

Wie handhabt Ihr das denn, wenn eine Komponente geupdatet werden sollte? Das muss ja doch jedem manuell mitgeteilt werden und eventuell muss Quelltext der die Komponenten benutzt angepasst werden.

Am Beispiel TeeChart: Das Teil hatte in der Version von Anfang 2013 einen Bug der unter bestimmten Voraussetzungen den Speicher volllaufen ließ, da musste unbedingt geupdatet werden.

Weiteres Beispiel TeeChart: Wir haben das Ding auch gleich mit Quelltext gekauft, aber ich sehe wieder etliche Stunden Arbeit vor mir, mich da reinzufriemeln, da ein schönes Package direkt fürs Repo draus zu basteln. Stattdessen haben wir dann doch wieder nur die "Setup.exe" genommen.

[himitsu]

Das Problem ist aber auch, daß nicht unbedingt alle Einstellungen synchron gehalten werden drürfen, bzw. daß man auswählen können sollte was da synchronisiert wird, denn einige Programmierer richten sich ihr system ja persönlich ein, so wie sie es brauchen.

Wenn die Benutzerprofile auf einem zentralen rechner liegen, dann kann man sich ein "Neue Mitarbeiter"-Profil anlegen, welches nach der Einstellung einfach geklont wird.
Oder wenn die Delphis und die gemeinstamen Komponenten auf auf dem selben Rechner am gleichen Ort liegen, dann würde es z.B. reichen die entsprechenden Registrypfade zu kopieren.



Aber ein App-Store wäre etwas praktisches, dann hätte man auch ml ein zentrales System, worüber man auch Updates der Komponenten verteilen könnte.
Aber das Ding sollte dann nicht direkt in die Delphi-IDE integriert, sondern müsste auch als Addon auch in älteren Versionen installierbar sein.
Und wenn man es genau nimmt, dann könnten wir uns sowas dann auch selber erstellen.

[Guido R.]

Wie wäre es mit einer VM ?
Ein einfaches System nur mit den Entwickler-Tools.
Wird eine neue Komponente benötigt wird die auf der zentralen VM installiert und an alle Arbeitsstationen kopiert.
Damit wären alle Entwickler auf dem selben Stand.

(entsprechende Lizenzen für OS und Entwickler-Tools, sowie ausreichend leistungsfähige Hardware natürlich vorausgesetzt)

[OlliWW]

Zitat:

Zitat von himitsu (Beitrag 1242517)

Oder wenn die Delphis und die gemeinstamen Komponenten auf auf dem selben Rechner am gleichen Ort liegen, dann würde es z.B. reichen die entsprechenden Registrypfade zu kopieren.

Deswegen dachte ich an einen Terminalserver

[FBrust]

Hallo,

Zitat:

Zitat von Guido R. (Beitrag 1242518)

Wie wäre es mit einer VM ?

So machen wir es. Die VM, die als Grundlage dient, wird von Zeit zu Zeit auf den neuesten Stand gebracht und dann an alle Entwickler verteilt, hat sich bewährt.


Gruß
Frank

[OlliWW]

Aber die VM wird unter einem "pseudo" Benutzer eingerichtet.
Sobald ich mich mit einem richtigen Domänen Benutzer einloggen auf der geklonten VM muss ich doch eh wieder vieles neu einrichten, weil es ein anderes Benutzerprofil ist.

[himitsu]

Hat die VM nicht auch den "Nachteil", daß man sich die IDE-Oberfläsche nicht personalisieren kann?
- vorallem welche Fensterchen wann und wo an welcher Stelle angezeigt werden
- oder der Eine arbeitet lieer mit GExperts und der Andere mit CnPack und der Dritte mag nur je einen Teil von allem
- ...

[Uwe Raabe]

Bei meinen Projekten verwende ich immer die Sourcen der Bibliotheken, die auch in der Versionsverwaltung mit vorgehalten werden. Damit ist immer gewährleistet, daß ein Quellcode-Stand immer mit den dazu passenden Bibliothekssourcen compiliert wird. Die Pfade zu den Bibliotheken stehen immer in den Projektoptionen - niemals in den globalen Bibliothekspfaden. Wenn man das konsequent pflegt (also nicht mehr benötigte rauswerfen) hat man auch gleich eine Kontrolle darüber, welche Bibliotheken für ein Projekt wirklich benötigt werden.

Bei den installierten Packages haben wir das in meiner früheren Firma so gehalten, daß die BPL- und DCP-Dateien immer von einer zentralen Stelle in die entsprechenden Pfade der IDE kopiert wurden (z.B. $(BDSCOMMONDIR)\Bpl und $(BDSCOMMONDIR)\Dcp). Dazu gab es dann noch je Delphi-Version eine REG-Datei, in der die nötigen Einträge zur Registrierung der Packages stehen (also vorwiegend Einträge für Known Packages). Damit reduziert sich die Installation der Packages in die IDE auf einen simplen Kopiervorgang und einen Doppelklick auf die Reg-Datei mit anschießender Bestätigung.

Es gab dann halt immer einen, der die Sachen passend bereitlegen musste - also Packages erzeugen installieren, aus dn beiden Verzeichnissen im Netz ablegen und die REG-Datei pflegen. Dazu wird meistens der komplette Registry-Zweig exportiert und dann alles überflüssige rausgelöscht. Gegebenenfalls müssen dabei die Pfade noch auf Environment-Variable geändert werden. Allerdings ändert sich die REG-Datei nur selten.

Ich verwende dieses Verfahren immer noch für meine diversen Delphi-Installationen auf unterschiedlichen Systemen (PC, Notebook, VMs).

[Der schöne Günther]

Ich weiß bis heute nicht für das DCP und BPL-Dateien eigentlich gut sind und wo sie auftauchen- Wenn ich das richtig sehe, hätte dann aber jeder "nur" die bereits kompilierten Packages und kann somit, trotz eventuell gekauften Quelltext im Debugging-Fall nicht direkt durch die Innereien der Komponenten steppen.

[OlliWW]

Vielen Dank für die ausführliche Erklärung Uwe.

Ähnliche Ansätze haben wir auch schon verfolgt bzw. uns gedacht dass es darauf hinaus laufen wird.

Wie dem Verlauf des Threads entnehmen kann, scheint es leider keine pauschale Lösung zu geben, obgleich das Interesse daran anscheinend sehr hoch ist.

Die Sourcen in jeweils mit in die Versionsverwaltung mit aufzunehmen und bei jedem erstellen einer Programmversion mit zu kompilieren halte ich, zumindest bei uns, für nicht durchführbar, da unser Softwareprojekt schon über 2000000 Zeilen Code besitzt und das neu kompilieren der Komponentensourcen jedes mal noch mehr Zeit in Anspruch nehmen würde.

[Der schöne Günther]

In Delphi-speziellen Dingen sollte man mir am besten nicht überhaupt nicht zuhören. Aber das ist doch nur beim allerersten Kompilieren so? Danach existieren lokal die DCUs und soweit sich der Quelltext der Komponenten nicht ändert, werden die auch nicht neu kompiliert?

[jaenicke]

Es sei denn man erstellt das Projekt neu. Deshalb liegen bei uns auch nur die .dcu Dateien im Bibliothekspfad und die Quelltexte im Suchpfad. Die .dcu Dateien werden über ein Package erstellt, in dem die Quelltextunits alle hinzugefügt sind.

Man kann natürlich auch nur die Debug- und Release-DCUs sowie die kompilierten Packages verteilen und die Pfade lokal entsprechend setzen.

[Bernhard Geyer]

Zitat:

Zitat von OlliWW (Beitrag 1242534)

Die Sourcen in jeweils mit in die Versionsverwaltung mit aufzunehmen und bei jedem erstellen einer Programmversion mit zu kompilieren halte ich, zumindest bei uns, für nicht durchführbar, da unser Softwareprojekt schon über 2000000 Zeilen Code besitzt und das neu kompilieren der Komponentensourcen jedes mal noch mehr Zeit in Anspruch nehmen würde.

Delphi 6, 1,9 Mio Quellcodezeilen, Kompletter Rebuild: ca. 11 Sekunden (ohne SSD)
Sollte bei euch auch nicht viel länger dauern.

[Uwe Raabe]

Zitat:

Zitat von OlliWW (Beitrag 1242534)

Wie dem Verlauf des Threads entnehmen kann, scheint es leider keine pauschale Lösung zu geben, obgleich das Interesse daran anscheinend sehr hoch ist.

Natürlich muss jeder das System finden, das für ihn am besten funktioniert. Man sollte die Vorschläge hier deshalb auch als genau solche verstehen.

Zitat:

Zitat von OlliWW (Beitrag 1242534)

Die Sourcen in jeweils mit in die Versionsverwaltung mit aufzunehmen und bei jedem erstellen einer Programmversion mit zu kompilieren halte ich, zumindest bei uns, für nicht durchführbar, da unser Softwareprojekt schon über 2000000 Zeilen Code besitzt und das neu kompilieren der Komponentensourcen jedes mal noch mehr Zeit in Anspruch nehmen würde.

Wie Günther schon erwähnte kommt das beim Compile ja nur einmal zum tragen. Bei einem Build aber natürlich jedesmal wieder. Alternativ kann man das aber auch leicht abgewandelt handhaben: beim Update aus dem Repo (ich verwende Mercurial) wird über einen entsprechenden AfterUpdate-Hook eine einmaliges Compilieren der Bibliotheken angestoßen. Danach stehen dann die DCUs zur Verfügung. Der Hook garantiert lediglich das automatische Synchronisieren der Sourcen mit den DCUs, ansonsten kann man das auch manuell erledigen. Von einer Versionierung der DCUs selbst würde ich allerdings abraten.

Der Vorteil der Sourcen ist halt, daß sie immer mit den gleichen Compilerschaltern compiliert werden wie das Projekt selbst. Das erspart z.B. separate Verzeichnisse für die Debug-DCUs.

Natürlich kommt es auch auf den Anteil der Komponentensourcen am gesamten Code-Volumen an. Wenn zu den 2 Mio. Zeilen für eure eigenen Sourcen vielleicht nur 0.5 Mio. für Bibliotheken hinzukommt, sollte der Zeitverlust bei einem Build gerade mal 25% betragen. Sind das aber zusätzlich 4 Mio. sieht das sicher schon anders aus.

Im Übrigen kann man mit einer SSD schon einiges wieder herausholen.