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

Ich bin nicht überzeugt

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. Ich bin nicht überzeugt

    Autor: GwhE 04.04.21 - 22:17

    Erstmal ein schöner Artikel und ein intresantes Thema.

    Bin aber immer noch nicht überzeugt. Die Frage ist ja welches problem will man damit lösen. Meisten lese ich die tests sind nicht alle fertig aber code soll schon in prod. Und wenn was schief läuft dann ist es ja nicht schlimm kann es ja "einfach" wieder zurück drehen. aber hier schreibt der autor ja auch das es der falsche grund ist. Dann lieber sein CI/CD pipline besser automatisieren. Dort kann man auch fachliche test automatisieren. Und auch das A/B pattern verstehe ich nicht wirklich warun dort nicht eine pilotierung einsetzten kann, wenn man es so oft braucht.

    Wie gesagt man lädt sich hier sehr viel komplexität in den code. Und ein "einfaches" zurückdrehen scheint ja mehr vom Glück habzuhängen als von einem geplannten vorgehen.

  2. Re: Ich bin nicht überzeugt

    Autor: amagol 04.04.21 - 23:21

    GwhE schrieb:
    --------------------------------------------------------------------------------
    > Meisten lese ich die tests sind nicht alle fertig aber
    > code soll schon in prod.

    Wenn Tests micht gleichzeitig mit dem Code fertig sind, hat man ein Problem. Da helfen verder Feature Flags noch irgendwas anderes (ausser Tests natuerlich).

    > Und auch das A/B pattern verstehe ich nicht wirklich warun dort nicht eine
    > pilotierung einsetzten kann, wenn man es so oft braucht.

    Stell dir vor du hast jede Woche 100 neue Features - jedes davon hat potentiell Einfluss auf deine Verkaufszahlen. Wie stellst du fest welche davon Erfolgreich waren und welche nicht? A/B Tests sind da sehr hilfreich.

    > Wie gesagt man lädt sich hier sehr viel komplexität in den code.

    Es kommt darauf an. Oft ist es einfach nur ein "if (flag.isEnabled) then A else B", wober B der alte Code ist den man ein paar Wochen nach erfolgreichem Start wegwirft.

    > Und ein "einfaches" zurückdrehen scheint ja mehr vom Glück habzuhängen als von
    > einem geplannten vorgehen.

    Es ist einfach und mit Glueck hat das wenig zu tun. Natuerlich bleibt bei jeder Aenderung ein Restrisiko - und die Aufraeumarbeiten muessen halt gemacht werden.

    Meine Erfahrung basiert hier auf Webanwendungen/Microservices die gehostet werden. Bei Software die an Kunden ausgeliefert wird stelle ich mir Feature Flags problematischer vor.

  3. Re: Ich bin nicht überzeugt

    Autor: GwhE 05.04.21 - 09:37

    Gegen das A/B testing habe auch gar nichts. Gerade wenn man eine saubere Microservice Architektur hat man aber doch die möglichkeiten auch 100 unterschiedliche Atifakte zu deployen.

    Und ja das aufräumen hat was mit Glück zu tun. Wenn ich dann im code schnittstellen habe wie gewährleiste ich als Entwickler das der code auch ohne feature 65 aber mit feature 52 funktioniert. Hier im Forum war der vergleich zu globalen Variabeln den ich gut fande. Es geht ja nicht darum das an einer einzigen stelle im code ein if then else steht. Sondern an mindestens zwei verschiedenen. Um alles dann sauber zu refactoren und sicherstellen das es mit feature 45 und 68 geht aber nicht mit feature 23. braucht man ausreichend tests. Das wären in dem fall dann sowas wie O (100!), ansonstent ist es glück das der code auch in einer zufaälligen feature kombi funktioniert.

  4. Re: Ich bin nicht überzeugt

    Autor: CalebR 05.04.21 - 18:15

    Für mich ist der Hauptpunkt warum wir es etablieren um bei Trunk basierter Entwicklung und mit einer guten CI/CD wirklich den Code ständing zu deployen und damit von den klassischen Release Zyklen weg zu kommen. Wir wollen damit den klassischen Effekt von "Entwickler hat was über den Zaun geworfen" entgegenwirken und auch der Entwickler erhält ein besseres Feedback bei der CI/CD da er weiß, ein Fehler ist nicht durch die letzten 500 commits gekommen sondern durch seine Änderungen.

    Ja und wo kommen hier Feature Toggles mit rein? Wir verwenden Sie um den Businesscase vom Deployment zu trennen. D.h. Product Owner will FeatureX, der Entwickler setzt das Feature um und gibt ihm einen Toggle und die Software wird deployed mit dem Feature ausgeschaltet.

    Je nach Feature Toggle Tool kann jetzt QA das ganze in der passenden Umgebung testen und freigeben. Zum Abschluss kann der Product Owner das Feature zu einem mit Kunden oder Partner vereinbarten Termin freigeben - der Entwickler braucht jetzt nur noch ein Ticket mit dem er den Toggle wieder ausbauen kann und das neue Feature bleibt, ggf. alter Code kommt raus.

    Wichtig dabei: Der Code kann ständig deployed und angepasst werden und die Änderungen sind verhältnismäßig klein. Man braucht aber auch ein voll automatisiertes Deployment.

  5. Re: Ich bin nicht überzeugt

    Autor: GwhE 06.04.21 - 09:31

    Ok danke für das beispiel.

    Was man nicht kennt ist erstmak immer schlecht.

    Klingt aber erstmal gut so wie ihr es einsetzt. Dann würde ich es als DevOps tool sehen um software in prod zu bringen, und nicht als programier pattern.

  6. Re: Ich bin nicht überzeugt

    Autor: CalebR 08.04.21 - 10:37

    GwhE schrieb:
    --------------------------------------------------------------------------------
    > Ok danke für das beispiel.

    Sehr gerne :-)

    > Was man nicht kennt ist erstmak immer schlecht.

    Geht mir auch nicht anders ^^

    > Klingt aber erstmal gut so wie ihr es einsetzt. Dann würde ich es als
    > DevOps tool sehen um software in prod zu bringen, und nicht als programier
    > pattern.

    Ja und nein. Ich würde den Status als Kompliziert einstufen, da es davon abhängt was du als DevOps betrachtest. Meine Arbeit besteht derzeit darin Entwickler darin Entwickler zu unterstützen und zu schulen DevOps Methodiken und Tools einzusetzten - im wesentlichen lässt sich das auf dieses DevOps Roundell reduzieren ( http://veilleweb2.fr/wp-content/uploads/2016/06/DevOps-cycle-PPT-COLOURS-Copy.png ).

    Am Ende müssen aber Personen die auf die Programmierung (Entwickler) spezialisiert sind den Prozess begleiten, verstehen und vor allem anwenden. Es ist also wirklich ein Umgang mit dem Code um einen anderen Schnitt zwischen Produkt und Projekt machen zu können, zumindest in dem Einsatz den ich kenne.

  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. Wissenschaftliche Mitarbeiter*innen mit dem Schwerpunkt (Satelliten-)Fernerkundung
    Umweltbundesamt, Berlin, Leipzig, Dessau-Roßlau
  2. Softwareentwickler (m/w/d) automatisiertes und hochautomatisiertes Fahren
    e:fs TechHub GmbH, Wolfsburg
  3. Product Manager ERP- und POS-Systeme (m/w/d)
    beauty alliance IT SERVICES GmbH, Bielefeld (Home-Office)
  4. DevOps Engineer (m/w/d)
    Deutsche Bundesbank, Hamburg, Leipzig, Düsseldorf, Frankfurt am Main, Stuttgart, München

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. ab 34,99€
  2. 49,99€ (inkl. Bonusmission "Die vierzig Räuber")
  3. (u. a. TESO High Isle - Collector's Edition für 35,99€ statt 79€)


Haben wir etwas übersehen?

E-Mail an news@golem.de