Und du hast trotzdem die Frage nicht beantwortet: \u201eIst Jenkins notwendig oder nicht?\u201c<\/em><\/p>\n<\/p>\n
Jenkins ist in keiner Hinsicht notwendig. Ernsthaft, Werkzeuge wie Jenkins und Gitlab bieten Ihnen Komfort. Sie werden sehen, ob der Build erfolgreich war oder nicht. Sie k\u00f6nnen Ihnen helfen, aber sie bieten Ihnen keine Praxis. Sie k\u00f6nnen Ihnen nur ein \u201eOk\u201c oder \u201eNicht Ok\u201c geben. Und das, falls Sie \u00fcberhaupt Tests schreiben, denn wenn es keine Tests gibt, ist es fast sinnlos. Daher ist es zwar bequemer, aber insgesamt kann man auch ohne ihn leben und verliert nicht viel. <\/p>\n
<\/p>\n
Das hei\u00dft, wenn Sie Praktiken haben, ben\u00f6tigen Sie ihn nicht?<\/em><\/p>\n<\/p>\n
Ganz genau. Ich empfehle den Test von Jez Humble. Zuletzt habe ich eine gespaltene Meinung zu dem letzten Punkt. Aber insgesamt, wenn Sie drei Dinge haben: Sie f\u00fchren st\u00e4ndig Merges durch, Sie f\u00fchren Tests bei Commits im Master aus und beheben Builds im Master schnell, dann ben\u00f6tigen Sie wahrscheinlich nicht viel mehr. <\/p>\n
<\/p>\n
W\u00e4hrend wir auf Fragen der Teilnehmer warten, habe ich eine Frage. Wir haben gerade \u00fcber Produktcode gesprochen. Hast du auch Infrastrukturcode verwendet? Ist das derselbe Code, mit denselben Prinzipien und demselben Lebenszyklus, oder gibt es dort andere Lebenszyklen und Prinzipien? Normalerweise, wenn alle \u00fcber Continuous Integration und Development sprechen, wird oft vergessen, dass es auch Infrastrukturcode gibt. In letzter Zeit wird das immer mehr. Sollten diese Regeln auch dort Anwendung finden?<\/em><\/p>\n<\/p>\n
Es w\u00e4re nicht nur angebracht, es w\u00e4re gro\u00dfartig, denn es w\u00fcrde das Leben definitiv erleichtern. Sobald wir mit Code arbeiten, nicht nur mit Bash-Skripten, sondern mit richtigem Code.<\/p>\n
<\/p>\n
Halt, halt, ein Bash-Skript ist auch Code. Fass meine alte Liebe nicht an.<\/em> <\/p>\n<\/p>\n
Gut, ich werde deine Erinnerungen nicht verletzen. Ich habe eine pers\u00f6nliche Abneigung gegen Bash. Es bricht oft unsch\u00f6n und unvorhersehbar, deshalb mag ich es nicht. Aber nehmen wir an, du hast Code in Bash. Vielleicht habe ich wirklich keine Ahnung, und dort gibt es gute Testframeworks. Ich bin einfach nicht auf dem Laufenden. Und wir erhalten die gleichen Vorteile.<\/p>\n
<\/p>\n
Sobald wir mit Infrastruktur als Code arbeiten, sto\u00dfen wir auf die gleichen Probleme wie Entwickler. Vor einigen Monaten erhielt ich einen Pull-Request mit 1.000 Zeilen Bash-Code von einem Kollegen. Und man bleibt vier Stunden mit dem Review besch\u00e4ftigt. Die Probleme sind die gleichen. Es ist immer noch Code. Und immer noch Teamarbeit. Wir stecken bei dem Pull-Request fest und haben die gleichen Merge-Konflikte beim Bash zu l\u00f6sen. <\/p>\n
<\/p>\n
Ich besch\u00e4ftige mich derzeit intensiv mit der attraktiven Programmierung von Infrastrukturen. Ich habe Pulumi in die Infrastruktur integriert. Das ist reines Programmieren. Dort sieht es noch ansprechender aus, weil ich alle M\u00f6glichkeiten der Programmiersprache habe, d. h. ich habe mit den gleichen If-Bedingungen an einer Stelle sch\u00f6ne Toggle erstellt, und alles l\u00e4uft hervorragend. Mein Beitrag ist bereits im Master. Alle k\u00f6nnen ihn sehen. Die anderen Ingenieure sind dar\u00fcber informiert. Es hat bereits Auswirkungen gehabt. Allerdings wurde es nicht f\u00fcr alle Infrastrukturen aktiviert, sondern zun\u00e4chst f\u00fcr meine Testumgebungen. Um deine Frage noch einmal zu beantworten: Ja, es ist notwendig. Es erleichtert uns Ingenieuren, die mit Code arbeiten, definitiv das Leben. <\/p>\n
<\/p>\n
Gibt es noch weitere Fragen?<\/em> <\/p>\n<\/p>\n
Ich habe eine Frage. Ich m\u00f6chte die Diskussion mit Oleg fortsetzen. Insgesamt denke ich, dass Sie recht haben, dass wenn eine Aufgabe einen Monat in Anspruch nimmt, es ein Problem mit der Architektur gibt, es ein Problem mit der Analyse, Dekomposition, Planung usw. gibt. Aber ich habe das Gef\u00fchl, dass wenn Sie beginnen, nach Continuous Integration zu leben, Sie anfangen werden, die Probleme mit der Planung zu beheben, denn das wird Ihnen nicht erspart bleiben. <\/p>\n
<\/p>\n
(Oleg) Ja, das stimmt. In Bezug auf den Aufwand ist diese Praxis mit jeder anderen ernsthaften Praxis vergleichbar, die die Kultur ver\u00e4ndert. Das Schwierigste beim \u00dcberwinden sind die Gewohnheiten, insbesondere die schlechten Gewohnheiten. Und wenn es notwendig ist, diese Praxis umzusetzen, erfordert das eine ernsthafte \u00c4nderung der Gewohnheiten der Beteiligten: Entwickler, Management, Produktionsleiter, dann k\u00f6nnen Sie mit \u00dcberraschungen rechnen.<\/em> <\/p>\n<\/p>\n
Welche \u00dcberraschungen k\u00f6nnten auftreten? Angenommen, Sie haben beschlossen, h\u00e4ufiger Integrationen durchzuf\u00fchren. Und an der Integration sind einige andere Dinge gebunden, zum Beispiel Artefakte. In Ihrem Unternehmen gibt es m\u00f6glicherweise die Regel, dass jedes Artefakt in irgendeinem System zur Lagerung von Artefakten erfasst werden muss. Und das nimmt Zeit in Anspruch. Eine Person muss best\u00e4tigen, dass sie als Release-Manager dieses Artefakt auf die Produktionsbereitschaft getestet hat. Wenn das 5-10-15 Minuten dauert und Sie einmal pro Woche ein Release machen, dann ist es nicht viel, wenn man einmal pro Woche eine halbe Stunde aufwendet.<\/em> <\/p>\n<\/p>\n
Wenn Sie Continuous Integration 10 Mal am Tag durchf\u00fchren, dann m\u00fcssen Sie 10 Mal 30 Minuten berechnen. Und das \u00fcbersteigt die Arbeitszeit dieses Release-Managers. Er wird m\u00fcde, das zu tun. Es gibt st\u00e4ndig laufende Kosten f\u00fcr bestimmte Praktiken. Und das ist alles.<\/em> <\/p>\n<\/p>\n
Sie m\u00fcssen entweder diese Regel aufheben, sodass Sie sich nicht mehr mit so etwas besch\u00e4ftigen, d.h. Sie ordnen nicht mehr manuell einen Grad der \u00dcbereinstimmung von etwas zu etwas anderem zu. Sie verlassen sich vollst\u00e4ndig auf einen automatisierten Satz von Tests zur Bereitstellung.<\/em> <\/p>\n<\/p>\n
Und wenn Sie von jemandem eine Best\u00e4tigung ben\u00f6tigen, damit der Hauptverantwortliche unterschreibt, und Sie ohne Vasja, der sagt, dass er es erlaubt, nicht in die Produktion gehen, dann st\u00f6ren all diese Dinge die Praktiken. Denn wenn es mit Steuern verbundene Aktivit\u00e4ten gibt, vervielfacht sich alles um das 100-Fache. Deshalb wird eine Ver\u00e4nderung oft nicht von allen mit Freude wahrgenommen. Denn es ist schwierig, die Gewohnheiten der Menschen zu \u00e4ndern.<\/em> <\/p>\n<\/p>\n
Wenn jemand eine gewohnte Arbeit verrichtet, macht er das, ohne gro\u00df dar\u00fcber nachzudenken. Die kognitive Belastung ist gleich null. Er arbeitet einfach nach einem vorgefertigten Plan, in seinem Kopf gibt es bereits eine Checkliste, er hat es tausendmal gemacht. Und sobald Sie kommen und ihm sagen: 'Lass uns diese Praxis abschaffen und ab Montag eine neue einf\u00fchren', wird das f\u00fcr ihn eine erhebliche kognitive Belastung. Und diese tritt sofort f\u00fcr alle ein.<\/em> <\/p>\n<\/p>\n
Es ist zwar nicht f\u00fcr jeden m\u00f6glich, sich diesen Luxus zu leisten, aber ich handhabe es immer so: Wenn ein neues Projekt startet, werden gew\u00f6hnlich alle ungepr\u00fcften Praktiken sofort integriert. Solange das Projekt noch in den Anf\u00e4ngen steckt, sind wir praktisch nicht gef\u00e4hrdet. Es gibt noch kein Prod, also gibt es nichts, was wir ruinieren k\u00f6nnten. Daher k\u00f6nnen wir diesen Ansatz als \u00dcbung nutzen. Das funktioniert. Allerdings haben nicht alle Unternehmen die M\u00f6glichkeit, solche Projekte h\u00e4ufig zu starten. Das ist auch etwas seltsam, da es derzeit einen umfassenden digitalen Wandel gibt; alle sollten Experimente durchf\u00fchren, um mit der Konkurrenz Schritt zu halten.<\/em> <\/p>\n<\/p>\n
Hier kommen wir zu dem Punkt, dass man zun\u00e4chst ein klares Verst\u00e4ndnis daf\u00fcr haben muss, was man tun m\u00f6chte. Die Welt ist nicht perfekt, und das Prod ist ebenfalls nicht ideal. <\/p>\n
<\/p>\n
Ja, diese Dinge sind miteinander verbunden.<\/em><\/p>\n<\/p>\n
Auch Unternehmen haben oft nicht den klaren \u00dcberblick, dass sie genau in diese Richtung gehen sollten. <\/p>\n
<\/p>\n
Es gibt Situationen, in denen wirklich keine \u00c4nderungen m\u00f6glich sind. Das ist der Fall, wenn der Druck auf das Team steigt. Das Team ist bereits ziemlich ersch\u00f6pft. Es hat keine Zeit f\u00fcr Experimente. Von morgens bis abends entwickeln sie neue Funktionen. Und das Management verlangt immer mehr. In einer solchen Situation sind Ver\u00e4nderungen unm\u00f6glich. Das Team kann nur gesagt werden, dass es morgen genau wie gestern arbeiten wird, nur dass die Funktionen etwas umfangreicher sein m\u00fcssen. Es sind keine \u00dcberg\u00e4nge zu anderen Praktiken m\u00f6glich. Dies ist die klassische Situation, in der es keine Zeit zum Feilen gibt, weil die B\u00e4ume gef\u00e4llt werden m\u00fcssen; also wird mit einer 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 wichtig, eine umfassende Testabdeckung auf verschiedenen Ebenen zu haben. Wie viel Zeit wird f\u00fcr Tests aufgewendet? Das ist irgendwie teuer und nimmt viel Zeit in Anspruch.\u201c<\/em><\/p>\n<\/p>\n
(Oleg) Das ist ein klassisches Missverst\u00e4ndnis. Es sollten gen\u00fcgend Tests vorhanden sein, damit Sie selbst sicher sind. Continuous Integration ist nicht so aufgebaut, dass zuerst 100 % der Tests durchgef\u00fchrt werden, und erst dann fangen Sie an, diese Praxis anzuwenden. Continuous Integration reduziert Ihre kognitive Belastung, da jede \u00c4nderung, die Sie sehen, so offensichtlich ist, dass Sie verstehen, ob sie etwas kaputt macht oder nicht, auch ohne Tests. Sie k\u00f6nnen dies mental schnell testen, weil es sich um kleine \u00c4nderungen handelt. Selbst wenn Sie nur manuelle Tester haben, wird es auch einfacher f\u00fcr sie. Sie haben das Update herausgebracht und gesagt: \u201eSchau mal, ist etwas kaputt?\u201c Sie haben \u00fcberpr\u00fcft und gesagt: \u201eNein, es ist nichts kaputt.\u201c Weil der Tester wei\u00df, wo er hinschauen muss. Ihr Commit ist mit einem bestimmten Codeabschnitt verkn\u00fcpft. Und das wird durch ein spezifisches Verhalten ausgel\u00f6st.<\/em><\/p>\n<\/p>\n
Das hast du nat\u00fcrlich gesch\u00f6nt. <\/p>\n
<\/p>\n
(Dmitry) Da stimme ich nicht zu. Es gibt die Praxis des Testgetriebenen Entwickelns, die genau davor sch\u00fctzt.<\/em> <\/p>\n<\/p>\n
(Oleg) Ich habe das bisher noch nicht angesprochen. Die erste Illusion ist, dass man 100 % Tests schreiben muss oder dass man sich \u00fcberhaupt nicht mit Continuous Integration befassen sollte. Das ist nicht wahr. Es sind zwei parallele Praktiken, die nicht direkt voneinander abh\u00e4ngen. Ihre Testabdeckung sollte optimal sein. Optimal bedeutet, dass Sie selbst sicher sind, dass die Qualit\u00e4t des Masters, die nach einem Commit \u00fcbrig bleibt, Ihnen erlaubt, am Freitagabend betrunken den \u201eDeploy\u201c-Button mit Zuversicht zu dr\u00fccken. Wie erreichen Sie das? Durch Reviews, durch Abdeckung, durch gutes Monitoring.<\/em> <\/p>\n<\/p>\n
Gutes Monitoring ist nicht zu unterscheiden von Tests. Wenn Sie Tests einmal in der Pre-Prod-Phase ausf\u00fchren, \u00fcberpr\u00fcfen sie alle Ihre Anwendungsf\u00e4lle nur einmal. Wenn Sie jedoch einen unendlichen Zyklus laufen lassen, ist dies Ihr ausgebautes Monitoring-System, das st\u00e4ndig alles testet \u2013 ob es ausgefallen ist oder nicht. In diesem Fall besteht der Unterschied nur in der Einmaligkeit oder der Wiederholung. Ein sehr gutes Set an Tests \u2026, die unendlich oft ausgef\u00fchrt werden, ist Monitoring. Und richtiges Monitoring sollte genau so sein.<\/em> <\/p>\n<\/p>\n
Und wie genau erreichen Sie den Zustand, in dem Sie sich am Freitagabend bereit f\u00fchlen, nach Hause zu gehen, ist eine ganz andere Frage. Vielleicht sind Sie einfach ein mutiger Draufg\u00e4nger.<\/em> <\/p>\n<\/p>\n
Lassen Sie uns ein wenig zu Continuous Integration zur\u00fcckkehren. Wir sind ein wenig in eine andere komplexe Praxis abgeschweift. <\/p>\n
<\/p>\n
Und die zweite Illusion ist, dass MVP schnell erstellt werden sollte, weshalb Tests \u00fcberhaupt nicht notwendig sind. Das ist nicht ganz richtig. Wenn Sie bei einem MVP eine User Story schreiben, k\u00f6nnen Sie entweder impulsiv handeln, indem Sie geh\u00f6rt haben, dass es eine bestimmte User Story gibt, und sofort mit dem Codieren beginnen, oder Sie arbeiten nach TDD. Die Erfahrung zeigt, dass es nicht l\u00e4nger dauert, wenn Sie nach TDD arbeiten; Tests sind ein Nebeneffekt. Die TDD-Praxis besteht nicht darin, zu testen. Obwohl es Test Driven Development hei\u00dft, geht es dabei eigentlich nicht um Tests. Es ist eher ein architektonischer Ansatz. Es geht darum, genau das zu schreiben, was ben\u00f6tigt wird, und das, was nicht ben\u00f6tigt wird, zu vermeiden. Diese Praxis konzentriert sich auf die n\u00e4chste Iteration Ihrer Gedanken hinsichtlich des Aufbaus der Anwendungsarchitektur.<\/em> <\/p>\n<\/p>\n
Es ist also nicht einfach, sich von diesen Illusionen zu befreien. MVP und Tests stehen nicht im Widerspruch zueinander. Ganz im Gegenteil, wenn Sie Ihr MVP gem\u00e4\u00df der TDD-Praxis erstellen, werden Sie es besser und schneller umsetzen, als wenn Sie dies ohne Praktiken und zuf\u00e4llig tun.<\/em><\/p>\n<\/p>\n
Das ist eine sehr nicht offensichtliche und komplexe \u00dcberlegung. Wenn man h\u00f6rt, dass ich jetzt noch Tests schreiben werde und gleichzeitig schneller etwas machen kann, klingt das absolut unplausibel. <\/p>\n
<\/p>\n
(Dmitrij) Viele, wenn sie von MVP sprechen, haben einfach keine Lust, etwas Vern\u00fcnftiges zu schreiben. Und das sind letztendlich verschiedene Dinge. Man sollte MVP nicht in etwas Schlechtes verwandeln, das nicht funktioniert.<\/em> <\/p>\n<\/p>\n
Ja, ja, du hast recht.<\/p>\n
<\/p>\n
Und dann pl\u00f6tzlich das MVP in der Produktion.<\/em><\/p>\n<\/p>\n
F\u00fcr immer. <\/p>\n
<\/p>\n
TDD klingt zun\u00e4chst ungew\u00f6hnlich, wenn man h\u00f6rt, dass man Tests schreibt und scheinbar mehr Arbeit leistet. Es mag merkw\u00fcrdig erscheinen, aber tats\u00e4chlich l\u00e4uft es so schneller und ansprechender. Wenn du einen Test schreibst, denkst du bereits intensiv dar\u00fcber nach, welcher Code geschrieben wird, wie er aufgerufen wird und welches Verhalten wir davon erwarten. Du sagst nicht einfach, dass du eine Funktion geschrieben hast, die etwas tut. Stattdessen \u00fcberlegst du dir zuerst, welche Bedingungen sie erf\u00fcllen muss und wie sie aufgerufen werden soll. Du deckst das mit Tests ab und daraus erkennst du, wie die Schnittstellen innerhalb deines Codes aussehen werden. Das hat einen erheblichen Einfluss auf die Architektur. Dein Code wird automatisch modularer, weil du zuerst versuchst zu verstehen, wie du ihn testen wirst, bevor du ihn schreibst. <\/p>\n
<\/p>\n
Ich hatte mit TDD die Erfahrung, dass ich zu einem bestimmten Zeitpunkt einen Mentor f\u00fcr Ruby engagiert habe, als ich noch Ruby-Programmierer war. Und er sagt: \"Lass uns TDD machen.\" Ich dachte mir: \"Mist, jetzt muss ich noch etwas zus\u00e4tzlich schreiben.\" Und wir haben vereinbart, dass ich in den n\u00e4chsten zwei Wochen den gesamten funktionierenden Code in Python nach TDD schreibe. Nach zwei Wochen wurde mir klar, dass ich nicht mehr zur\u00fcck will. Wenn man zwei Wochen lang versucht, dies \u00fcberall anzuwenden, merkt man, wie viel einfacher es wird, auch nur zu denken. Aber das ist nicht offensichtlich, deshalb empfehle ich jedem, wenn ihr das Gef\u00fchl habt, dass TDD kompliziert, langwierig und \u00fcberfl\u00fcssig ist, haltet euch zwei Wochen lang daran. Mir haben zwei Wochen daf\u00fcr gereicht.<\/p>\n
<\/p>\n
(Dmitrij) Wir k\u00f6nnen diesen Gedanken aus der Perspektive des Infrastrukturmanagements weiterentwickeln. Bevor wir etwas Neues einf\u00fchren, f\u00fchren wir ein Monitoring durch und starten dann. In diesem Fall wird das Monitoring zu einem regul\u00e4ren Test. Es gibt eine Entwicklung durch Monitoring. Aber fast alle sagen, dass es lange dauert, dass sie es als l\u00e4stig empfinden und einen vorl\u00e4ufigen Entwurf erstellt haben. Wenn wir das Monitoring richtig durchf\u00fchren, verstehen wir den Zustand des CI-Systems. In einem CI-System gibt es viel Monitoring. Wir verstehen den Zustand des Systems und wissen, was darin vor sich geht. Und w\u00e4hrend der Entwicklung gestalten wir das System so, dass es den gew\u00fcnschten Zustand erreicht.<\/em> <\/p>\n<\/p>\n
Diese Praktiken sind seit langem bekannt. Wir haben das vor etwa 4 Jahren besprochen. Aber in den letzten 4 Jahren hat sich praktisch nichts ge\u00e4ndert.<\/em> <\/p>\n<\/p>\n
Ich schlage vor, die offizielle Diskussion an dieser Stelle zu beenden.<\/em><\/p>\n<\/p>\n
Video (als Medienelement eingef\u00fcgt, funktioniert aber aus irgendeinem Grund 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