{"id":55870,"date":"2020-01-30T00:00:00","date_gmt":"2020-01-29T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian"},"modified":"2020-02-18T14:04:02","modified_gmt":"2020-02-18T11:04:02","slug":"ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","title":{"rendered":"Von Skripten zu einer eigenen Plattform: wie wir die Entwicklung bei CIAN automatisiert haben","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Von
\n
\nAuf der RIT 2019 pr\u00e4sentierte unser Kollege Alexander Kortkow h\u00e4lt<\/a><\/noindex> \u00fcber die Automatisierung der Entwicklung bei CIAN: Um das Leben und die Arbeit zu erleichtern, nutzen wir unsere eigene Plattform Integro. Sie verfolgt den Lebenszyklus von Aufgaben, entlastet die Entwickler von Routinearbeiten und verringert signifikant die Anzahl der Bugs in der Produktion. In diesem Beitrag erg\u00e4nzen wir Alexanders Vortrag und erz\u00e4hlen, wie wir von einfachen Skripten zur Integration von Open-Source-Produkten \u00fcber unsere eigene Plattform gelangt sind und was unser spezielles Automatisierungsteam tut.
\n\u00a0<\/a><\/noindex><\/p>\n

Null-Level<\/h2>\n

\n\u201eNull-Level gibt es nicht, davon wei\u00df ich nichts\u201c<\/b>
\nMeister Shifu aus dem Zeichentrickfilm \u201eKung Fu Panda\u201c<\/i><\/p>\n

Die Automatisierung bei CIAN begann 14 Jahre nach der Gr\u00fcndung des Unternehmens. Damals bestand das Entwicklungsteam aus 35 Personen. Kaum zu glauben, oder? Nat\u00fcrlich gab es in irgendeiner Form bereits Automatisierung, aber die separate Abteilung f\u00fcr kontinuierliche Integration und Codeauslieferung begann sich tats\u00e4chlich erst im Jahr 2015 zu bilden.\u00a0<\/p>\n

Zu diesem Zeitpunkt hatten wir ein gro\u00dfes Monolith-System aus Python, C# und PHP, das auf Linux- und Windows-Servern bereitgestellt wurde. Um dieses Monster zu deployen, hatten wir eine Reihe von Skripten, die wir manuell ausf\u00fchrten. Au\u00dferdem gab es den Build des Monolithen, der uns Schmerzen und Leiden bereitete, aufgrund von Konflikten beim Zusammenf\u00fchren von Branches, Fehlerkorrekturen und dem Neubau mit \u201eeinem anderen Satz von Aufgaben im Build\u201c. Vereinfacht dargestellt, sah der Prozess so aus:<\/p>\n

\"Von
\n
\nDas entsprach nicht unseren Vorstellungen, und wir wollten einen wiederholbaren, automatisierten und verwalteten Build- und Deployment-Prozess aufbauen. Dazu ben\u00f6tigten wir ein CI\/CD-System und w\u00e4hlten zwischen der kostenlosen Version von TeamCity und Jenkins, mit denen wir bereits gearbeitet hatten, und die uns beide hinsichtlich der Funktionalit\u00e4ten \u00fcberzeugten. Letztendlich entschieden wir uns f\u00fcr TeamCity als das neuere Produkt. Zu diesem Zeitpunkt nutzten wir noch keine Microservices-Architektur und erwarteten nicht die Vielzahl an Aufgaben und Projekten.<\/p>\n

Wir kommen zur Idee eines eigenen Systems<\/h2>\n

\nDie Einf\u00fchrung von Teamcity reduzierte nur einen Teil der manuellen Arbeiten: Es blieben die Erstellung von Pull-Requests, das Vorantreiben von Aufgaben in Jira und die Auswahl von Aufgaben f\u00fcr das Release. Mit diesen Anforderungen konnte Teamcity nicht mehr zurechtkommen. Daher war ein weiterer Automatisierungsweg erforderlich. Wir pr\u00fcften die Optionen f\u00fcr die Arbeit mit Skripten in Teamcity oder den Wechsel zu externen Automatisierungssystemen. Letztendlich entschieden wir uns jedoch f\u00fcr die maximale Flexibilit\u00e4t, die nur eine eigene L\u00f6sung bieten kann. So entstand die erste Version unseres internen Automatisierungssystems namens Integro.<\/p>\n

Teamcity automatisiert den Prozess der Ausf\u00fchrung von Build- und Deployment-Prozessen, w\u00e4hrend Integro sich auf die Hochgradautomatisierung der Entwicklungsprozesse konzentriert. Es war notwendig, die Arbeit mit Aufgaben in Jira mit der Verarbeitung des dazugeh\u00f6rigen Codes in Bitbucket zu verbinden. In dieser Phase begannen in Integro eigene Workflows f\u00fcr die Bearbeitung verschiedener Aufgabentypen zu entstehen.\u00a0<\/p>\n

Mit der zunehmenden Automatisierung in den Gesch\u00e4ftsprozessen ist die Anzahl der Projekte und Runs in TeamCity gestiegen. Dabei trat ein neues Problem auf: Eine kostenlose TeamCity-Instanz war nicht mehr ausreichend (3 Agents und 100 Projekte). Wir haben eine weitere Instanz hinzugef\u00fcgt (noch 3 Agents und 100 Projekte), und dann noch eine. Letztendlich hatten wir ein System aus mehreren Clustern, das schwer zu verwalten war.<\/p>\n

\"Von
\n
\nAls die Frage nach einer vierten Instanz aufkam, wurde uns klar, dass wir so nicht weitermachen konnten, da die Gesamtkosten f\u00fcr die Unterst\u00fctzung von 4 Instanzen aus dem Rahmen fielen. Es stellte sich die Frage, ob wir TeamCity kostenpflichtig erwerben oder auf das kostenlose Jenkins umsteigen sollten. Wir f\u00fchrten Berechnungen zu den Instanzen und Automatisierungspl\u00e4nen durch und entschieden uns, mit Jenkins zu arbeiten. Nach ein paar Wochen wechselten wir zu Jenkins und reduzierten einen Teil des Kopfzerbrechens, der mit der Wartung mehrerer TeamCity-Instanzen verbunden war. So konnten wir uns auf die Entwicklung von Integro konzentrieren und Jenkins an unsere Bed\u00fcrfnisse anpassen.<\/p>\n

Mit dem Anstieg der grundlegenden Automatisierung, wie der automatischen Erstellung von Pull Requests, dem Sammeln und Ver\u00f6ffentlichen von Code Coverage sowie anderen Pr\u00fcfungen, wurde der Wunsch laut, manuelle Releases m\u00f6glichst abzulehnen und diese Aufgabe Robotern zu \u00fcberlassen. Dar\u00fcber hinaus hat im Unternehmen der Umstieg auf Mikrodienste begonnen, die h\u00e4ufige Releases erforderten, und zwar unabh\u00e4ngig voneinander. So sind wir allm\u00e4hlich zu automatisierten Releases unserer Mikrodienste \u00fcbergegangen (das Monolith-Projekt wird aufgrund des komplexen Prozesses weiterhin manuell herausgegeben). Doch wie es oft der Fall ist, trat eine neue Herausforderung auf.\u00a0<\/p>\n

Wir automatisieren das Testing<\/h2>\n

\n\"Von
\n
\nDurch die Automatisierung der Releases wurden die Entwicklungsprozesse beschleunigt, wobei teilweise auf bestimmte Testphasen verzichtet wurde. Dies f\u00fchrte zu einem tempor\u00e4ren Qualit\u00e4tsverlust. Es mag banal klingen, aber mit der Beschleunigung der Releases musste auch die Produktentwicklungsmethodik \u00fcberdacht werden. Wir mussten \u00fcber die Automatisierung von Tests nachdenken, die pers\u00f6nliche Verantwortung der Entwickler f\u00fcr den produzierten Code und die darin enthaltenen Bugs f\u00f6rdern (hierbei geht es um das \u201eVerinnerlichen der Idee\u201c und nicht um finanzielle Strafen) und \u00fcber Entscheidungen zum Release\/Durchf\u00fchrung von Aufgaben durch automatisiertes Deployment nachdenken.\u00a0<\/p>\n

Um die Qualit\u00e4tsprobleme zu beheben, kamen wir zu zwei wichtigen Entscheidungen: Wir f\u00fchrten Kanarientests ein und implementierten ein automatisiertes Fehlermonitoring mit automatisierter Reaktion bei \u00dcberschreitung. Die erste L\u00f6sung erm\u00f6glicht es, offensichtliche Fehler zu erkennen, bevor der Code in die Produktion gelangt, w\u00e4hrend die zweite die Reaktionszeit auf Probleme in der Produktion verk\u00fcrzt hat. Fehler treten nat\u00fcrlich auf, aber wir investieren den Gro\u00dfteil unserer Zeit und Energie nicht in deren Behebung, sondern in deren Minimierung.\u00a0<\/p>\n

Automatisierungsteam<\/h2>\n

\nDerzeit haben wir ein Team von 130 Entwicklern und wachsen weiter. wachsen<\/a><\/noindex>. Das Team f\u00fcr kontinuierliche Integration und Codebereitstellung (im Folgenden als Deploy and Integration Team oder DI bezeichnet) besteht aus 7 Personen und arbeitet in 2 Bereichen: der Entwicklung der Automatisierungsplattform Integro und DevOps.\u00a0<\/p>\n

DevOps ist verantwortlich f\u00fcr die Dev\/Beta-Umgebungen der CIAN-Website sowie die Integro-Umgebungen. Es unterst\u00fctzt die Entwickler bei der L\u00f6sung von Problemen und entwickelt neue Ans\u00e4tze zur Skalierung dieser Umgebungen. Der Bereich der Integro-Entwicklung befasst sich sowohl mit Integro selbst als auch mit verwandten Diensten, zum Beispiel Plugins f\u00fcr Jenkins, Jira, Confluence, und entwickelt auch unterst\u00fctzende Tools und Anwendungen f\u00fcr Entwicklerteams.\u00a0<\/p>\n

Das DI-Team arbeitet eng mit dem Plattformteam zusammen, das f\u00fcr die Entwicklung von Architekturen, Bibliotheken und internen Entwicklungsans\u00e4tzen verantwortlich ist. Dar\u00fcber hinaus kann jeder Entwickler bei CIAN zur Automatisierung beitragen, indem er beispielsweise Mikroautomationen f\u00fcr die Bed\u00fcrfnisse seines Teams erstellt oder coole Ideen zur Verbesserung der Automatisierung teilt.<\/p>\n

Der mehrschichtige Ansatz zur Automatisierung bei CIAN<\/h2>\n

\n\"Von
\n
\nAlle Systeme, die in der Automatisierung eingesetzt werden, k\u00f6nnen in mehrere Schichten unterteilt werden:<\/p>\n

    \n
  1. Externe Systeme (Jira, Bitbucket usw.). Diese werden von den Entwicklungsteams genutzt.\n<\/li>\n
  2. Die Integro-Plattform. In der Regel arbeiten Entwickler nicht direkt damit, aber sie ist die Grundlage aller Automatisierungsprozesse.\n<\/li>\n
  3. Liefer-, Orchestrierungs- und Entdeckungsdienste (zum Beispiel Jenkins, Consul, Nomad). Mit ihrer Hilfe setzen wir Code auf Servern um und gew\u00e4hrleisten die Interaktion der Dienste miteinander.\n<\/li>\n
  4. Physische Ebene (Server, OS, zugeh\u00f6rige Software). Auf dieser Ebene arbeitet unser Code. Dies kann sowohl ein physischer Server als auch ein virtueller sein (LXC, KVM, Docker).\n<\/li>\n<\/ol>\n

    \nBasierend auf diesem Konzept teilen wir die Aufgabenbereiche innerhalb des DI-Teams. Die ersten beiden Ebenen fallen in den Verantwortungsbereich der Entwicklungsrichtung Integro, w\u00e4hrend die letzten beiden Ebenen in den Verantwortungsbereich von DevOps fallen. Diese Trennung erm\u00f6glicht es, sich auf Aufgaben zu konzentrieren und beeintr\u00e4chtigt nicht die Zusammenarbeit, da wir nahe beieinander sitzen und st\u00e4ndig Wissen und Erfahrungen austauschen.<\/p>\n

    Integro<\/h2>\n

    \nLassen Sie uns auf Integro konzentrieren und mit dem Technologie-Stack beginnen:<\/p>\n