Nach einer wahren Begebenheiten
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…
Ich teste immer in Prod, weil da die realistischsten Bedingungen sind
…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.
Keine Ficks zu geben. ¯\(ツ)/¯
Ich lern das noch. Aber jetzt gerade gießt das einfach nur noch Kaffee in die Gastritis oder so
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.
Klar, man will ja später nicht schwarz auf weiß stehen haben, dass das Management von den eklatanten Mängeln wusste und trotzdem nichts behoben hat. Wenn dann irgendwann ein riesen Ausfall, Datenverlust, Hackerangriff, Datenschutzverstoß o.ä. auftritt, wäscht man die Hände in Unschuld und wird bei der Versicherung vorstellig.
Sagt mein Chef auch. Weniger Zeit für Tests vergäuden, effizienter coden!
Ja aber dann sieht der hochbegabte Manager auch, dass eben die Tests bei einer Testreihe fehlschlägt die nicht von OP stammt.
Optimist, du! 😋
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
Dann zwinge sie, dir zuzuhören (niemand verlässt das Meeting, ehe die Tests wieder Grün sind und das Gebaute funktioniert, ach und der Kaffee ist aus, also los geht’s…)
Gute Idee! Ich buche dann Mal die Flugtickets. Das müssten die bei der Arbeit doch verstehen, manchmal geht’s einfach nur in Präsenz u.u
Präsenz fördert das Zusammenhaltsgefühl 😈
Pasteis können zusätzlich auch nicht schaden
Zuhören? An nem Montag? Ich fürchte schreckliches.
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
