Ich teste immer in Prod, weil da die realistischsten Bedingungen sind
Habe mal erlebt wie Entwickler eine Flag in nen Service eingebaut haben um die Warnungen in der spärlich konfigurierten Testumgebungen auszuschalten und sich dann wundern, wenn in Produktion Störungen auftreten, deren Tests sie aus Genervtheit deaktivierten
Das war doch jetzt ne Woche auf Test, können sie das bitte auf Prod pushen?
Haben sie denn getestet auf Test?
Nein, wieso?
Richtige Männer patchen in der Produktion.
Meine weibliche Intuition hatte mir dann doch zu einer Rückwärtsrolle und ausreichend Zeit zur Fehlersuche geraten
Aber warum hält eure kontinuierliche Integration / kontinuierlicher Versand Fernleitung eine Entsendung nach produktiv nicht auf, wenn die Tests Fehler nachweisen?
Weil das kein ordentlicher integrierter Prozess ist und weil von innerhalb der Firma (in Portugal) für innerhalb der Firma (in de) gearbeitet wird, sieht man das alles auch nicht so eng...
Keine Ficks zu geben. ¯\(ツ)/¯
Ich lern das noch. Aber jetzt gerade gießt das einfach nur noch Kaffee in die Gastritis oder so
...und genau deswegen macht man einen Schutz auf
mainund lässt nur Merge-Requests dorthin zu, die einen erfolgreichen Lauf der (Test-)Pipeline absolviert haben.Wenn jemand kaputte Commits in einen eigenen dev-Brach macht, ist mir das meistens Recht egal...
Kommt drauf an ob da ein Squash kommt oder nicht. Im schlimmsten Fall sind nicht ausführbare Commits in Verlauf und dann geht bisect und so nicht mehr.
Na immerhin steht dann dessen Name dran und nicht deiner. Kannst ja bei der nächsten Retro anbringen :)
Oder der hochbegabte Manager lässt sich die Logs zeigen und sieht dann neben den ganzen Fehlermeldungen @ComfortableRaspberry@feddit.org als Autor der Tests.
“If we stopped testing right now, we'd have very few cases, if any.” — President Donald Trump
Ohne Witz: mein vorletzter AG, kleines Softwarehaus für so Personalzeug entscheidet sich im Jahr 2018 dafür eine QA Abteilung zu gründen. Himbeere soll sich bisschen weiterbilden für Testautomatisierung, noch 2 Kollegys dazu (das waren auch zwei ganz besondere Kandidatys) und dann geht's ab. Gesagt getan, waren dann auch recht erfolgreich und haben einige Bugs gefunden. Deshalb wurde die Abteilung dann nach 2 Jahren wieder aufgelöst weil man das ja gar nicht alles beheben könne.
Sagt mein Chef auch. Weniger Zeit für Tests vergäuden, effizienter coden!
Haben Montag das nächste Meeting in der passenden Runde. Da werde ich das nochmal zum Anlass nehmen, um meinen Vortrag "Verlorenes Vertrauen gewinnen wir nur schwer zurück! Und 10 weitere Gründe ein Update im Zweifel auch mal aufzuschieben ¯\(ツ)/¯ " zu halten. Vielleicht hört ja mal jemand zu
