Ist es möglich, etwas zu automatisieren? Dann werden wir natürlich alle Tester feuern. Warum werden sie jetzt benötigt? Es gibt keine "manuellen" Tests mehr. Immerhin?
Dies ist eine Geschichte über die Zukunft des Testens in Bezug auf DevOps. Es wird konkrete Zahlen und rein praktische Schlussfolgerungen geben, wie sich herausstellt, dass gute Spezialisten immer Arbeit haben. (Oder keine Arbeit! Schauen Sie sich das Foto von Shakespeare an und haben Sie Angst, Ihr Schicksal wird jetzt entschieden).
Das Material basiert auf einer Abschrift des Berichts von Baruch
jbaruch Sadogursky, Developer Advocate bei JFrog. Die Textversion und das Video des Berichts sind unter dem Schnitt.
Hallo allerseits! Sehen Sie ein Zitat von Shakespeare auf dem Bild oben? Dies ist Heinrich VI., Der Vorschlag, alle Anwälte zu töten. Sie verstehen, seitdem haben wir mehr vegetarische Möglichkeiten, die falschen Berufe loszuwerden. Wir werden niemanden töten, nehmen Sie es einfach und feuern Sie alle.
Genauer gesagt gibt es eine solche Möglichkeit. Werden wir jemanden feuern?
Lass uns reden.
Das ist Vasya. Eines Morgens kommt er zur Arbeit und geht am Hauptmeetingraum vorbei. Und dort begrüßt sein Chef einen neuen Berater.
Ein Effizienzberater kommt zum Unternehmen und sagt: „Wir werden DevOps wie in Netflix * durchführen. Wir sind speziell zu einer Konferenz ins Silicon Valley geflogen, und dort wurde uns gesagt, wie es ihnen bei Netflix geht. “
* Haftungsausschluss: Netflix wird in diesem Artikel häufig als unerreichbares Ideal von DevOps verwendet. Diese Verwendung ist ein Haushaltswort.
Eine Diskussion darüber, ob Netflix wirklich die perfekten DevOps hat, würde den Rahmen dieses Artikels sprengen (höchstwahrscheinlich übrigens nein).
Sie installieren Spinnaker, starten dann Chaos Monkey und alles ist automatisiert. Und wir werden dies tun und sehr effektiv sein.
Der Chef fragt, was ist mit den Testern? „Und hier wie bei Netflix -
Freiheit und Verantwortung . Die Entwickler werden die Tests selbst schreiben. “
Und dann wird Vasya krank, weil er auf seine Visitenkarte schaut und dort ...
Vasya beginnt sich Sorgen zu machen: Als das letzte Mal ein Effizienzberater kam, wurde seine Freundin Natasha, die als Systemadministratorin arbeitete, entlassen. Weil überall DevOps. Und dann merkt er, dass bald alles sehr schlecht sein wird.
Aber dann wacht Vasya natürlich auf.
Mein Name ist Baruch Sadogursky, ich bin Developer Advocate bei JFrog. Der Herausgeber dieses Artikels hat ausdrücklich darum gebeten, ein paar Absätze zu schreiben, damit niemand an meiner Autorität zweifelt, uns zu sagen, wie wir Tester entlassen werden.
JFrog ist ein Silicon Valley-Startup, unsere letzte Bewertung lag bei über einer Milliarde Dollar. Wir sind offiziell
Einhorn und machen DevOps-Automatisierung. Unsere Produkte -
Artifactory ,
Xray ,
Mission Control usw. - sind Werkzeuge für die Automatisierung, die die Fleischverarbeitungsanlage in Omsk zu Netflix macht.
Ich selbst bin kein Tester, also werde ich vielleicht etwas Unsinn erzählen. Im Programm der Konferenz, auf der dieser Bericht ursprünglich gelesen wurde, gibt es eine besondere Bezeichnung - ein Bild mit einem Molotow-Cocktail. Der Sprecher wird also eine Art Häresie tragen, und das Publikum wird verbrennen. Hier geht es um mich. Auf Twitter bin ich
@jbaruch . Wie Sie bereits verstanden haben, bin ich ein sehr fröhlicher Typ, dem ich dringend folgen muss.
Ich habe Neuigkeiten für Sie: 80% der Entwickler schreiben Tests. Entwickler sind mit allen Arten von Umfragen zufrieden. Nun, JetBrains ist mit dem sehr guten
State of Developer Ecosystem Report zufrieden. Sie fragen, wer Unit-Tests schreibt.
- 59% schreiben alleine
- 11% sehen Unit-Tests in ihrem Code und wissen nicht, woher sie kommen.
Insgesamt verwenden 70% der Entwickler Unit-Tests. Das ist cool.
Es gibt eine eingehendere
Studie von Hubstaff über das Testen mit Hilfe von Entwicklern, sie ist etwas älter - 2014. Ihm zufolge:
- 85% der Entwickler schreiben Unit-Tests,
- 15% nein;
- 40% arbeiten nach testgetriebener Entwicklungsmethode;
- Gute Abdeckung - zwischen 34 und 66 bei 31% der Entwickler.
Die überwiegende Mehrheit der Entwickler behauptet, dass sie auch etwas mit Stiften testen. Sie lügen natürlich, aber die Statistiken sind wie folgt.
Seit 2011 lautet unser Lieblingszitat:
„Jedes Unternehmen ist ein Softwareunternehmen“ . Dazu gehört natürlich auch die Omsker Fleischfabrik, in der Vasya arbeitet. Überall gibt es Software und jeder in dieser Software versucht, Geld zu verdienen. Was wollen Unternehmen? Rudern Sie die Beute mit einer Schaufel. Woher kommt das Geld? Von zufriedenen Kunden. Was wollen Kunden? Neue Funktionen. Und wann wollen sie neue Funktionen? Jetzt!
Der Comic-Chef Dilbert ist Vasyas Chef. Er hörte sich auch alle möglichen interessanten Berichte an. Er glaubt, dass Kunden, die neue Funktionen wünschen, häufiger neue Funktionen veröffentlichen müssen. Ist logisch. Reduzieren Sie dazu die Reibung in Teams.
Soll ich öfter veröffentlichen? Zum Beispiel hat Java 2017 auf häufigere Releases umgestellt, weil jeder Funktionen möchte und sie anscheinend schneller veröffentlicht werden müssen. Alle sechs Monate erscheint ein neues Java. Aber niemand benutzt es.
Wir hatten kürzlich Joker, wir haben
Java Puzzlers darauf gehostet. Am Anfang fragen wir immer, wer in welchem Java ist, um zu verstehen, welche Puzzleteile gefragt werden sollen.
Das Bild hat sich nicht geändert: 80% oder noch mehr sitzen immer noch auf Java 8, das vor hundert Jahren veröffentlicht wurde. Niemand nimmt den neunten, den zehnten oder den elften.
Um zu verstehen, warum sie es nicht verwenden, müssen Sie verstehen, wie wir eine Entscheidung darüber treffen, ob Updates vorgenommen werden sollen oder nicht. Stellen wir uns vor, wie wir Updates - das Betriebssystem, die Anwendungen, den Browser - einfügen, was immer Sie wollen.
Wie setzen wir Updates
Es wird eine Benachrichtigung angezeigt, dass wir ein Update haben. Lassen Sie uns ein neues Betriebssystem installieren. Wollen wir das? Gibt es dort etwas Nützliches oder haben wir eine Registrierkasse, die unter Windows 98 Embedded läuft, und wir brauchen nichts anderes?
Wenn wir dieses Update wollen, ist die nächste Frage, wie gefährlich es ist. Es ist eine Sache, wenn Facebook aktualisiert wird und wir scrollen und nicht mögen können. Es ist eine ganz andere Sache, wenn das Lebenserhaltungssystem im Krankenhaus ausgeschaltet ist. Wenn wir uns nicht um die Risiken kümmern, lassen Sie uns aktualisieren. Wenn es Risiken gibt, besteht die Frage darin, demjenigen zu vertrauen, der das Update einführt.
Es gab vorher keine Probleme mit Apple: Es gibt ein neues Betriebssystem - nehmen wir es. Es war vorher und jetzt haben wir Angst, aktualisiert zu werden, es gibt kein früheres Vertrauen. Wenn wir vertrauen - kein Problem, aktualisieren wir. Wenn wir nicht vertrauen, müssen Sie testen.
Wir machen sogenannte Abnahmetests. Hier sagen sie uns: Ein neues Java ist herausgekommen, und wir sind zum Beispiel Baidu. Hochlast, 100.500 Server, Cloud, JVM überall. Wir nehmen einen Teil der Server und beginnen, Java zu ändern. Eine Reihe von Ingenieuren muss etwas tun und alles überprüfen. Einmal alle drei Jahre ist es normal, aber einmal alle sechs Monate ... Bist du beschissen? Wir werden es nur sechs Monate lang überprüfen. Natürlich nehmen wir dies nicht als Ihr neues Java.
Wenn wir dies schnell überprüfen können, lohnt es sich daher, es zu aktualisieren. Wenn Sie jedoch längere Zeit nachsehen müssen, können Sie einige Versionen überspringen. Nichts wird passieren, wenn wir sofort von der achten Version zur zwölften kriechen.
Das Problem liegt im Vertrauen. Wenn wir nicht vertrauen, wird die Aktualisierung schwierig sein. Wenn das Vertrauensproblem behoben ist, gibt es keine Probleme mit Updates. Entweder haben wir eine Funktion, oder es ist uns egal.
Nimm Chrome. Er aktualisiert, beginnend mit einer Version, ohne jemanden zu fragen. Die Risiken dort sind gering, aber immer noch da. Andererseits vertrauen wir denen, die Chrome schreiben. Wenn eine neue Chrome-Version herauskommt, ist dort meistens nichts kaputt. Tatsächlich haben wir keine Probleme mit dem Vertrauen und sind auf diesem Weg.
Wir haben ein Update, Risiken sind nicht wichtig, wir vertrauen - wir aktualisieren. Und sie werden uns nicht fragen, ob wir wollen oder nicht, deshalb werden wir immer aktualisieren. Genau das wird getan.
Stellen Sie sich vor, Netflix bringt ein neues Update heraus, und jetzt können wir nicht nur Bildunterschriften und Bildschirmschoner überspringen, sondern auch alle langweiligen Orte. Cooles Update? Cool. Wollen wir ihn Wir wollen. Wird es funktionieren? Höchstwahrscheinlich ja. Im Extremfall gehen wir zu YouTube und sehen uns die Cartoons an, wenn Netflix kaputt ist.
Die Frage des Vertrauens ist kritisch. Wie lösen wir das? Das Wort "wir" bedeutet die beiden Mitbegründer von JFrog, Fred Simon (Fred Simon), Yoav Landman (Yoav Landman) und Ihren bescheidenen Diener. Wir
haben ein Buch geschrieben , das Ratschläge zur Lösung dieses Problems gibt.
Nehmen wir an, wir haben unseren CEO überzeugt, er hat Liquid Software gelesen und jetzt versteht er, warum er ein Update benötigt. Er fragt den Berater, wie wir öfter aktualisieren werden. Agil! DevOps! Was ist DevOps?
Devops
Lassen Sie mich Ihnen eine kleine Theorie darüber erzählen, was DevOps ist, da wir damit Geld verdienen. Schauen Sie sich das Bild an, wir hatten diese Gruppen, Teams, Abteilungen:
Es gibt Entwickler, es gibt Ops - Systemadministratoren, die das, was die Entwickler geschrieben haben, nehmen und auf das Produkt werfen. Und in der Mitte zwischen den Ops-Entwicklern gibt es QAs, die getestet werden. Das heißt, die Entwickler setzten sich, schrieben, brachten es dann zu den Testern, testeten es, wiesen es den Systemadministratoren zu und luden es auf das Produkt hoch. Dafür hatten wir getrennte Abteilungen.
Die russische Sprache ist wunderschön: Die Abteilung ist immer
getrennt , das ist die Wurzel des Wortes. Im Englischen ist dieser Reiz nicht, daher werden diese verschiedenen Abteilungen
Silos genannt . Die beste Übersetzung dieses Wortes ins Russische
lieferte Anton Weiss, der der beste
Redner bei DevOops war . Er nennt Silos "Brunnen". Verschiedene Abteilungen - Tiefbrunnen. Um dort etwas Arbeit zu laden, müssen Sie nach unten gehen und dann die Arbeit von dort herausziehen - aufstehen. Dies ist am bequemsten in Gruppen. Wie gruppieren wir die Dinge, die wir aus dem Brunnen bekommen?
Natürlich in Eimern. Das heißt, wir haben solche "Eimer Arbeit". Die Entwickler haben etwas in den Brunnen geschrieben, wir haben es in Eimer geladen, aus dem Brunnen genommen, die Eimer zu den Testern getragen und zu ihnen in den Brunnen gesenkt.
Es werden viele Maßnahmen ergriffen, um die Arbeit zwischen verschiedenen Brunnen zu übertragen. Wenn wir Aufgaben gruppieren, um diese Arbeit zu speichern, beginnen wir, diese Buckets zu laden. Je größer der Eimer, desto mehr sparen wir natürlich bei diesem Übertragungsprozess. Daher werden Eimer groß gemacht.
Was ist das Problem mit großen Eimern? Die Tatsache, dass sie für eine lange Zeit füllen. Wenn wir also wichtige Funktionen haben, die dringend für die Produktion freigegeben werden müssen, weil es eine Reihe von Kunden mit Geld gibt, können wir dies nicht tun. Wir haben Brunnen, besser sammeln wir mehr in einem Eimer. Daher warten wichtige Funktionen auf den ganzen Unsinn, solange wir genug haben, um dies gut zu füllen. Das ist schlecht, wie Sie verstehen. Dies wird durch die Tatsache gelöst, dass wir alle diese Brunnen erhalten und mischen.
Ich bin nicht schuld! Ich habe nur die drei Originalfarben genommen, sie übereinander gelegt, und diese Farbe hat sich herausgestellt. Jetzt machen wir alle alles. Wir haben solche Ingenieure, die sowohl Shvets als auch Reapers und Dyuras sind. Dies sind Dev, QA und Ops. Er hat den Code geschrieben und getestet und dann alles für die Produktion ausgelegt - so ein Einhorn.
Was ist das Problem der Einhörner? Dass sie nicht existieren. Und diejenigen, die existieren, wurden lange von Netflix angeheuert. Daher bleibt es uns überlassen, die Mischung herzustellen.
Die Mischung
Wir haben eine gemeinsame Kultur, gemeinsame Ziele. Wir haben die Brunnen verlassen, wir sind jetzt alle zusammen, aber wir haben immer noch eine tiefe Spezialisierung. Ein Entwickler ist immer noch mehr ein Entwickler als Ops, und ein Tester ist mehr ein Tester als ein Entwickler. Trotzdem verstehen sie alles. Sie verstehen, was sie tun, warum sie es tun und wie es funktioniert.
Das heißt, wir haben T-förmige Menschen, "Menschen in Form des Buchstabens T".
Sie haben eine tiefe Spezialisierung, sie wissen sehr gut, was sie tun. Sie wissen es ganz gut und alles andere auch. Zum Beispiel verstehen Entwickler ein wenig, wie man richtig testet, wie das Layout auf Prod abläuft und so weiter.
DevOps ist:
- Die Kultur dessen, was wir jetzt gemeinsame Ziele haben, wir verstehen, was wir zusammen tun.
- Automatisierung, um häufiger freizugeben.
Geschwindigkeit und Qualität
Lassen Sie uns über die Annahme sprechen, dass es eine umgekehrte Beziehung zwischen Geschwindigkeit und Qualität gibt. Grob gesagt ist die Qualität umso schlechter, je schneller wir veröffentlichen. Und umgekehrt: Wenn wir es nicht eilig haben, haben wir Zeit, alles gründlich zu testen. Wir haben einen Kompromiss!
Um zu verstehen, ob diese Abhängigkeit tatsächlich besteht, wenden wir uns wissenschaftlichen Arbeiten zu und sprechen über den
State of DevOps-Bericht der DORA-Organisation. Ich empfehle Ihnen dringend, sich diesen Bericht genauer anzusehen.
Wie sehr kannst du ihm vertrauen? Der Bericht besagt, dass in fünf Jahren über fünftausend Menschen befragt wurden und 2018 fast 2000 Menschen. Dies ist eine sehr große Stichprobe, und auf der Grundlage einer solchen Menge werden beispielsweise Prognosen bei den US-Wahlen abgegeben. Daher kann der Forschung vertraut werden.
Außerdem ist Nicole Forsgren, die im Gegensatz zu uns DORA leitet, Wissenschaftlerin, daher ist dort alles ernst. Mal sehen, was DORA über diese inverse Korrelation sagt.
Erstens teilten sie alle Befragten in drei Gruppen ein: Low Performers, Medium Performers und High Performers.
Darüber hinaus gibt es Elite. Dies ist Netflix (eigentlich nicht, siehe den obigen
Haftungsausschluss ).
Wie Sie sehen können, ändern sich die Proportionen. Natürlich gab es vor fünf Jahren viel mehr Low Performers, jetzt gibt es viel mehr High Performers, weil wir bereits anfangen, ein wenig zu verstehen, was wir tun.
Das ist irgendwie seltsam. Es stellt sich heraus, dass Medium mit Griffen mehr als Low getestet wird. Warum? Ja, weil Low überhaupt nichts testet.
Sie haben einen Trend, einen Graphen namens J-Kurve, der die Korrelation oder inverse Korrelation zwischen Geschwindigkeit und Qualität zeigt. Und hier ist alles sehr seltsam. Irgendwann sehen wir eine Bestätigung dieser inversen Korrelation. Das heißt, je schneller wir veröffentlichen, desto geringer ist die Qualität.
Aber dann ist die Korrelation nicht nur nicht invers, sondern direkt. Je schneller wir veröffentlichen, desto besser ist unsere Qualität. Nehmen wir an, wir sind mittelgroß und testen mit Stiften. Alles ist nicht schlecht, aber langsam, denn wir glauben, wenn wir es nicht eilig haben, werden wir alles besser testen. Dann kommt ein Berater von DevOps und sagt: „Das war's, jetzt automatisieren wir. Und wir brauchen keine Tester. Alles in Ordnung ist".
Aber ohne Tests ist es Unsinn. Nachdem wir festgestellt haben, dass schließlich etwas getestet werden muss und eine korrekte Automatisierung erforderlich ist, beginnen wir mit der korrekten Automatisierung und streben weiterhin nach himmelhohen Höhen.
Dieser Fehler, bei dem es viele Fehler gibt, muss korrekt behoben werden. Ich denke, es gibt keine Fragen. Die Frage ist, wie man da rauskommt.
Wir müssen die Frage beantworten, wie wir ohne manuelle Tests leben können. Die Antwort ist die gleiche wie die Frage, wie man lebt, ohne Server einzurichten. Offensichtlich möglich. Was ändert sich?
Zuvor hatten wir einen Systemadministrator, der ein Produkt für prod auf den Markt brachte. Er saß da und wartete darauf, dass die Entwickler mit dem Schreiben fertig waren. Danach nahm er dieses Produkt und legte die CD-ROM ein und steckte die Drähte fest. Was passiert zu diesem Zeitpunkt mit allen anderen? Alle anderen warten. Dies ist ein Engpass, Plug.
Wir lösen dies mit der richtigen Automatisierung. Wir automatisieren den Prozess, wir haben eine Pipeline im Voraus vorbereitet und jetzt wird das Produkt automatisch eingeführt, sobald es fertig geschrieben ist. Bedeutet das, dass diese Leute jetzt nicht gebraucht werden? Nein. Dies bedeutet, dass sie gebraucht werden, aber sie tun etwas anderes.
Gleiches gilt für Tests. Wir haben Tester, die das Produkt testen. Sie warten, bis sie ein Produkt schreiben. Schrieb - es ist Zeit zu testen. Was machen alle anderen beim Testen? Sie tun nichts, sie warten. Wie lösen wir das?
Wieder die richtige Automatisierung. Wir bauen einen Prozess auf. Er garantiert die Qualität des Produktes. Wir können diesen Prozess im Voraus vorbereiten, und dann wird das Produkt automatisch getestet.
- Dies erfordert beispielsweise funktionsübergreifende Teams . Hier standen wir aus den Brunnen auf und setzten uns zusammen. Jetzt liegt ein Löwe mit einem Schaf und der Tester arbeitet mit dem Programmierer zusammen.
- Wir führen kontinuierliche Tests durch . Es ist wie automatisiertes Testen, aber intelligenter.
- Während des Entwicklungsprozesses werden „Gehirntests“ durchgeführt. Dies ist ein korrekterer Begriff als „manuelles Testen“, da es beim manuellen Testen um das Gehirn geht, nicht um die Hände. Vielen Dank für diesen Begriff an meinen Zwilling auf Facebook Alexey Vinogradov. Gehirntests finden während des Entwicklungsprozesses statt. Sobald etwas erscheint, können Sie bereits seinen Ablauf überprüfen, Sie können bereits verstehen, wie es funktioniert, Sie können bereits beginnen, einige Eckfälle zu skizzieren, die wir dann automatisieren werden.
- Wir folgen jetzt dem Entwickler. Wenn er den Test zuerst nicht geschrieben hat, können wir ihm einen Schlag ins Gesicht geben. Dies ist eine testgetriebene Entwicklung .
- Sofortiges Feedback ist wichtig. Wir sollten eine Pipeline haben, die uns sofort mitteilt, sobald etwas kaputt geht. Weil wir sofort loslegen und es sofort reparieren müssen.
- Teilnahme am Design . Es kommt vor, dass Sie sich etwas ansehen und überlegen, wie wir diese Scheiße jetzt testen werden. Aber entschuldigen Sie, wo waren Sie, als alle beschlossen, dass es Scheiße geben würde? Sie kommen zu dem Treffen und sagen, dass Sie nicht einverstanden sind, Sie müssen es unbewusst tun. Sie müssen in das Design einbezogen werden, um sicherzustellen, dass Sie es später testen können.
- Werkzeuge, Gurte, Ständer - was viele von Ihnen heute tun, gehen nirgendwo hin. Im Gegenteil, das wird mehr sein. Dementsprechend sollte jemand dies schreiben.
- Chaos Engineering . Sie haben immer davon geträumt, Chaos Monkey in der Produktion zu starten, besonders wenn Sie ein Netzwerk von Geldautomaten unter Windows 95 haben. Hier ist Ihre Chance.
- Und schließlich müssen Sie dem Ignoranten das Entwerfen von Tests beibringen . Wir haben beschlossen, dass die Entwickler zumindest behaupten, Tests zu schreiben. Lassen Sie sie jetzt Tests schreiben, nur müssen wir ihnen beibringen, wie es geht. Wer wird sie unterrichten, woher wissen sie, wie man Tests schreibt? Nur du. Sonst niemand.
Es bleibt alles zu automatisieren. Tatsächlich können wir Tests automatisieren. Das Problem ist, dass Sie ein bestimmtes Teil automatisieren können.
Sie alle kennen diesen Witz darüber, wie ein Tester eine Bar betritt, Bier bestellt, 0 Biere bestellt, 99999999999 Bier bestellt, eine Eidechse bestellt, -1 Bier bestellt und bestellt ... Dies ist ein Fehler, weil es asdfgh sein muss und nicht dieser Bullshit.
Es ist leicht zu automatisieren. Es ist klar, dass es überhaupt keine Probleme mit den Zahlen gibt. Wir setzen einen Randomizer, er tut es uns an. Sogar eine Eidechse kann heute schon dort erzeugt werden. Das ist unübersichtlich - ich hoffe, Sie haben davon gehört, weil ich es gestern gelesen habe.
Aber dann kommt der Kunde, fragt, wo die Toilette ist und alles, die Bar brennt nieder, jeder stirbt und das alles. Dies kann nicht automatisiert werden. Nun, wie Sie können, aber zuerst müssen Sie mit Ihrem Kopf verstehen, dass die Bar nicht nur dort ist, wo die Getränke sind, sondern auch dort, wo die Toilette ist. Darüber hinaus sind die Chancen, dass der Kunde auf die Toilette gehen möchte, etwas höher als die Tatsache, dass er eine Eidechse bestellt. Daher ist es wichtiger, dies zu überprüfen, aber dafür müssen Sie das Geschäft verstehen, Sie müssen das Produkt verstehen, und nur Menschen mit dem Kopf können dies tun.
, , , . DevOps. , . T- — , .
, - . « », , . , , , . , Selenium . , .
, .
— . , , . . , , Ops- , , , , , , , .
Developers in test — , , . , . , ; — , ; TDD , , , , . , , .
« ». , , , , , — . , , , , , , , , , , Continuous Testing .
end-to-end , . , , DevOps, .
, - , . , 70- : « DevOps, ». , , .
. -, , , , , . : ( EVP Engineering, SignalFx) , , .
70- . . , , . , . , , , , . , , , , — , netflix .
, , , , , , , , , . . , .
, . . « , », — , , .
«, — . — : , , , . , , , , , . . , - , . ? Artifactory , ?!».
, — , . , . ? !
DORA: , , , .
New Work. , New Work Low — 30%, Medium — 40%, High Elite — 50%. ( , Low) , , .
.
Heisenbug 2018 Moscow, — 17-18 Heisenbug. , . , ( ).