{"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 zur 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 hat unser Kollege Alexander Korotkov Bericht<\/a><\/noindex> \u00fcber die Automatisierung der Entwicklung bei CIAN gesprochen: Um das Leben und die Arbeit zu erleichtern, nutzen wir unsere eigene Plattform Integro. Sie verfolgt den Lebenszyklus von Aufgaben, befreit Entwickler von Routineoperationen und reduziert signifikant die Anzahl der Bugs in der Produktion. In diesem Beitrag werden wir Alexanders Vortrag erg\u00e4nzen und erz\u00e4hlen, wie wir den Weg von einfachen Skripten zur Integration von Open-Source-Produkten \u00fcber unsere eigene Plattform gegangen sind und womit unser separates Automatisierungsteam besch\u00e4ftigt ist.
\n\u00a0<\/a><\/noindex><\/p>\n

Nullniveau<\/h2>\n

\n\u00abEs gibt kein Nullniveau, ich kenne so etwas nicht\u00bb<\/b>
\nMeister Shifu aus dem Film \u00abKung-Fu Panda\u00bb<\/i><\/p>\n

Die Automatisierung bei CIAN begann 14 Jahre nach der Gr\u00fcndung des Unternehmens. Damals bestand das Entwicklungsteam aus 35 Personen. Es ist schwer zu glauben, oder? Nat\u00fcrlich gab es in gewisser Weise schon Automation, aber ein separates Konzept f\u00fcr kontinuierliche Integration und Code-Auslieferung begann erst 2015 Gestalt anzunehmen.\u00a0<\/p>\n

Zu diesem Zeitpunkt hatten wir ein riesiges Monolith aus Python, C# und PHP, das auf Linux-\/Windows-Servern bereitgestellt war. F\u00fcr die Bereitstellung dieses Monsters hatten wir eine Sammlung von Skripten, die wir manuell ausf\u00fchrten. Es gab auch die Zusammenstellung des Monolithen, die Schmerz und Leiden durch Konflikte beim Zusammentragen von Branches, Fehlerkorrekturen und das erneute Zusammenstellen \u201emit einem anderen Aufgabenpaket im Build\u201c bereitete. Vereinfacht sah der Prozess so aus:<\/p>\n

\"Von
\n
\nDas gen\u00fcgte uns nicht, und wir wollten einen wiederholbaren, automatisierten und steuerbaren Prozess f\u00fcr das Bauen und Bereitstellen aufbauen. Daf\u00fcr ben\u00f6tigten wir ein CI\/CD-System und w\u00e4hlten zwischen der kostenlosen Version von Teamcity und Jenkins, da wir mit beiden gearbeitet hatten und beide uns hinsichtlich der Funktionalit\u00e4ten zusagten. Wir entschieden uns f\u00fcr Teamcity als das neuere Produkt. Zu diesem Zeitpunkt verwendeten wir noch keine Microservices-Architektur und rechneten nicht mit vielen Aufgaben und Projekten.<\/p>\n

Wir kamen zu der Idee eines eigenen Systems<\/h2>\n

\nDie Einf\u00fchrung von Teamcity hat nur einen Teil der manuellen Arbeit beseitigt: Es blieb noch die Erstellung von Pull Requests, die Fortschreibung von Aufgaben in Jira und die Auswahl von Aufgaben f\u00fcr die Ver\u00f6ffentlichung. Mit dieser Aufgabe konnte das Teamcity-System nicht mehr umgehen. Es musste ein Weg zur weiteren Automatisierung gefunden werden. Wir haben die Optionen f\u00fcr die Arbeit mit Scripts in Teamcity oder den Umstieg auf externe Automatisierungssysteme gepr\u00fcft. Letztendlich haben wir entschieden, dass wir die maximale Flexibilit\u00e4t ben\u00f6tigen, die nur eine eigene L\u00f6sung bieten kann. So entstand die erste Version des internen Automatisierungssystems namens Integro.<\/p>\n

Teamcity k\u00fcmmert sich um die Automatisierung auf der Ebene des Starts von Build- und Deploy-Prozessen, w\u00e4hrend Integro sich auf die hochgradige Automatisierung von Entwicklungsprozessen konzentriert hat. Es war n\u00f6tig, die Arbeit mit den Aufgaben in Jira mit der Verarbeitung des zugeh\u00f6rigen Quellcodes in Bitbucket zu verbinden. In dieser Phase begannen innerhalb von Integro eigene Workflows f\u00fcr die Bearbeitung von Aufgaben verschiedener Typen zu entstehen.\u00a0<\/p>\n

Durch die zunehmende Automatisierung der Gesch\u00e4ftsprozesse erh\u00f6hte sich die Anzahl der Projekte und Runs in Teamcity. So trat ein neues Problem auf: Ein kostenloser Teamcity-Instanz reichte nicht mehr aus (3 Agenten und 100 Projekte), wir haben eine weitere Instanz hinzugef\u00fcgt (noch 3 Agenten 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 es so nicht weitergehen konnte, da die Gesamtkosten f\u00fcr die Unterst\u00fctzung von vier Instanzen schon nicht mehr tragbar waren. Es stellte sich die Frage, ob wir Teamcity kaufen oder uns f\u00fcr die kostenlose Jenkins entscheiden sollten. Wir haben die Berechnungen f\u00fcr die Instanzen und die Automatisierungspl\u00e4ne durchgef\u00fchrt und entschieden, dass wir mit Jenkins leben werden. Nach ein paar Wochen sind wir auf Jenkins umgestiegen und haben einen Teil der Kopfschmerzen, die mit der Unterst\u00fctzung mehrerer Teamcity-Instanzen verbunden waren, losgeworden. Daher konnten wir uns auf die Entwicklung von Integro und die Anpassung von Jenkins konzentrieren.<\/p>\n

Mit dem Anstieg der grundlegenden Automatisierung (in Form der automatischen Erstellung von Pull Requests, der Erfassung und Ver\u00f6ffentlichung der Codeabdeckung und anderer \u00dcberpr\u00fcfungen) gab es den nachhaltigen Wunsch, manuelle Releases m\u00f6glichst abzulehnen und diese Arbeit den Robotern zu \u00fcberlassen. Dar\u00fcber hinaus begann innerhalb des Unternehmens der Umstieg auf Mikrodienste, die h\u00e4ufige Releases erforderten, und zwar getrennt voneinander. So kamen wir schrittweise zu automatisierten Releases unserer Mikrodienste (das Monolith wird aufgrund der Komplexit\u00e4t des Prozesses bisher manuell ver\u00f6ffentlicht). Doch wie das h\u00e4ufig der Fall ist, trat eine neue Komplikation auf.\u00a0<\/p>\n

Automatisieren wir das Testen<\/h2>\n

\n\"Von
\n
\nDurch die Automatisierung der Releases haben sich die Entwicklungsprozesse beschleunigt, teilweise auch auf Kosten des \u00dcberspringens bestimmter Testphasen. Das f\u00fchrte zu einem vor\u00fcbergehenden Qualit\u00e4tsverlust. Es klingt banal, aber zusammen mit der Beschleunigung der Releases musste auch die Methodik der Produktentwicklung ge\u00e4ndert werden. Wir mussten \u00fcber die Automatisierung von Tests nachdenken, die pers\u00f6nliche Verantwortung (hier geht es um das \u201eVerstehen der Idee im Kopf\u201c, nicht um Geldstrafen) der Entwickler f\u00fcr den Code und die Fehler darin, sowie um die Entscheidung \u00fcber das Release\/nicht Release der Aufgaben durch automatisiertes Deployment.\u00a0<\/p>\n

Um die Qualit\u00e4tsprobleme zu beheben, haben wir zwei wichtige Entscheidungen getroffen: Wir haben Canaries-Tests eingef\u00fchrt und die automatische \u00dcberwachung von Fehlern mit automatisierter Reaktion auf deren \u00dcberschreitung implementiert. Die erste Entscheidung erm\u00f6glichte es, offensichtliche Fehler zu erkennen, bevor der Code vollst\u00e4ndig in die Produktion gelangte, die zweite reduzierte die Reaktionszeit auf Probleme in der Produktion. Fehler gibt es nat\u00fcrlich, aber wir verbringen den Gro\u00dfteil unserer Zeit und Energie nicht mit der Behebung, sondern mit der Minimierung.\u00a0<\/p>\n

Das Automatisierungsteam<\/h2>\n

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

DevOps ist verantwortlich f\u00fcr die Dev\/Beta-Umgebungen der CIAN-Website, die Integro-Umgebungen und unterst\u00fctzt die Entwickler bei der L\u00f6sung von Problemen und der Entwicklung neuer Ans\u00e4tze zur Skalierung der Umgebungen. Der Entwicklungsbereich f\u00fcr Integro k\u00fcmmert sich sowohl um Integro selbst als auch um verwandte Dienste, wie Plugins f\u00fcr Jenkins, Jira, Confluence, und entwickelt au\u00dferdem unterst\u00fctzende Tools und Anwendungen f\u00fcr Entwicklerteams.\u00a0<\/p>\n

Das DI-Team arbeitet eng mit dem Plattformteam zusammen, das sich mit der Entwicklung der Architektur, Bibliotheken und Entwicklungsans\u00e4tzen innerhalb des Unternehmens besch\u00e4ftigt. Dar\u00fcber hinaus kann jeder Entwickler innerhalb von CIAN zu Automatisierungen beitragen, zum Beispiel Mikroautomatisierungen f\u00fcr die Bed\u00fcrfnisse des Teams erstellen oder eine gro\u00dfartige Idee teilen, wie man die Automatisierung noch besser gestalten kann.<\/p>\n

Schichtkuchen der Automatisierung bei CIAN<\/h2>\n

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

    \n
  1. Externe Systeme (Jira, Bitbucket usw.). Diese werden von den Entwicklungsteams verwendet.\n<\/li>\n
  2. Die Integro-Plattform. H\u00e4ufig arbeiten die Entwickler nicht direkt damit, aber sie unterst\u00fctzt die gesamte Automatisierungsarbeit.\n<\/li>\n
  3. Liefer-, Orchestrierungs- und Entdeckungsdienste (zum Beispiel Jenkins, Consul, Nomad). Mit deren Hilfe setzen wir den Code auf Servern um und sorgen daf\u00fcr, dass die Dienste miteinander funktionieren.\n<\/li>\n
  4. Physikalischer Ebene (Server, Betriebssysteme, verwandte Software). Auf dieser Ebene l\u00e4uft unser Code. Dies kann sowohl ein physischer Server als auch ein virtueller (LXC, KVM, Docker) sein.\n<\/li>\n<\/ol>\n

    \nBasierend auf diesem Konzept teilen wir die Zust\u00e4ndigkeiten innerhalb des DI-Teams. Die ersten beiden Ebenen liegen im Verantwortungsbereich der Integro-Entwicklung, w\u00e4hrend die letzten beiden Ebenen im Zust\u00e4ndigkeitsbereich von DevOps liegen. Diese Aufteilung erm\u00f6glicht es, sich auf die Aufgaben zu konzentrieren und st\u00f6rt nicht die Interaktion, da wir nah beieinander sind und st\u00e4ndig Wissen und Erfahrungen austauschen.<\/p>\n

    Integro<\/h2>\n

    \nKonzentrieren wir uns auf Integro und beginnen wir mit dem Technologiestack:<\/p>\n