In Bezug auf https://www.delphipraxis.net/1407726-post13.html mal eine Frage:
Speziell Delphi hat immer noch einen der schnellsten Compiler und rödelt durch Millionen Zeilen (je nach Rechner) innerhalb von einer Minute. Was genau macht jetzt einen Buildserver erforderlich, vor allem, wenn man nicht jedesmal alle Bitigkeiten und Architekturen bauen muss, um diese dann in ihre jeweiligen Installer zu packen?

Ohne irgendwem zu nahe treten zu wollen:
Wozu ist also ein Buildserver noch gut, daß man angesichts eines geschenkten Gauls noch Enttäuschung verspüren könnte?

Sherlock

Zitat von Sherlock:

In Bezug auf https://www.delphipraxis.net/1407726-post13.html mal eine Frage:
Speziell Delphi hat immer noch einen der schnellsten Compiler und rödelt durch Millionen Zeilen (je nach Rechner) innerhalb von einer Minute. Was genau macht jetzt einen Buildserver erforderlich, vor allem, wenn man nicht jedesmal alle Bitigkeiten und Architekturen bauen muss, um diese dann in ihre jeweiligen Installer zu packen?

Ohne irgendwem zu nahe treten zu wollen:
Wozu ist also ein Buildserver noch gut, daß man angesichts eines geschenkten Gauls noch Enttäuschung verspüren könnte?

Sherlock

Gute Frage. Für die Zielgruppe der Community-Edition seh ich jetzt keinen Bedarf an einem Build-Server.

Zitat von Sherlock:

Wozu ist also ein Buildserver noch gut, daß man angesichts eines geschenkten Gauls noch Enttäuschung verspüren könnte?

Bei einem Build-Server geht es in erster Linie nicht darum, dass es Zeit kostet, sondern um andere Dinge, z.B.:

• Stabile Umgebung ohne Änderungen, zu Test neuer Möglichkeiten
• Automatisierte Tests, welche durchaus länger dauern können
• Wiederholbarkeit von Builds unter identischen Bedingungen
• Sicherer Verwaltung von Zertifikaten (z.B.: Code-Signierung)
• In keiner Firma sind die Rechner aller Kollegen komplett identisch, daraus können sich unterschiedliche Builds trotz gleichen Quellcodes ergeben

......

Sakura, das verstehe ich. Eine kleine Firma, die trotz mageren 5000€ Umsatz mehrere Entwickler beschäftigt, hat allerdings Sorgen, die nicht durch einen Buildserver zu beseitigen sind.

Lassen wir mal Firmen aussen vor, lassen wir ferner mehrere Entwickler aussen vor. Konzentrieren wir uns auf die Zielgruppe: "Hobbyisten"

Sherlock

CnPack ist so ein Hobbyisten-Projekt mit einem Build-Server.

Nur damit man ein konkretes Beispiel hat, worum es geht.

Nein, meiner Meinung nach sind die aktuellen Limitierungen der CE völlig in Ordnung.

Zum Nachlesen:

https://docs.microsoft.com/en-us/azu...us-integration
https://www.joelonsoftware.com/2001/...e-your-friend/

Ein Buildserver kümmert sich ja nicht nur um das Kompilieren, sondern kann den ganzen Buildprozess automatisieren:
- Bereitstellen/Zurücksetzen von Ressourcen
- Installation erzeugen
- Erzeugen anderer Dokumente/Daten/Dateien
- Dokumente aufbereiten
- Code signieren
- Infos bereitstellen/versenden

Sowas alles kann man aber auch mit FinalBuilder und Co. lokal machen.

Bei mehreren Entwicklern oder auch alleine an mehreren Rechnern (HomePC, Schlepptop, Arbeitsrechner, Windows-Tablet, ...) :
* wie der sakura schon sagte, hat man nicht alles überall installiert (Fremdkomponenten, Zertifikate, ...) und auch nicht überall gleich
* ja, auch die Dauer kann ein Grund sein, wenn der Build (und eventuelle Zusätzliches) ewig dauert und viele Ressourcen (CPU, RAM, HDD) benötigt
** es gibt größere Projekte, da dauert das schonmal paar Stunden, bis alles durch ist (auch Freeware/OpenSource)

Und dann das schon angesprochene Thema CI
https://de.wikipedia.org/wiki/Kontin...he_Integration

PS: Sowas kann man auch an andere Prozesse hängen.
z.B. beim Checkin in SVN/GIT/... automatisch Tests und den Build zuzüglich Bereitstellung (inkl. Installationsdateien auf Webseite hochladen) anstoßen

Du kannst dein SVN/GIT auf einem NAS ablegen und dort via Docker ein Buildsystem drauf, was dann diesen Build + eventuelle Tests erledigt. Bei Problemen bekommst du dann z.B. ne Mail.
Privat bin ich auch ein einsamer Entwickler und will demnächst mich mit dem Docker beschäftigen ... AndroidVM und ein paar Windows mit den verschiedenen Delphis (früher hatte ich das auf dem PC, aber Speicher auf Schlepptops ist auch nicht viel da und da ich diese VMs eh nicht dauernd benötige ...)
https://www.youtube.com/watch?v=GWNr4BAN-Kc

Zitat von himitsu:

Sowas alles kann man aber auch mit FinalBuilder und Co. lokal machen.

FinalBuilder ist ein Buildserver . Und ob so was nun lokal oder remote läuft ist unwesentlich. Wichtig ist das Prinzip. Vereinheitlichung und Absicherung der Qualität und Vollständigkeit. Wie oft passiert es, dass neu erstellte units nicht zum Repository geaddet werden - von einem selber oder von Kollegen. Kopmpiliert ja. Ein Buuildserver checkt aber alles immer frisch aus, so findet man auch solche Fehler, die evtl. erst rauskommen wenn man die VM, Rechner oder USB Disk wechselt und der Meinung ist, man könnte alles aus dem Repository holen. Die bereits erwähnten automatisierten unittests gehören natürlich auch dazu.

Zitat von Union:

FinalBuilder ist ein Buildserver

Falsch, FinalBuilder ist ein Tool, kein ganzer Server, mit welchem sich Build-Prozesse steuern lassen.

......

Puh, da eröffnen wir jetzt die Diskussion über den Unterschied Server (Hardware) und Server (Software)?