Und du hast die Frage nicht beantwortet: \u201eBraucht man Jenkins oder nicht?\u201c<\/em><\/p>\n<\/p>\n
Jenkins ist in Wahrheit auf keinen Fall notwendig. Wenn ich ehrlich bin, werden dir Werkzeuge wie Jenkins und Gitlab mehr Komfort bieten. Du wirst sehen, ob der Build erfolgreich war oder nicht. Sie k\u00f6nnen helfen, aber sie werden dir keine Praktiken vermitteln. Sie k\u00f6nnen dir nur ein kleines Zeichen geben \u2013 ok, nicht ok. Und das gilt, wenn du auch Tests schreibst, denn ohne Tests ist es fast sinnlos. Daher ist es n\u00fctzlich, weil es praktischer ist, aber im Allgemeinen kann man auch ohne leben, man verliert nicht viel. <\/p>\n
<\/p>\n
Das hei\u00dft, wenn du Praktiken hast, brauchst du es dann nicht?<\/em><\/p>\n<\/p>\n
Ganz genau. Ich empfehle den Test von Jez Humble. Da habe ich zu dem letzten Punkt eine zwiesp\u00e4ltige Meinung. Aber im Allgemeinen, wenn du drei Dinge hast: du mergen st\u00e4ndig, du f\u00fchrst Tests bei Commits im Master aus und reparierst schnell den Build im Master, dann brauchst du vielleicht nicht mehr. <\/p>\n
<\/p>\n
W\u00e4hrend wir auf Fragen von den Teilnehmern warten, habe ich eine Frage. Wir haben jetzt \u00fcber Produktcode gesprochen. Hast du auch f\u00fcr Infrastrukturcode verwendet? Ist das derselbe Code, hat er dieselben Prinzipien und denselben Lebenszyklus, oder gibt es dort andere Lebenszyklen und Prinzipien? \u00dcblicherweise, wenn alle \u00fcber Continuous Integration und Development sprechen, vergessen sie, dass es auch Infrastrukturcode gibt. Und in letzter Zeit wird es immer mehr davon. Sollten all diese Regeln auch dort gelten?<\/em><\/p>\n<\/p>\n
Es ist nicht nur so, dass es sinnvoll w\u00e4re, es w\u00e4re gro\u00dfartig, denn es w\u00fcrde das Leben sicher genauso erleichtern. Sobald wir mit Code arbeiten, nicht mit Bash-Skripten, sondern wenn wir richtigen Code haben.<\/p>\n
<\/p>\n
Stopp, stopp, ein Bash-Skript ist auch Code. Fass meine alte Liebe nicht an.<\/em> <\/p>\n<\/p>\n
Gut, ich werde deine Erinnerungen nicht treten. Ich habe eine pers\u00f6nliche Abneigung gegen Bash. Es bricht auf h\u00e4ssliche und furchterregende Weise st\u00e4ndig. Und es bricht oft unvorhersehbar, daher mag ich es nicht so sehr. Aber gut, nehmen wir an, du hast Code in Bash. Vielleicht habe ich wirklich keine Ahnung und es gibt vern\u00fcnftige Test-Frameworks daf\u00fcr. Ich bin einfach nicht im Thema. Und wir bekommen die gleichen Vorteile.<\/p>\n
<\/p>\n
Sobald wir mit Infrastruktur wie mit Code arbeiten, bekommen wir all die gleichen Probleme wie Entwickler. Vor ein paar Monaten hatte ich eine Situation, in der mir ein Kollege einen Pull-Request mit 1.000 Zeilen Bash geschickt hat. Und du h\u00e4ngst vier Stunden in der \u00dcberpr\u00fcfung fest. Die Probleme sind immer noch die gleichen. Es ist immer noch Code. Und immer noch Teamarbeit. Wir stecken bei Pull-Requests fest und h\u00e4ngen bei den gleichen Merge-Konflikten von Bash fest, zum Beispiel. <\/p>\n
<\/p>\n
Ich schaue mir jetzt sehr aktiv das gesamte Thema an, um die Infrastruktur so sch\u00f6n wie m\u00f6glich zu programmieren. Ich habe gerade Pulumi in die Infrastruktur eingef\u00fchrt. Das ist Programmierung pur. Dort sieht es noch ansprechender aus, weil ich alle M\u00f6glichkeiten der Programmiersprache habe, d. h. ich habe mit denselben If-Anweisungen auf einfache Weise sch\u00f6ne Toggles erstellt und alles ist gut. Das hei\u00dft, meine \u00c4nderung ist bereits im Master. Jeder kann sie jetzt sehen. Andere Ingenieure sind dar\u00fcber informiert. Es hat bereits Einfluss gehabt. Aber es wurde nicht f\u00fcr alle Infrastrukturen aktiviert. Es wurde zum Beispiel f\u00fcr meine Testumgebungen aktiviert. Daher, um deine Frage nochmal zu beantworten, es ist notwendig. Es erleichtert unser Leben als Ingenieure, die mit Code arbeiten, auf die gleiche Weise. <\/p>\n
<\/p>\n
Hat noch jemand Fragen?<\/em> <\/p>\n<\/p>\n
Ich habe eine Frage. Ich m\u00f6chte die Diskussion mit Oleg fortsetzen. Insgesamt denke ich, dass du recht hast, dass, wenn eine Aufgabe einen Monat dauert, du ein Problem mit der Architektur hast, ein Problem mit der Analyse, der Dekomposition, der Planung usw. Aber ich habe das Gef\u00fchl, dass, wenn du versuchst, nach Continuous Integration zu leben, du anf\u00e4ngst, die Schmerzen bei der Planung zu beheben, denn du kannst davon nicht mehr weg. <\/p>\n
<\/p>\n
(Oleg) Ja, das ist so. In Bezug auf den Arbeitsaufwand ist diese Praxis mit jeder anderen ernsthaften Praxis vergleichbar, die die Kultur ver\u00e4ndert. Das Schwierigste bei der \u00dcberwindung sind die Gewohnheiten, insbesondere die schlechten Gewohnheiten. Und wenn es notwendig ist, dass die Gewohnheiten der Umgebung ge\u00e4ndert werden: Entwickler, Management, Produktionsleiter, dann erwartet Sie eine \u00dcberraschung.<\/em> <\/p>\n<\/p>\n
Welche \u00dcberraschungen k\u00f6nnte es geben? Angenommen, Sie haben beschlossen, dass Sie die Integration h\u00e4ufiger durchf\u00fchren werden. Und mit der Integration sind noch andere Dinge verbunden, nehmen wir an, Artefakte. In Ihrem Unternehmen gibt es beispielsweise die Richtlinie, dass jedes Artefakt auf irgendeine Weise in einem System zur Lagerung von Artefakten erfasst werden muss. Und das kostet eine gewisse Zeit. Eine Person muss ein H\u00e4kchen setzen, dass sie als Release-Manager dieses Artefakt auf die Betriebsbereitschaft f\u00fcr die Ver\u00f6ffentlichung in der Produktion getestet hat. Wenn das 5-10-15 Minuten dauert, aber Sie einmal pro Woche eine Ver\u00f6ffentlichung machen, dann einmal pro Woche eine halbe Stunde zu investieren \u2013 das ist eine geringe Steuer.<\/em> <\/p>\n<\/p>\n
Wenn Sie Continuous Integration 10 Mal am Tag durchf\u00fchren, m\u00fcssen Sie 10 Mal 30 Minuten multiplizieren. Und das \u00fcbersteigt die Arbeitszeit dieses Release-Managers. Er ist einfach m\u00fcde, das zu tun. Es gibt st\u00e4ndige Kosten f\u00fcr bestimmte Praktiken. Und das ist alles.<\/em> <\/p>\n<\/p>\n
Und Sie m\u00fcssen entweder diese Regel aufheben, damit Sie sich nicht mehr mit diesem Unsinn besch\u00e4ftigen, d.h. Sie weisen nicht mehr manuell einen Grad der \u00dcbereinstimmung von etwas mit etwas zu. Sie verlassen sich voll und ganz auf einen automatisierten Testsatz f\u00fcr die Betriebsbereitschaft.<\/em> <\/p>\n<\/p>\n
Und wenn Sie von jemandem einen Nachweis ben\u00f6tigen, damit der Chef unterschreibt, und Sie nicht in die Produktion gehen, ohne dass Wanja gesagt hat, dass er es erlaubt usw. \u2013 all dieser Unsinn steht den Praktiken im Weg. Denn wenn damit verbundene Aktivit\u00e4ten als Steuer fungieren, vervielfacht sich alles um das 100-fache. Daher wird eine Ver\u00e4nderung oft nicht von allen positiv aufgenommen. Denn Gewohnheiten sind schwer zu \u00e4ndern.<\/em> <\/p>\n<\/p>\n
Wenn eine Person die gewohnte Arbeit verrichtet, tut sie dies praktisch nicht nachdenken. Die kognitive Belastung betr\u00e4gt null. Er bearbeitet einfach das Vorhandene, hat bereits eine Checkliste im Kopf, die er tausend Mal durchgegangen ist. Und sobald du kommst und ihm sagst: \u201eLass uns diese Praxis abschaffen und ab Montag eine neue einf\u00fchren\u201c, wird dies eine enorme kognitive Belastung f\u00fcr ihn. Und das trifft alle sofort.<\/em> <\/p>\n<\/p>\n
Deshalb ist es am einfachsten, obwohl sich diese Eleganz nicht alle leisten k\u00f6nnen, genau so zu verfahren. Wenn ein neues Projekt gestartet wird, werden oft sofort alle unerprobten Praktiken in dieses Projekt integriert. Solange das Projekt jung ist, riskieren wir nicht viel. Es gibt noch kein Prod, also gibt es nichts, was man ruinieren k\u00f6nnte. Daher kann es als Training genutzt werden. Dieser Ansatz funktioniert. Aber nicht alle Unternehmen haben die M\u00f6glichkeit, solche Projekte h\u00e4ufig zu starten. Obwohl es auch etwas seltsam ist, denn derzeit ist die digitale Transformation durchg\u00e4ngig, jeder sollte Experimente durchf\u00fchren, um mit den Wettbewerbern Schritt zu halten.<\/em> <\/p>\n<\/p>\n
Hier kommt man zu dem Punkt, dass man zun\u00e4chst verstehen muss, was man tun muss. Die Welt ist nicht perfekt, das Prod ist auch nicht perfekt. <\/p>\n
<\/p>\n
Ja, diese Dinge h\u00e4ngen zusammen.<\/em><\/p>\n<\/p>\n
Die Unternehmen haben auch nicht immer das Verst\u00e4ndnis, dass sie dorthin gehen sollten. <\/p>\n
<\/p>\n
Es gibt Situationen, in denen keine Ver\u00e4nderungen \u00fcberhaupt m\u00f6glich sind. Dies ist der Fall, wenn der Druck auf das Team gr\u00f6\u00dfer wird. Das Team ist bereits ziemlich ersch\u00f6pft. Es hat keine Reservezeit f\u00fcr Experimente. Sie arbeiten von morgens bis abends an Features. Und den F\u00fchrungskr\u00e4ften sind die Features nie genug. Es wird immer mehr verlangt. In einer solchen Situation sind keine Ver\u00e4nderungen m\u00f6glich. Dem Team kann nur gesagt werden, dass sie morgen genauso arbeiten wie gestern, einfach etwas mehr Features machen m\u00fcssen. Keinerlei \u00dcberg\u00e4nge zu irgendeiner Praxis sind in diesem Sinne m\u00f6glich. Dies ist die klassische Situation, in der es keine Zeit gibt, die Axt zu sch\u00e4rfen, man muss die B\u00e4ume f\u00e4llen, also wird mit der stumpfen Axt gearbeitet. Hier gibt es keine einfachen Ratschl\u00e4ge.<\/em> <\/p>\n<\/p>\n
(Dmitrij) Ich lese eine Klarstellung aus dem Chat vor: \u201eAber es ist notwendig, eine umfangreiche Testabdeckung auf verschiedenen Ebenen zu haben. Wie viel Zeit wird f\u00fcr Tests aufgewendet? Irgendwie ist das teuer, nimmt viel Zeit in Anspruch.\u201c<\/em><\/p>\n<\/p>\n
(Oleg) Das ist ein klassisches Missverst\u00e4ndnis. Es sollten ausreichend Tests vorhanden sein, damit Sie selbst Vertrauen haben. Continuous Integration ist keine Methode, bei der zuerst 100 % der Tests durchgef\u00fchrt werden und erst dann beginnen Sie, diese Praxis anzuwenden. Continuous Integration reduziert Ihre kognitive Belastung, weil jede \u00c4nderung, die Sie mit eigenen Augen sehen, so offensichtlich ist, dass Sie sofort verstehen, ob sie etwas kaputt macht oder nicht, sogar ohne Tests. Sie k\u00f6nnen dies im Kopf schnell testen, da es kleine \u00c4nderungen sind. Selbst wenn Sie nur manuelle Tester haben, wird es auch f\u00fcr sie einfacher. Sie haben das Release gemacht und gesagt: \u201eSchau mal, ist nichts kaputt?\u201c Sie haben gepr\u00fcft und gesagt: \u201eNein, es ist nichts kaputt.\u201c Weil der Tester wei\u00df, wo er schauen muss. Ihr Commit ist mit einem Codefragment verkn\u00fcpft. Und es wird durch ein bestimmtes Verhalten ausgef\u00fchrt.<\/em><\/p>\n<\/p>\n
Hier hast du nat\u00fcrlich \u00fcbertrieben. <\/p>\n
<\/p>\n
(Dmitry) Da stimme ich nicht zu. Es gibt die Praxis \u2013 Testgetriebene Entwicklung, die gerade davor rettet.<\/em> <\/p>\n<\/p>\n
(Oleg) Dazu bin ich noch nicht gekommen. Die erste Illusion ist, dass man genau 100 % Tests schreiben muss oder \u00fcberhaupt keine Continuous Integration betreiben kann. Das ist nicht wahr. Das sind zwei parallele Praktiken. Und sie h\u00e4ngen nicht direkt voneinander ab. Ihre Testabdeckung sollte optimal sein. Optimal bedeutet, dass Sie selbst sicher sind, dass die Qualit\u00e4t des Masters, die nach dem Commit \u00fcbrig bleibt, es Ihnen erm\u00f6glicht, sicher am Freitagabend im betrunkenen Zustand auf die Schaltfl\u00e4che \u201eDeploy\u201c zu klicken. Wie erreichen Sie das? Durch Reviews, durch Abdeckung, durch gutes Monitoring.<\/em> <\/p>\n<\/p>\n
Gutes Monitoring ist nicht von Tests zu unterscheiden. Wenn Sie die Tests einmal im Pre-Prod ausf\u00fchren, \u00fcberpr\u00fcfen sie einmal alle Ihre Benutzerszenarien und das war's. Wenn Sie sie jedoch in einem endlosen Zyklus ausf\u00fchren, haben Sie Ihr erweitertes Monitoring-System, das endlos alles testet \u2013 ob es abgest\u00fcrzt ist oder nicht. In diesem Fall liegt der Unterschied nur in der Einmaligkeit oder Mehrmaligkeit. Ein sehr guter Satz von Tests \u2026, die endlos ausgef\u00fchrt werden, ist Monitoring. Und richtiges Monitoring sollte so sein.<\/em> <\/p>\n<\/p>\n
Und wie genau Sie diesen Zustand erreichen, in dem Sie am Freitagabend deployen und nach Hause gehen, ist eine andere Frage. Vielleicht sind Sie einfach ein mutiger Typ.<\/em> <\/p>\n<\/p>\n
Lass uns einen Schritt zur\u00fcck zu Continuous Integration machen. Wir sind ein wenig in eine andere komplexe Praxis abgedriftet. <\/p>\n
<\/p>\n
Und die zweite Illusion ist, dass man MVP angeblich schnell erstellen muss, weshalb Tests dort \u00fcberhaupt nicht notwendig seien. Das ist nicht ganz richtig. Es geht darum, dass man, wenn man im MVP eine User Story schreibt, diese entweder unbedacht umsetzt, d. h. man hat geh\u00f6rt, dass es eine User Story gibt, und springt sofort ins Codieren, oder nach TDD arbeitet. Und nach TDD, wie die Praxis zeigt, dauert es nicht l\u00e4nger, d. h. Tests sind ein Nebeneffekt. Die TDD-Praxis besteht nicht darin, Tests zu schreiben. Trotz des Begriffs Test Driven Development geht es dabei in Wirklichkeit gar nicht um Tests. Es handelt sich eher um einen architektonischen Ansatz. Es ist ein Ansatz, um genau das zu schreiben, was n\u00f6tig ist, und nicht das, was nicht n\u00f6tig ist. Diese Praxis fokussiert darauf, wie man die n\u00e4chste Iteration seines Denkens in Bezug auf die Erstellung der Anwendungsarchitektur angeht.<\/em> <\/p>\n<\/p>\n
Es ist also nicht so einfach, sich von diesen Illusionen zu befreien. MVP und Tests widersprechen sich nicht. Ganz im Gegenteil, wenn Sie das MVP nach der TDD-Praxis erstellen, werden Sie es besser und schneller umsetzen, als wenn Sie ohne diese Praxis arbeiten und einfach drauflos programmieren.<\/em><\/p>\n<\/p>\n
Das ist ein sehr unauff\u00e4lliger und komplexer Gedanke. Wenn du h\u00f6rst, dass du jetzt noch Tests schreiben musst und dabei etwas schneller machst, klingt das absolut unangemessen. <\/p>\n
<\/p>\n
(Dmitry) Viele, wenn sie von MVP sprechen, haben einfach keine Lust, etwas Vern\u00fcnftiges zu schreiben. Und das sind immer noch verschiedene Dinge. Man sollte MVP nicht in eine schlechte Sache verwandeln, die nicht funktioniert.<\/em> <\/p>\n<\/p>\n
Ja, ja, du hast recht.<\/p>\n
<\/p>\n
Und dann kommt pl\u00f6tzlich das MVP in die Produktion.<\/em><\/p>\n<\/p>\n
F\u00fcr immer. <\/p>\n
<\/p>\n
TDD klingt sehr ungewohnt, wenn man h\u00f6rt, dass man Tests schreibt und dabei scheinbar mehr Arbeit verrichtet. Das klingt sehr seltsam, aber in Wirklichkeit bekommt man es dadurch schneller und sch\u00f6ner hin. Wenn du einen Test schreibst, denkst du bereits viel dar\u00fcber nach, welchen Code und wie er aufgerufen wird sowie welches Verhalten wir von ihm erwarten. Du sagst nicht einfach, dass du eine Funktion geschrieben hast und sie etwas macht. Du hast zuerst dar\u00fcber nachgedacht, dass sie unter bestimmten Bedingungen so aufgerufen wird. Du deckst das mit Tests ab und daraus verstehst du, wie deine Schnittstellen innerhalb deines Codes aussehen werden. Das hat einen gro\u00dfen Einfluss auf die Architektur. Dein Code wird automatisch modularer, weil du zuerst versuchst zu verstehen, wie du ihn testen wirst, und erst dann schreibst du ihn. <\/p>\n
<\/p>\n
Ich habe mit TDD Folgendes erlebt: Irgendwann habe ich einen Mentor f\u00fcr Ruby engagiert, als ich noch Ruby-Programmierer war. Und er sagt: \u201eLass uns TDD ausprobieren\u201c. Ich dachte mir: \u201eVerdammtes A, jetzt muss ich noch mehr zus\u00e4tzlich schreiben\u201c. Und wir haben uns darauf geeinigt, dass ich zwei Wochen lang allen funktionierenden Code in Python nach TDD schreibe. Nach zwei Wochen habe ich realisiert, dass ich nicht mehr zur\u00fcckwill. Nach zwei Wochen, in denen ich versucht habe, das \u00fcberall anzuwenden, verstehst du, wie viel einfacher es geworden ist, sogar nur zu denken. Aber das ist nicht offensichtlich, deshalb empfehle ich jedem, dass, wenn ihr das Gef\u00fchl habt, TDD ist kompliziert, langwierig und unn\u00f6tig, versucht es einfach f\u00fcr zwei Wochen. Mir haben zwei Wochen daf\u00fcr gereicht.<\/p>\n
<\/p>\n
(Dmitri) Wir k\u00f6nnen diesen Gedanken aus der Sicht der Infrastruktur-Operationen weiter ausf\u00fchren. Bevor wir etwas Neues starten, machen wir ein Monitoring und starten dann. In diesem Fall wird unser Monitoring zu einer normalen Testung. Und es gibt eine Entwicklung durch Monitoring. Aber fast alle sagen, dass es lange dauert, ich habe keinen Bock, ich habe einen vorl\u00e4ufigen Entwurf gemacht. Wenn wir richtiges Monitoring gemacht haben, verstehen wir den Zustand des CI-Systems. Und im CI-System gibt es viel Monitoring. Wir verstehen den Zustand des Systems, wir verstehen, was sich darin befindet. Und w\u00e4hrend der Entwicklung stellen wir bewusst das System so ein, dass es den gew\u00fcnschten Zustand erreicht.<\/em> <\/p>\n<\/p>\n
Diese Praktiken sind schon lange bekannt. Wir haben vor etwa 4 Jahren dar\u00fcber diskutiert. Aber in den 4 Jahren hat sich praktisch nichts ge\u00e4ndert.<\/em> <\/p>\n<\/p>\n
Aber in dieser Note schlage ich vor, die offizielle Diskussion zu beenden.<\/em><\/p>\n<\/p>\n
Video (als Medienelement eingef\u00fcgt, funktioniert aber irgendwie nicht):<\/p>\n
\nhttps:\/\/youtu.be\/zZ3qXVN3Oic<\/a><\/noindex> habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041e\u0431\u0441\u0443\u0434\u0438\u043c \u043f\u043e\u0447\u0435\u043c\u0443 CI-\u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u0438 CI \u2013 \u044d\u0442\u043e \u0441\u043e\u0432\u0441\u0435\u043c \u043f\u0440\u043e \u0440\u0430\u0437\u043d\u043e\u0435. \u041a\u0430\u043a\u0443\u044e \u0431\u043e\u043b\u044c CI \u043f\u0440\u0438\u0437\u0432\u0430\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c, \u043e\u0442\u043a\u0443\u0434\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u043b\u0430 \u0438\u0434\u0435\u044f, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u044f \u0447\u0442\u043e \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043d\u044f\u0442\u044c \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0435\u0441\u0442\u044c \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430, \u0430 \u043d\u0435 \u043f\u0440\u043e\u0441\u0442\u043e \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u043d\u044b\u0439 Jenkins. \u041c\u044b\u0441\u043b\u044c \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0434\u043e\u043a\u043b\u0430\u0434 \u043f\u0440\u043e Continuous Integration \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0435\u0449\u0435 \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434, \u043a\u043e\u0433\u0434\u0430 \u044f \u0445\u043e\u0434\u0438\u043b \u043f\u043e \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f\u043c \u0438\u0441\u043a\u0430\u043b \u0440\u0430\u0431\u043e\u0442\u0443. \u041f\u043e\u043e\u0431\u0449\u0430\u043b\u0441\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93885","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Continuous](\"\/wp-content\/uploads\/2020\/09\/ed8a32ae63b8dccfc8b4893ab27f1527.jpg\")
<\/p>\n