Wir erstellen ein Cloud-Projekt für die Entwicklung - eine Plattform, die Entwicklern, Entwicklern, Testern, Teamleitern und anderen am Entwicklungsprozess beteiligten Spezialisten das Leben so weit wie möglich vereinfachen kann. Dieses Produkt ist nicht für jetzt und nicht für morgen, und die Notwendigkeit dafür wird gerade gebildet.
Die Hauptidee ist, dass Sie die Pipeline mit vorkonfigurierten Tools bereitstellen können, aber gleichzeitig mit der Möglichkeit, eine Reihe von Einstellungen vorzunehmen, müssen Sie nur den Code bereitstellen.
Woher kommt eine solche Perversion? Wir sehen einen klaren Trend, dass sich jetzt die Geschwindigkeit der Bereitstellung neuer Projekte auf den Markt auswirkt. Der Handel hängt davon ab, wie schnell Releases geliefert werden. Ab wie schnell Fehler behoben werden, wie schnell neue Nischen besetzt werden. Anfang 2018 führte das globale Unternehmen „451 Research“ eine Umfrage durch, welche Technologien für die Entwicklung Priorität haben werden. Zu den Top Ten gehören Technologien zur Erstellung und Verwaltung von Containern sowie serverlose Anwendungsarchitekturen und Microservices, die selbst ein Hype-Thema wie Blockchain überholen.
Und jetzt haben wir ein paar Fragen an Sie.
Grafik aus der Umfrage:
Ist es notwendig
Die Verwendung von Behältern bei der Entwicklung eines neuen Produkts hat sowohl Vor- als auch Nachteile. Ob diese Technologie eingesetzt werden soll oder nicht, muss anhand der gestellten Aufgaben entschieden werden. Bei einigen Aufgaben kann auf die Verwendung von Containern nicht verzichtet werden, bei einigen sind sie einfach überflüssig. Für Websites mit geringem Datenverkehr reicht beispielsweise eine einfache Architektur mit zwei Servern völlig aus. Wenn jedoch ein deutliches Entwicklungswachstum sowie ein enormer Besucheranstieg in kurzer Zeit geplant sind, lohnt es sich in diesem Fall, die Infrastruktur mit Containern in Betracht zu ziehen.
Die Verwendung von Behältern hat mehrere Vorteile:
- Jede Anwendung wird isoliert in einem eigenen Container ausgeführt, wodurch konfigurationsbedingte Probleme minimiert werden.
- Die Anwendungssicherheit wird auch durch Isolieren jedes Containers erreicht.
- Aufgrund der Tatsache, dass die Container den Kernel des Betriebssystems verwenden, wird das Gastbetriebssystem jetzt nicht mehr benötigt, wodurch eine große Menge an Ressourcen freigegeben wird.
- Aufgrund der Verwendung des Kernels des Betriebssystems und weil Sie sich nicht auf den Hypervisor verlassen müssen, benötigen Container im Vergleich zu anderen Stacks viel weniger Ressourcen.
- Aufgrund der Tatsache, dass für die Container kein Gastbetriebssystem erforderlich ist, können sie problemlos von einem Server auf einen anderen migriert werden.
- Aufgrund der Tatsache, dass jede Anwendung in einem isolierten Container ausgeführt wird, ist die Übertragung vom lokalen Computer in die Cloud einfach.
- Das Starten und Stoppen des Containers ist aufgrund der Verwendung des Kernels des Betriebssystems sehr „billig“.
In Verbindung mit all dem glauben wir, dass die Containerisierungstechnologie derzeit der schnellste, ressourceneffizienteste und sicherste Stack ist. Aufgrund der Vorteile von Containern können Sie sowohl auf der lokalen Maschine als auch in der Produktion dieselbe Umgebung haben, was den Prozess der kontinuierlichen Integration und Lieferung erleichtert.
Die Vorteile von Containern sind so überzeugend, dass sie definitiv noch lange genutzt werden.
Was hat die Cloud mit Entwicklung zu tun?
In der idealen Welt des Entwicklers sollte jeder Commit-Code auf Knopfdruck wie von Zauberhand in die Produktion eingeführt werden.
Wir hatten es so: Es gibt einen Gitlabchik mit Aufgaben und einer Quelle. Wenn Sie etwas sammeln müssen - GitLab Runner. Wir arbeiten an Git Flow, alle Funktionen in separaten Zweigen. Wenn ein Zweig in das Repository gelangt, werden Tests mit diesem Code in GitLab gestartet. Wenn die Tests bestanden wurden, kann der Entwickler dieses Threads eine Zusammenführungsanforderung stellen, tatsächlich eine Anforderung für eine Codeüberprüfung. Nach der Überprüfung wird der Zweig akzeptiert, in den Entwicklungszweig eingefügt und erneut getestet. Bei der Bereitstellung sammelt GitLab Runner den Docker-Container und rollt ihn auf den Staging-Server, wo er angeklickt und erfreut werden kann. Und hier ist der erste Gag - wir durchsuchen den Code mit unseren Händen nach Konformität mit der Funktion und dies ist das erste, was wir beheben. Danach fügen wir den Code in den Release-Zweig ein. Und für sie führen wir eine separate vorproduktive Version unserer Lösung ein, die unsere Geschäftskunden beobachten. Nachdem die Version auf dem Pre-Prod vorinstalliert ist, rollen wir sie in die Produktion und sie rollt zu den Produktknoten. Es gibt automatisch generierte Versionshinweise und Fehlerberichte. Die Montagegeschwindigkeit betrug mehr als 30 Minuten, jetzt ist sie um eine Größenordnung geringer. Wir haben eine Reihe von Tools für uns ausgewählt und überlegen nun, wie wir dasselbe fertige SaaS erstellen können.
Für uns ist der typische Freigabeprozess für die Freigabe wie folgt:
- Festlegen von Zielen für die Implementierung neuer Funktionen
- Code-Lokalisierung
- Änderungen entsprechend den Aufgaben vornehmen. Schreiben automatisierter Tests vor dem Build.
- Codeüberprüfung, sowohl manuell als auch selbsttestend
- Code in einem Entwicklungszweig zusammenführen
- Erstellen Sie einen Entwicklungszweig
- Stellen Sie die Testinfrastruktur bereit
- Stellen Sie die Version in der Testinfrastruktur bereit
- Ausführen von Tests, Funktionen, Integration usw.
- Beenden Sie Fehler sofort im Entwicklungszweig
- Migrieren eines Entwicklungszweigs zu einem Hauptzweig
Hier ist ein Diagramm mit Details zu unserem Prozess:
Eigentlich die erste Frage - bitte sagen Sie uns, wo Sie harken, was für ein Rake war und wie universell dieses Schema ist oder nicht. Wenn Sie einen Workflow verwenden, der sich stark von diesem unterscheidet, fügen Sie bitte ein paar Wörter hinzu.
Welche Art von Produkt planen wir?
Wir haben uns entschlossen, Amazon in dieser Hinsicht nicht zu kopieren, sondern unsere Entwicklung unter Berücksichtigung der Besonderheiten des Marktes durchzuführen. Machen Sie sofort einen Vorbehalt, dass alle Berechnungen aufgrund unserer Analyse unsere subjektive Meinung sind. Wir sind offen für einen konstruktiven Dialog und bereit, die Roadmap des Produkts zu ändern.
Bei der Analyse der vorhandenen Pipeline von Amazon kamen wir zu dem Schluss, dass sie über enorme Funktionen verfügt, der Schwerpunkt jedoch auf sehr großen Unternehmensteams liegt. Es schien uns, dass die Einführung eines Microservices in Docker unangemessen lang ist, mehr als wenn er beispielsweise in Kubernetes eingeführt wurde, weil Es gibt einen Ort, an dem interne Konfigurationen konfiguriert, interne Vereinbarungen definiert usw. werden können. und all dies muss für eine lange Zeit verstanden werden.
Auf der anderen Seite gibt es beispielsweise Heroku, wo Sie mit einem Klick bereitstellen können. Aufgrund der Tatsache, dass Projekte mit Microservices von Drittanbietern in der Regel ziemlich verzweigt sind, wird es irgendwann erforderlich, benutzerdefinierte Docker-Images mit DBaaS-Diensten bereitzustellen, und all dies passt nicht in Herocku, da es entweder teuer ist entweder unangenehm.
Wir wollen eine andere Option finden. Das goldene Mittel. Stellen Sie Ihnen je nach Art des Projekts und der Aufgaben eine Reihe bereits vorkonfigurierter Tools zur Verfügung, die bereits in eine einzelne Pipeline integriert sind. Dabei bleibt sowohl die Möglichkeit einer tiefgreifenden Änderung der Einstellungen als auch die Möglichkeit, die Tools selbst zu ersetzen.
Also was wird es sein?
Ökosystem, das ein Portal sowie eine Reihe von Tools und Diensten umfasst, um die Interaktion von Entwicklern mit der Infrastrukturebene zu minimieren. Sie definieren Umgebungsparameter, die nicht an die physische Umgebung gebunden sind:
- Entwicklungsumgebung (Konfigurationsmanagementsystem, Aufgabeneinstellungssystem, Repository zum Speichern von Code und Artefakten, Task-Tracker)
- CI - Kontinuierliche Integration (Assembly, Infrastruktur und Orchestrierung)
- QA - Qualitätssicherung (Testen, Überwachen und Protokollieren)
- Staging - Integrationsumgebung / Prerelease-Schleife
- Produktion - Produktiver Kreislauf
Bei der Auswahl der Tools haben wir uns auf Best Practices auf dem Markt konzentriert.
Wir werden die Infrastruktur mit Stage und Prod unter Verwendung von Docker und Kubernetes mit parallelem Feature-Dusting aufbauen.
Dies geschieht iterativ. In der ersten Phase ist ein Dienst geplant, mit dem Sie die Docker-Datei aus dem Projekt entnehmen, den erforderlichen Container sammeln und an Kubernetes auslegen können.
Wir planen außerdem, dem Service zur Überwachung des Entwicklungsprozesses und der kontinuierlichen Lieferung besondere Aufmerksamkeit zu widmen. Was verstehen wir unter diesem Service? Dies ist eine Gelegenheit, ein hierarchisches KPI-Modell mit Indikatoren wie prozentualer Abdeckung durch Komponententests, durchschnittliche Zeit zur Beseitigung eines Vorfalls oder Defekts, durchschnittliche Zeit von der Festschreibung bis zur Lieferung usw. zu erstellen.
Die Erfassung von Quelldaten aus verschiedenen Systemen - Testmanagementsysteme, Aufgabenverwaltung, CI / CD-Komponenten, Infra-Monitoring-Tools usw.
Und das Wichtigste ist, in einer angemessenen Form zu zeigen, die für eine schnelle Analyse zur Verfügung steht - Dashboards mit der Möglichkeit eines Drilldowns, einer vergleichenden Analyse von Indikatoren.
Was wollen wir tun?
Eigentlich würde ich gerne von Ihnen über all das und unsere Pläne für Schritte hören. Jetzt sind sie:
- Infrastruktur und Orchestrierung - Docker & Kubernetes
- Aufgabeneinstellung, Code- und Artefaktspeicherung, Task-Tracker - Gitlab, Redmine, S3
- Produktion & Entwicklung - Chef / Ansible
- Versammlung - Jenkins
- Testen - Selen, LoadRunner
- Überwachung und Protokollierung - Prometheus & ELK
- Übrigens, wie sehen Sie, ob es innerhalb der Plattform eine Auswahl gibt - wenn Sie wollten, wählten Sie Jenkins, wollten Sie nicht - GitLab Runner?
- Oder spielt es keine Rolle, was sich darin befindet, die Hauptsache ist, dass alles richtig gebaut, getestet und bereitgestellt wird?
Wie kann man helfen?
Das Produkt wird für inländische Entwickler entwickelt. Wenn Sie uns jetzt sagen, wie es geht, ist es wahrscheinlich, dass es in der Version enthalten sein wird.
Bitte sagen Sie mir, welche Stapel Sie gerade verwenden. Sie können - in den Kommentaren oder per E-Mail an team@ts-cloud.ru.
UPD: Der Einfachheit halber haben wir hier einen kurzen Fragebogen in Google-Form erstellt.
Außerdem werden wir Sie über die Entwicklung auf dem Laufenden halten - und den unterstützenden Teilnehmern irgendwann Zugang zur Beta gewähren (in der Tat freien Zugang zu guten Computerressourcen der Cloud im Austausch für Feedback).