Get best of the week

Portal für Testumgebungen oder Speichern Sie unsere Entwickler



Vor ein paar Jahren fühlten wir uns in einer Art surrealem Traum. Alle Mitarbeiter gingen zum Testen in die Cloud (es ist praktisch, Testumgebungen zu erweitern und zu reduzieren), und wir haben versucht herauszufinden, welche sofort einsatzbereiten Tools geliefert werden sollten. Dazu haben wir gemeinsam mit Kunden herausgefunden, wie die Devops-Prozesse funktionieren. Und es stellte sich heraus, dass nur wenige Unternehmen in Russland die Automatisierung kompetent einsetzen.

Ich werde sofort erklären, dass wir größtenteils entweder mit denen gesprochen haben, die an der Entwicklung von bis zu 150 bis 200 Mitarbeitern im Unternehmen beteiligt sind, oder mit Branchen, in denen die IT traditionell schwierig ist. Größere Unternehmen haben normalerweise sowohl einen Prozess als auch eine eigene Cloud und kommen zu uns, um Backups bereitzustellen.

Die Produktion ist in der Regel gut etabliert. Es gibt einen Zyklus, einen Release-Plan, es gibt ein Ziel, der Code geht zusammen mit den Entwicklern zum Ziel.

Tests und Qualitätssicherung werden auch am häufigsten getestet.

Und zwischen ihnen gibt es einen Abgrund. Und DevOps versucht es zu füllen. Dieser Superman sollte die Freigabe nehmen (und sie idealerweise in Jenkins oder ähnlichem zusammenbauen), ein Auto erstellen, alles dort einsetzen, die Arbeit überprüfen, vielleicht ein paar Vortests ausgeben und sie der Qualitätssicherung geben.

Was ist das Problem?


Wenn es sich bei einem Produkt um eine kleine Art von Webanwendung handelt, gibt es kein Problem. Der Entwickler oder Tester nimmt die Datenbank direkt aus dem Backup, stellt eine Verbindung zur neuesten Version her und läuft weiter.

Aber wenn das Produkt ein wenig wächst, setzt der Produktionszusammenbruch ein.

Devops bekam die Freilassung, aber er nahm sie und hatte nicht vor. Dann beginnt er nach dem Extrem zu suchen und die Entwickler zu sortieren. Eine Version kann nachts mehrere Stunden lang gesammelt werden, und Entwickler sitzen normalerweise tagsüber im Büro.

Fast alles wird von Hand gemacht. Das heißt, die Ops sitzen und schauen auf den Fortschrittsbalken der Versammlung. Denn überall kann etwas schief gehen. Diejenigen, die energischer sind, binden dies alles mit ihren eigenen Skripten, und manchmal fällt es sehr schön und effizient aus. Aber öfter sehen wir, dass der Freigabeplan schrittweise ausgeführt wird, eine separate Person für jeden Schritt verantwortlich ist und es für ihn einfacher ist, den Vorgang zwanzig Mal mit den Händen zu wiederholen, da sich sonst herausstellt, dass er nicht funktioniert.

Gleichzeitig sollte jemand für den gesamten Prozess verantwortlich sein, und dies ist der Hauptstoppfaktor. Der Versuch, eine solche Person zu finden, scheitert oft. Er ist nämlich für die Automatisierung verantwortlich, und er ist es, der daran interessiert ist. Es ist natürlich immer einfacher, für einzelne Abschnitte verantwortlich zu sein und dann die Pfeile an jemanden in der Entwicklung zu übertragen.

Die Virtualisierung fügt weitere Aspekte des Chaos hinzu. Virtuelle Umgebungen sind immer ein Chaos. Die Person, die für die Gruppierung verantwortlich ist (Server, Rack), ist schlecht orientiert, wem das gehört, ob es notwendig ist oder nicht. Es ist logisch, dass sich der Systemadministrator nicht viel Gedanken darüber machen muss, was mit den Entwicklern los ist. Aber Devops sollten, aber seine Rolle impliziert normalerweise kein solches Wissen. Und er hat Angst, den Überschuss auszuschalten, weil er nicht versteht, ob er noch gebraucht wird oder nicht.

Dann ist es notwendig, interne Konten für die gegenseitige Abrechnung von Abteilungen auszustellen. Jemand denkt über die Verfügbarkeit nach, jemand über die Verwendung des Prozessors, dann teilen sie sich die Kosten wie Strom und die Arbeit der Administratoren zu gleichen Teilen oder in bestimmten Anteilen.

Unerwartet, aber kein fertiges Produkt


Es scheint, dass dieser gesamte Förderer mit einer Art Produkt bedeckt sein sollte. Es gibt viele gute Punktlösungen. Derselbe Ansible wird perfekt bereitgestellt, weiß jedoch nicht, wie virtuelle Maschinen gesteuert werden sollen. Und Hypervisoren können. Es gibt alle Tools für Devops-Scripting, Sie können die Module verbinden ... Sie müssen nur diese Softwarekette übernehmen und zusammenbauen, oder?

Nicht so. Banken und staatliche Unternehmen hatten den Wunsch, in der Cloud zu testen. Jeder gute Wachmann ist anfällig für Paranoia, oft aus gutem Grund. Für die IB Bank ist jede Neuinstallation ein sehr ärgerlicher Faktor. Ich kenne einen Fall, in dem Ops Jenkins und Terraform in die Infrastruktur gezogen, Bash dahinter bereitgestellt und dann das DBMS, das all dies enthält. Es stellte sich heraus, dass es sich um ein gutes halbautomatisches Förderband handelte, das bis zu einem vollständig autonomen Einsatz fertiggestellt werden konnte. Nur für die Informationssicherheit war es eine Katastrophe.

Sie wollten alles in einem. Und um die virtuelle Maschine (und verschiedene Anbieter, einschließlich Openstack) zu verwalten. Ein Kunde in einer Anwendung kann sowohl Vmvara als auch Hyper-in haben und etwas anderes, das für die Unterstützung von FreeBSD oder OS / 2 alt und schrecklich ist.

Wir brauchen unser Fahrrad


Im Allgemeinen haben wir unsere Plattform geschrieben. Unter der Haube - Ansible, out of the box - Integration mit Jenkins. Sie können Ihre eigenen Skripte für Ansible schreiben. Sie können alles von der Subnetzsammlung bis zum Release-Management tun.



Das Portal lebt im Paradigma der Testumgebung. Dies ist seine Hauptessenz. Eine Testumgebung = ein Subnetz. Wenn es wirklich schlecht ist, gibt es eine Integration mit dem RPA, falls keine API vorhanden ist, und Sie benötigen einen Roboter, um Benutzeraktionen zu emulieren und auf Schaltflächen in der Benutzeroberfläche zu klicken. Abrechnung, Verfügbarkeit und Auslastung werden entweder von Antrag zu Antrag berücksichtigt: Bis die Zerstörungsanforderung geschrieben wurde, tropft das Geld.

So sieht es aus. Erstellen einer Umgebung mithilfe einer Vorlage:



Hinzufügen einer virtuellen Maschine:



Skripterstellung:



Wie sich wenig später herausstellte, sind die Beschwerden „Ich möchte nicht auf 50 Systemen laufen“ von allen Seiten zu hören. Wir hatten wichtige Schmerzen. Jeder große Kunde mit Tests wollte etwas Ähnliches, löste es jedoch aus irgendeinem Grund nicht oder organisatorisch mit Skriptleuten. Die Probleme sind sehr unterschiedlich, angefangen bei namenlosen virtuellen Computern (sie haben sie gelöscht, und dann erinnerte sich jemand daran, dass sie benötigt wurden) bis hin zur Tatsache, dass niemand für die fortlaufenden Skripte verantwortlich sein möchte. Roll-up-Skripte sind schwer zu schreiben, auch die Vorschriften leiden darunter. Irgendwann im Zyklus sollten die Daten anonymisiert werden, und es sieht so aus, als hätten wir zu Beginn des Jahres eine anonyme Datenbank erstellt. Die Software wurde sechsmal geändert und die Daten wurden aktualisiert.

Wenn Ihnen etwas Ähnliches plötzlich weh tut, schauen Sie einfach zu. Der Demo-Zugriff ist in der Technoserv Cloud verfügbar .

More articles:


All Articles