1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Macbook Pro: Mobile…

Buildserver?

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. Buildserver?

    Autor: pica 07.11.21 - 16:47

    Meine Erfahrung mit Buildservern sind gut. So ein nettes 2 Sockelsystem mit 'nem Terabyte RAM, so dass sämtliche Quelltexte, Objectfiles, etc im RAM gecashed sind kompiliert ganz schön schnell.

    Gruß,
    pica

  2. Re: Buildserver?

    Autor: OMGle 07.11.21 - 17:45

    pica schrieb:
    --------------------------------------------------------------------------------
    > Meine Erfahrung mit Buildservern sind gut. So ein nettes 2 Sockelsystem mit
    > 'nem Terabyte RAM, so dass sämtliche Quelltexte, Objectfiles, etc im RAM
    > gecashed sind kompiliert ganz schön schnell.

    Benutzest du beim Programmieren wirklich einen Build-Server?
    Ich meine nicht den Deployment-Prozess, sondern das ganz normal Programmieren: du öffnest ein Jira-Ticket, veränderst im Quell-Code ein Paar Zeilen, speicherst und ab geht's an den Build-Server, dann lädst du das Binary herunter und führst auf deiner Maschine aus, um zu sehen, dass du einen Minus vergessen oder die falsche Variable inkrementiert hast, dann korrigierst du den Tippfehler und schickst du das ganze wieder an den Build-Server?

  3. Re: Buildserver?

    Autor: pica 07.11.21 - 18:01

    Die Entwicklungsumgebungen, die ich verwende haben im Hintergrund einen Language Server laufen und melden derart triviale Fehler.
    Und warum ist ein Ticket notwendig um einen Build zu starten? Ein commit&push tut es auch für nicht release builds. Da ich eh nach jeder in sich geschlossenen Änderung ein commit&push in einem eigenen Branch mache, ist dies für mich kein Mehraufwand.

    Gruß,
    pica

  4. Re: Buildserver?

    Autor: OMGle 07.11.21 - 18:09

    pica schrieb:
    --------------------------------------------------------------------------------
    > Die Entwicklungsumgebungen, die ich verwende haben im Hintergrund einen
    > Language Server laufen und melden derart triviale Fehler.
    > Und warum ist ein Ticket notwendig um einen Build zu starten? Ein
    > commit&push tut es auch für nicht release builds. Da ich eh nach jeder in
    > sich geschlossenen Änderung ein commit&push in einem eigenen Branch mache,
    > ist dies für mich kein Mehraufwand.

    Aha, du pushst jede Änderung?
    Ich weiß nicht, was du da programmierst, ich versuche es mir vorzustellen: du veränderst Koordanaten eines Controls oder irgendeinen Text und willst sehen, wie es in der Anwendung aussieht, machst du commit/push und testest. Dann willst du die Schriftgröße etwas verkleinern, veränderst eine Zahl und machst commit/push etc.
    So geht's natürlich auch, dann braucht man gar keinen "echten" Rechner mehr, dazu reicht auch eine IDE im Browser.

  5. Re: Buildserver?

    Autor: pica 07.11.21 - 18:27

    Gut ich programmiere in der Regel Frameworks und Transformationen um aus z.B. UML oder BPMN oder anderen Modellen Quelltexte, Konfigurationsdateien, Dokumente oder andere Artefakte zu erstellen. OK, die Frameworks und/oder Transformationen muss ich natürlich auch Testen. Dann erstelle ich Demo-Anwendungen, mehr oder weniger auf Hello World Niveau.

    Programmiersprachen sind neben Java, auch C/C++ zumeist mit MISRA Profil, MOFM2T und ATL.

    Ist eher eine exotische Nische, gebe ich zu.

    Gruß,
    pica

  6. Re: Buildserver?

    Autor: GL 07.11.21 - 18:50

    OMGle schrieb:
    --------------------------------------------------------------------------------
    > Benutzest du beim Programmieren wirklich einen Build-Server?
    > [..] du öffnest ein Jira-Ticket, veränderst im Quell-Code ein
    > Paar Zeilen, speicherst und ab geht's an den Build-Server, dann lädst du
    > das Binary herunter und führst auf deiner Maschine aus, um zu sehen, dass
    > du einen Minus vergessen oder die falsche Variable inkrementiert hast, dann
    > korrigierst du den Tippfehler und schickst du das ganze wieder an den
    > Build-Server?

    Tss... also der übliche Workflow sollte heute so aussehen:

    1. Ticket lesen
    2. Branch anlegen
    3. Ticket lösen, d.h. Funktionalität implementieren und TESTs schreiben
    4. neue Tests grün und ggf. Funktionalität soweit möglich lokal getestet: Dann Merge/Pull-Request erstellen
    5. MR/PR triggert Build, je nach Projekt mit allen oder zumindest wesentlich mehr Tests
    6. Tests alle grün: manuelle Review vom Kollegen, sonst zurück zu 3
    7. Kollege hat Verbesserungsvorschläge: zurück zu 3, sonst
    8. Merge MR/PR, Close Ticket -- was danach passiert, ist eine Frage des DevOps bzw. des Prozesses (Continuous Deployment, QA-Environment, Sprint-Ende abwarten, etc.)

    und back to 1. So sieht das moderne Programmiererhamsterrad aus. Wer den Build-Server für den Bau des Binaries braucht, hat was nicht verstanden.

  7. Re: Buildserver?

    Autor: gadthrawn 08.11.21 - 06:44

    GL schrieb:
    --------------------------------------------------------------------------------
    > OMGle schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Benutzest du beim Programmieren wirklich einen Build-Server?
    > > [..] du öffnest ein Jira-Ticket, veränderst im Quell-Code ein
    > > Paar Zeilen, speicherst und ab geht's an den Build-Server, dann lädst du
    > > das Binary herunter und führst auf deiner Maschine aus, um zu sehen,
    > dass
    > > du einen Minus vergessen oder die falsche Variable inkrementiert hast,
    > dann
    > > korrigierst du den Tippfehler und schickst du das ganze wieder an den
    > > Build-Server?
    >
    > Tss... also der übliche Workflow sollte heute so aussehen:
    >
    > 1. Ticket lesen
    > 2. Branch anlegen
    > 3. Ticket lösen, d.h. Funktionalität implementieren und TESTs schreiben
    > 4. neue Tests grün und ggf. Funktionalität soweit möglich lokal getestet:
    > Dann Merge/Pull-Request erstellen
    > 5. MR/PR triggert Build, je nach Projekt mit allen oder zumindest
    > wesentlich mehr Tests
    > 6. Tests alle grün: manuelle Review vom Kollegen, sonst zurück zu 3
    > 7. Kollege hat Verbesserungsvorschläge: zurück zu 3, sonst
    > 8. Merge MR/PR, Close Ticket -- was danach passiert, ist eine Frage des
    > DevOps bzw. des Prozesses (Continuous Deployment, QA-Environment,
    > Sprint-Ende abwarten, etc.)
    >
    > und back to 1. So sieht das moderne Programmiererhamsterrad aus. Wer den
    > Build-Server für den Bau des Binaries braucht, hat was nicht verstanden.

    Ehrlich gesagt: nö. Schon vor 10 Jahren hat man Test vor sie Tests vor Funktionalität geschrieben.

    Und build Server dazu genutzt, das nicht jeder mit sanfter Konfiguration baut.

    Build Server sind älter wie der Begriff CI.

  8. Re: Buildserver?

    Autor: tritratrulala 08.11.21 - 08:52

    GL schrieb:
    > 1. Ticket lesen
    > 2. Branch anlegen
    > 3. Ticket lösen, d.h. Funktionalität implementieren und TESTs schreiben
    > 4. neue Tests grün und ggf. Funktionalität soweit möglich lokal getestet:
    > Dann Merge/Pull-Request erstellen
    > 5. MR/PR triggert Build, je nach Projekt mit allen oder zumindest
    > wesentlich mehr Tests
    > 6. Tests alle grün: manuelle Review vom Kollegen, sonst zurück zu 3
    > 7. Kollege hat Verbesserungsvorschläge: zurück zu 3, sonst
    > 8. Merge MR/PR, Close Ticket -- was danach passiert, ist eine Frage des
    > DevOps bzw. des Prozesses (Continuous Deployment, QA-Environment,
    > Sprint-Ende abwarten, etc.)
    >
    > und back to 1. So sieht das moderne Programmiererhamsterrad aus. Wer den
    > Build-Server für den Bau des Binaries braucht, hat was nicht verstanden.

    Laut dir und einigen anderen Postern hier leben wir anscheinend in einem feuchten Traum des Software Engineering. :D Wenn ich hier zu diversen Themen der Softwareentwicklung Posts lese, habe ich jedenfalls oft den Eindruck, dass viele in einer idealisierten, theoretischen Welt leben, nicht in der Realität. Geradezu so wie Absolventen ohne berufliche Erfahrung.

    Um beim Thema zu bleiben: Um mit wenig Overhead lokal zu testen musst du doch Binaries auch lokal bauen. Vielleicht nicht alles vom Projekt, aber zumindest eben genug, um Unit Tests & co auszuführen. Bei großen Projekten kann das auch schon sehr viel sein. Es ist auch nicht ungewöhnlich, dass man die ganze Applikation lokal hochfährt und ein paar Integrationstests durchführt. Teilweise auch manuell, denn, Überraschung, in der Realität lässt sich nicht alles perfekt automatisieren.

    Mit modernen IDEs wie z.B. VSCode kann man die gesamte Arbeit remote ausführen, auch den language server, aber das hat dann diverse tradeoffs. Genau wie Arbeit per Remote Desktop. Und beides klappt natürlich nur bei entsprechender Netzwerkverbindung. Lokal zu arbeiten hat daher noch immer einen großen Wert!



    1 mal bearbeitet, zuletzt am 08.11.21 08:55 durch tritratrulala.

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Produktberater (m/w/d) Personal-Software
    Stiftung Kirchliches Rechenzentrum Südwestdeutschland, Eggenstein-Leopoldshafen
  2. Sachbearbeiter (m/w/d) Digitalisierung
    Stadt Korntal-Münchingen, Korntal-Münchingen
  3. Informatiker / Informatikerin (m/w/d) im Rechenzentrum
    Helmut Schmidt Universität / Universität der Bundeswehr Hamburg, Hamburg
  4. Product Owner (w/m/d)
    Lebensversicherung von 1871 a. G. München, München

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 149€ (UVP 189€)
  2. (Hardware, PC-Zubehör, Notebooks uvm. reduziert)
  3. 39,99€ (Bestpreis!)
  4. (u. a. G.Skill Trident Z Neo 32-GB-Kit DDR4-3600 für 149€ statt 190,64€ im Vergleich, Patriot...


Haben wir etwas übersehen?

E-Mail an news@golem.de