Wir haben DevOps so gut wie möglich entwickelt. Wir waren zu acht und Vasya war die Coolste in Windows. Plötzlich ging Vasya und ich hatte die Aufgabe, ein neues Projekt zu starten, das von der Windows-Entwicklung bereitgestellt wurde. Als ich den gesamten Windows-Entwicklungsstapel auf den Tisch warf, wurde mir klar, dass die Situation schmerzhaft war ...
So beginnt die Geschichte Alexandra Sinchinova auf . Als der führende Windows-Spezialist das Unternehmen verließ, fragte sich Alexander, was er jetzt tun sollte. Natürlich auf Linux umsteigen! Alexander erzählt Ihnen am Beispiel eines abgeschlossenen Projekts für 100 Endbenutzer, wie es ihm gelungen ist, einen Präzedenzfall zu schaffen und einen Teil der Windows-Entwicklung auf Linux zu übertragen.
Wie kann man ein Projekt mit TFS, Puppet und Linux .NET Core einfach und mühelos an RPM liefern? Wie kann die Versionierung einer Projektdatenbank unterstützt werden, wenn das Entwicklungsteam zum ersten Mal die Wörter Postgres und Flyway hört und die Frist übermorgen ist? Wie integriert man Docker? Wie kann man .NET-Entwickler motivieren, Windows und Smoothies zugunsten von Puppet und Linux aufzugeben? Wie können ideologische Konflikte gelöst werden, wenn weder die Kraft noch der Wunsch noch die Ressourcen vorhanden sind, um Windows in der Produktion aufrechtzuerhalten? Darüber sowie über Web Deploy, Testing, CI, über die Praktiken der Verwendung von TFS in bestehenden Projekten und natürlich über kaputte Krücken und funktionierende Lösungen im Transkript von Alexanders Bericht.
Also, Vasya ist gegangen, die Aufgabe liegt bei mir, die Entwickler warten ungeduldig mit Mistgabeln. Als mir schließlich klar wurde, dass Vasya nicht zurückgegeben werden konnte, machte ich mich an die Arbeit. Zunächst habe ich den Prozentsatz der Win-VMs in unserer Flotte bewertet. Die Bewertung fiel nicht zugunsten von Windows aus.
Da wir DevOps aktiv weiterentwickeln, wurde mir klar, dass bei der Herangehensweise an die Bereitstellung einer neuen Anwendung etwas geändert werden muss. Es gab nur eine Lösung: Wenn möglich, alles auf Linux übertragen. Google hat mir geholfen – zu diesem Zeitpunkt war .Net bereits auf Linux portiert und mir wurde klar, dass dies die Lösung war!
Warum .NET Core in Verbindung mit Linux?
Dafür gab es mehrere Gründe. Zwischen „Geld zahlen“ und „nicht zahlen“ wird sich die Mehrheit – wie ich – für das zweite entscheiden. Eine Lizenz für MSDB kostet etwa 1 US-Dollar; die Wartung einer Flotte virtueller Windows-Maschinen kostet Hunderte von US-Dollar. Für ein großes Unternehmen ist das ein großer Aufwand. Deshalb Ersparnisse - erster Grund. Nicht das Wichtigste, aber eines der Bedeutendsten.
Virtuelle Windows-Maschinen beanspruchen mehr Ressourcen als ihre Linux-Brüder – Sie sind schwer. Angesichts der Größe des großen Unternehmens haben wir uns für Linux entschieden.
Das System wird einfach in die bestehende CI integriert. Wir verstehen uns als fortschrittliches DevOps, wir verwenden Bamboo, Jenkins und GitLab CI, daher läuft der Großteil unserer Arbeit unter Linux.
Der letzte Grund ist bequeme Begleitung. Wir mussten die Eintrittsbarriere für „Escorts“ senken – die Leute, die den technischen Teil verstehen, einen unterbrechungsfreien Service gewährleisten und Services von der zweiten Linie aus aufrechterhalten. Sie waren bereits mit dem Linux-Stack vertraut, sodass es für sie viel einfacher ist, ein neues Produkt zu verstehen, zu unterstützen und zu warten, als zusätzliche Ressourcen aufzuwenden, um die gleiche Funktionalität von Software für die Windows-Plattform zu verstehen.
Bedarf
Zuallererst - Komfort der neuen Lösung für Entwickler. Nicht alle waren bereit für Veränderungen, insbesondere nachdem das Wort Linux fiel. Entwickler möchten ihr Lieblings-Visual Studio, TFS mit Autotests für Assemblys und Smoothies. Wie die Lieferung an die Produktion erfolgt, ist ihnen nicht wichtig. Deshalb haben wir uns entschieden, den üblichen Prozess nicht zu ändern und alles für die Windows-Entwicklung unverändert zu lassen.
Neues Projekt erforderlich in bestehende CI integrieren. Die Schienen waren bereits vorhanden und alle Arbeiten mussten unter Berücksichtigung der Parameter des Konfigurationsmanagementsystems, akzeptierter Lieferstandards und Überwachungssysteme durchgeführt werden.
Einfache Unterstützung und Bedienung, als Bedingung für die Mindesteintrittsschwelle für alle neuen Teilnehmer aus verschiedenen Unternehmensbereichen und der Supportabteilung.
Frist - gestern.
Entwicklungsgruppe gewinnen
Womit arbeitete das Windows-Team damals?
Jetzt kann ich das getrost sagen IdentityServer4 ist eine coole kostenlose Alternative zu ADFS mit ähnlichen Funktionen, oder was auch immer Entity Framework-Kern - ein Paradies für Entwickler, in dem man sich nicht die Mühe machen muss, SQL-Skripte zu schreiben, sondern Abfragen in der Datenbank in OOP-Begriffen beschreiben muss. Aber dann, während der Diskussion des Aktionsplans, betrachtete ich diesen Stack, als wäre er eine sumerische Keilschrift, und erkannte nur PostgreSQL und Git.
Zu dieser Zeit nutzten wir aktiv Marionette als Konfigurationsmanagementsystem. In den meisten unserer Projekte verwendeten wir GitLab-CI, Elastisch, ausgewogene Hochlastdienste mit HAProxy überwachte alles mit Zabbix, Bänder Grafana и Prometheus, Jaeger, und das alles drehte sich auf Eisenstücken HP c ESXi auf VMware. Jeder kennt es – ein Klassiker des Genres.
Schauen wir uns das an und versuchen wir zu verstehen, was passiert ist, bevor wir mit all diesen Interventionen begonnen haben.
Was war
TFS ist ein ziemlich leistungsfähiges System, das nicht nur Code vom Entwickler an die endgültige Produktionsmaschine liefert, sondern auch über eine Reihe sehr flexibler Integrationen mit verschiedenen Diensten verfügt – um CI auf plattformübergreifender Ebene bereitzustellen.
Bisher handelte es sich dabei um Massivfenster. TFS verwendete mehrere Build-Agenten, die zum Zusammenstellen vieler Projekte verwendet wurden. Jeder Agent verfügt über 3-4 Mitarbeiter, um Aufgaben zu parallelisieren und den Prozess zu optimieren. Anschließend lieferte TFS gemäß den Release-Plänen den frisch gebackenen Build an den Windows-Anwendungsserver.
Was wollten wir erreichen?
Wir verwenden TFS für die Bereitstellung und Entwicklung und führen die Anwendung auf einem Linux-Anwendungsserver aus, und zwischen beiden liegt eine Art Magie. Das magic Box und da ist das Salz der Arbeit, die vor uns liegt. Bevor ich es auseinandernehme, mache ich einen Schritt zur Seite und sage ein paar Worte zur Anwendung.
Projekt
Die Anwendung bietet Funktionalität für den Umgang mit Prepaid-Karten.
Kunden
Es gab zwei Arten von Benutzern. Erste Zugriff erhalten, indem Sie sich mit einem SSL-SHA-2-Zertifikat anmelden. U zweiten Der Zugang erfolgte mit Login und Passwort.
HAProxy
Dann ging die Client-Anfrage an HAProxy, was die folgenden Probleme löste:
- primäre Autorisierung;
- SSL-Terminierung;
- Optimieren von HTTP-Anfragen;
- Sendeanfragen.
Das Client-Zertifikat wurde entlang der Kette überprüft. Wir - Autorität Und das können wir uns leisten, da wir selbst Zertifikate für Servicekunden ausstellen.
Achten Sie auf den dritten Punkt, wir werden etwas später darauf zurückkommen.
Backend
Sie planten, das Backend auf Linux zu erstellen. Das Backend interagiert mit der Datenbank, lädt die erforderliche Liste der Berechtigungen und gewährt dann, abhängig von den Berechtigungen des autorisierten Benutzers, Zugriff, um Finanzdokumente zu signieren und zur Ausführung zu senden oder eine Art Bericht zu erstellen.
Einsparungen mit HAProxy
Zusätzlich zu den beiden Kontexten, in denen jeder Kunde navigierte, gab es auch einen Identitätskontext. IdentityServer4 Sie können sich lediglich anmelden. Dies ist ein kostenloses und leistungsstarkes Analogon für ADFS - Active Directory-Verbunddienste.
Die Identitätsanfrage wurde in mehreren Schritten bearbeitet. Erster Schritt - Client bin ins Backend gekommen, der mit diesem Server kommunizierte und das Vorhandensein eines Tokens für den Client überprüfte. Wenn es nicht gefunden wurde, wurde die Anfrage an den Kontext zurückgegeben, aus dem sie kam, jedoch mit einer Umleitung, und mit der Umleitung ging sie an die Identität.
Zweiter Schritt – die Anfrage ist eingegangen zur Autorisierungsseite in IdentityServer, wo sich der Client registrierte und das lang erwartete Token in der IdentityServer-Datenbank erschien.
Dritter Schritt - Der Kunde wurde zurückgeleitet auf den Kontext, aus dem es kam.
IdentityServer4 verfügt über eine Funktion: Es gibt die Antwort auf die Rückgabeanforderung über HTTP zurück. Egal, wie sehr wir uns mit der Einrichtung des Servers abmühten, egal, wie sehr wir uns mit der Dokumentation befassten, jedes Mal, wenn wir eine erste Client-Anfrage mit einer URL erhielten, die über HTTPS kam, gab IdentityServer denselben Kontext zurück, jedoch mit HTTP. Wir waren schockiert! Und das alles haben wir über den Identitätskontext an HAProxy übertragen und in den Headern mussten wir das HTTP-Protokoll auf HTTPS ändern.
Was ist die Verbesserung und wo haben Sie gespart?
Wir haben Geld gespart, indem wir eine kostenlose Lösung zur Autorisierung einer Gruppe von Benutzern und Ressourcen verwendet haben, da wir IdentityServer4 nicht als separaten Knoten in einem separaten Segment platziert haben, sondern ihn zusammen mit dem Backend auf demselben Server verwendet haben, auf dem das Backend der Anwendung ausgeführt wird .
Wie es funktionieren soll
Also, wie versprochen – Magic Box. Wir verstehen bereits, dass wir garantiert auf Linux umsteigen werden. Lassen Sie uns konkrete Aufgaben formulieren, die Lösungen erforderten.
Marionette manifestiert sich. Um die Service- und Anwendungskonfiguration bereitzustellen und zu verwalten, mussten coole Rezepte geschrieben werden. Eine Bleistiftrolle zeigt eindrucksvoll, wie schnell und effizient es ging.
Versandart. Der Standard ist RPM. Jeder versteht, dass man unter Linux nicht darauf verzichten kann, aber das Projekt selbst bestand nach der Assemblierung aus einer Reihe ausführbarer DLL-Dateien. Es waren ungefähr 150 Stück, das Projekt war ziemlich schwierig. Die einzig harmonische Lösung besteht darin, diese Binärdatei in RPM zu packen und die Anwendung daraus bereitzustellen.
Versionierung. Wir mussten sehr oft etwas veröffentlichen und mussten entscheiden, wie wir den Paketnamen bilden sollten. Dies ist eine Frage des Integrationsgrads mit TFS. Wir hatten einen Build-Agenten unter Linux. Wenn TFS eine Aufgabe an einen Handler – Worker – an den Build-Agenten sendet, übergibt es ihm auch eine Reihe von Variablen, die in der Umgebung des Handler-Prozesses landen. Diese Umgebungsvariablen enthalten den Build-Namen, den Versionsnamen und andere Variablen. Lesen Sie mehr dazu im Abschnitt „Erstellen eines RPM-Pakets“.
TFS einrichten Es ging darum, Pipeline einzurichten. Früher haben wir alle Windows-Projekte auf Windows-Agenten gesammelt, aber jetzt erscheint ein Linux-Agent – ein Build-Agent, der in die Build-Gruppe aufgenommen, mit einigen Artefakten angereichert und mitgeteilt werden muss, welche Art von Projekten auf diesem Build-Agenten erstellt werden , und irgendwie die Pipeline ändern.
IdentityServer. ADFS ist nicht unser Weg, wir setzen auf Open Source.
Gehen wir die Komponenten durch.
magic Box
Besteht aus vier Teilen.
Linux Build-Agent. Linux, weil wir dafür bauen – das ist logisch. Dieser Teil wurde in drei Schritten durchgeführt.
- Konfigurieren Sie Arbeiter und nicht allein, da eine verteilte Arbeit am Projekt erwartet wurde.
- Installieren Sie .NET Core 1.x. Warum 1.x, wenn 2.0 bereits im Standard-Repository verfügbar ist? Denn als wir mit der Entwicklung begannen, war die stabile Version 1.09 und es wurde beschlossen, das Projekt darauf basieren zu lassen.
- Git 2.x.
RPM-Repository. RPM-Pakete mussten irgendwo gespeichert werden. Es wurde davon ausgegangen, dass wir dasselbe Unternehmens-RPM-Repository verwenden würden, das allen Linux-Hosts zur Verfügung steht. Das haben sie getan. Der Repository-Server ist konfiguriert Webhook der das erforderliche RPM-Paket vom angegebenen Speicherort heruntergeladen hat. Die Paketversion wurde vom Build-Agent an den Webhook gemeldet.
GitLab. Aufmerksamkeit! GitLab wird hier nicht von Entwicklern, sondern von der Betriebsabteilung verwendet, um Anwendungsversionen und Paketversionen zu steuern, den Status aller Linux-Maschinen zu überwachen und das Rezept zu speichern – alle Puppet-Manifeste.
Marionette – löst alle umstrittenen Probleme und liefert genau die Konfiguration, die wir von Gitlab wünschen.
Wir beginnen zu tauchen. Wie funktioniert die DLL-Lieferung an RPM?
Lieferung DDL an RPM
Nehmen wir an, wir haben einen Rockstar in der .NET-Entwicklung. Es verwendet Visual Studio und erstellt einen Release-Zweig. Danach lädt es es auf Git hoch, und Git ist hier eine TFS-Entität, das heißt, es ist das Anwendungs-Repository, mit dem der Entwickler arbeitet.
Danach erkennt TFS, dass ein neues Commit eingetroffen ist. Welche App? In den TFS-Einstellungen gibt es eine Bezeichnung, die angibt, über welche Ressourcen ein bestimmter Build-Agent verfügt. In diesem Fall sieht er, dass wir ein .NET Core-Projekt erstellen und wählt einen Linux-Build-Agenten aus dem Pool aus.
Der Build-Agent empfängt die Quellen und lädt das Notwendige herunter Abhängigkeiten aus dem .NET-Repository, npm usw. und sendet nach dem Erstellen der Anwendung selbst und dem anschließenden Packen das RPM-Paket an das RPM-Repository.
Andererseits passiert Folgendes. Der Ingenieur der Betriebsabteilung ist direkt am Rollout des Projekts beteiligt: Er ändert die Versionen der Pakete hier im Repository, in dem das Anwendungsrezept gespeichert ist, woraufhin Puppet ausgelöst wird Yum, ruft das neue Paket aus dem Repository ab und die neue Version der Anwendung ist einsatzbereit.
In Worten ist alles einfach, aber was passiert im Build-Agenten selbst?
Verpackungs-DLL-RPM
Projektquellen und Build-Aufgabe von TFS erhalten. Build-Agent beginnt mit dem Aufbau des Projekts selbst aus Quellen. Das zusammengebaute Projekt ist als Set erhältlich DLL-Dateien, die in einem Zip-Archiv verpackt sind, um die Belastung des Dateisystems zu reduzieren.
Das ZIP-Archiv wird weggeworfen in das Build-Verzeichnis des RPM-Pakets. Als nächstes initialisiert das Bash-Skript die Umgebungsvariablen, findet die Build-Version, die Projektversion und den Pfad zum Build-Verzeichnis und führt RPM-build aus. Sobald der Build abgeschlossen ist, wird das Paket veröffentlicht lokales Repository, die sich auf dem Build-Agenten befindet.
Als nächstes vom Build-Agenten zum Server im RPM-Repository JSON-Anfrage wird gesendet Angabe des Namens der Version und des Builds. Webhook, über den ich bereits gesprochen habe, lädt genau dieses Paket aus dem lokalen Repository auf dem Build-Agenten herunter und stellt die neue Assembly zur Installation zur Verfügung.
Warum dieses spezielle Paketzustellungsschema an das RPM-Repository? Warum kann ich das zusammengestellte Paket nicht sofort an das Repository senden? Tatsache ist, dass dies eine Voraussetzung für die Gewährleistung der Sicherheit ist. Dieses Szenario schränkt die Möglichkeit ein, dass Unbefugte RPM-Pakete auf einen Server hochladen, auf den alle Linux-Maschinen zugreifen können.
Datenbankversionierung
Bei einer Rücksprache mit dem Entwicklungsteam stellte sich heraus, dass die Jungs näher an MS SQL dran waren, aber in den meisten Nicht-Windows-Projekten nutzten wir PostgreSQL bereits mit aller Kraft. Da wir uns bereits entschieden hatten, auf alles Bezahlte zu verzichten, haben wir begonnen, auch hier PostgreSQL zu verwenden.
In diesem Teil möchte ich Ihnen erzählen, wie wir die Datenbank versioniert haben und wie wir uns zwischen Flyway und Entity Framework Core entschieden haben. Schauen wir uns ihre Vor- und Nachteile an.
Cons
Flyway geht nur in eine Richtung, wir Wir können nicht zurückdrehen - Das ist ein erheblicher Nachteil. Sie können es auf andere Weise mit Entity Framework Core vergleichen – im Hinblick auf die Benutzerfreundlichkeit für Entwickler. Sie erinnern sich, dass wir dies in den Vordergrund gestellt haben und das Hauptkriterium darin bestand, nichts für die Windows-Entwicklung zu ändern.
Für Flyway uns Es wurde eine Art Verpackung benötigtdamit die Jungs nicht schreiben SQL-Abfragen. Sie kommen dem OOP-Prinzip viel näher. Wir haben Anweisungen zum Arbeiten mit Datenbankobjekten geschrieben, eine SQL-Abfrage generiert und diese ausgeführt. Die neue Version der Datenbank ist fertig, getestet – alles ist in Ordnung, alles funktioniert.
Entity Framework Core hat ein Minus – bei starker Belastung erstellt suboptimale SQL-Abfragen, und die Inanspruchnahme der Datenbank kann erheblich sein. Da wir jedoch keinen Hochlastdienst haben und die Auslastung nicht in Hunderten von RPS berechnen, haben wir diese Risiken in Kauf genommen und das Problem an die Zukunft delegiert.
Pros
Entity Framework-Kern Funktioniert sofort und ist einfach zu entwickeln, und Flyway Einfache Integration in bestehende CI. Aber wir machen es für Entwickler bequem :)
Roll-Up-Verfahren
Puppet erkennt, dass eine Änderung der Paketversion bevorsteht, einschließlich derjenigen, die für die Migration verantwortlich ist. Zunächst wird ein Paket installiert, das Migrationsskripte und datenbankbezogene Funktionen enthält. Danach wird die Anwendung, die mit der Datenbank arbeitet, neu gestartet. Als nächstes folgt die Installation der restlichen Komponenten. Die Reihenfolge, in der Pakete installiert und Anwendungen gestartet werden, wird im Puppet-Manifest beschrieben.
Anwendungen verwenden sensible Daten wie Token und Datenbankkennwörter. All dies wird vom Puppet-Master in die Konfiguration übernommen, wo sie in verschlüsselter Form gespeichert werden.
TFS-Probleme
Nachdem wir uns entschieden und erkannt hatten, dass bei uns wirklich alles funktionierte, beschloss ich, für die Win-Entwicklungsabteilung bei anderen Projekten einen Blick darauf zu werfen, was mit den Baugruppen in TFS als Ganzes vor sich ging – ob wir schnell erstellten/veröffentlichten oder nicht, und entdeckte erhebliche Probleme mit der Geschwindigkeit.
Die Montage eines der Hauptprojekte dauert 12-15 Minuten – das ist eine lange Zeit, so kann man nicht leben. Eine schnelle Analyse ergab einen schrecklichen I/O-Rückgang, und zwar bei Arrays.
Nachdem ich es Komponente für Komponente analysiert hatte, identifizierte ich drei Schwerpunkte. Erste - „Kaspersky Antivirus“, das Quellen auf allen Windows Build-Agents scannt. Zweite - Windows Indexer. Es wurde nicht deaktiviert und alles wurde während des Bereitstellungsprozesses in Echtzeit auf den Build-Agenten indiziert.
Dritte - Npm-Installation. Es stellte sich heraus, dass wir in den meisten Pipelines genau dieses Szenario verwendeten. Warum ist er schlecht? Der Npm-Installationsvorgang wird ausgeführt, wenn der Abhängigkeitsbaum erstellt wird Paket-lock.json, wo die Versionen der Pakete aufgezeichnet werden, die zum Erstellen des Projekts verwendet werden. Der Nachteil besteht darin, dass Npm install jedes Mal die neuesten Versionen von Paketen aus dem Internet abruft, was bei einem großen Projekt viel Zeit in Anspruch nimmt.
Entwickler experimentieren manchmal auf einem lokalen Computer, um zu testen, wie ein bestimmter Teil oder ein ganzes Projekt funktioniert. Manchmal stellte sich heraus, dass vor Ort alles cool war, aber sie haben es zusammengebaut, ausgerollt und nichts hat funktioniert. Wir beginnen herauszufinden, wo das Problem liegt – ja, verschiedene Versionen von Paketen mit Abhängigkeiten.
Lösung
- Quellen in AV-Ausnahmen.
- Indizierung deaktivieren.
- Spinnerei npm ci.
Die Vorteile von npm ci bestehen darin, dass wir Wir sammeln den Abhängigkeitsbaum einmal, und wir bekommen die Möglichkeit, den Entwickler zur Verfügung zu stellen aktuelle Paketliste, mit dem er vor Ort beliebig viel experimentieren kann. Das spart Zeit Entwickler, die Code schreiben.
Konfiguration
Nun ein wenig zur Repository-Konfiguration. Historisch gesehen verwenden wir Nexus zum Verwalten von Repositorys, einschließlich Internes REPO. Dieses interne Repository enthält alle Komponenten, die wir für interne Zwecke verwenden, beispielsweise für selbstgeschriebene Überwachungen.
Wir benützen auch NuGet, da es im Vergleich zu anderen Paketmanagern über ein besseres Caching verfügt.
Erlebe die Kraft effektiver Ergebnisse
Nachdem wir die Build Agents optimiert hatten, konnte die durchschnittliche Buildzeit von 12 Minuten auf 7 Minuten reduziert werden.
Wenn wir alle Maschinen mitzählen, die wir für Windows hätten verwenden können, in diesem Projekt aber auf Linux umgestiegen sind, haben wir etwa 10 US-Dollar gespart. Und das nur bei den Lizenzen, und noch mehr, wenn wir den Inhalt berücksichtigen.
Pläne
Für das nächste Quartal wollten wir an der Optimierung der Codebereitstellung arbeiten.
Wechseln zu einem vorgefertigten Docker-Image. TFS ist eine coole Sache mit vielen Plugins, die eine Integration in Pipeline ermöglichen, einschließlich der triggerbasierten Zusammenstellung beispielsweise eines Docker-Images. Wir wollen diesen Auslöser für denselben machen Paket-lock.json. Wenn sich die Zusammensetzung der zum Erstellen des Projekts verwendeten Komponenten irgendwie ändert, erstellen wir ein neues Docker-Image. Es wird später verwendet, um den Container mit der zusammengestellten Anwendung bereitzustellen. Dies ist derzeit nicht der Fall, aber wir planen die Umstellung auf eine Microservice-Architektur in Kubernetes, die sich in unserem Unternehmen aktiv weiterentwickelt und seit langem Produktionslösungen bedient.
Zusammenfassung
Ich ermutige jeden, Windows wegzuwerfen, aber das liegt nicht daran, dass ich nicht weiß, wie man es kocht. Der Grund dafür ist, dass die meisten OpenSource-Lösungen dies tun Linux-Stack. geht es dir gut? Ressourcen sparen. Meiner Meinung nach gehört die Zukunft Open-Source-Lösungen auf Linux mit einer starken Community.
Sprecherprofil von Alexander Sinchinov .
ist eine Konferenz zur Integration von Entwicklungs-, Test- und Betriebsprozessen für Profis von Profis. Deshalb das Projekt, von dem Alexander gesprochen hat? umgesetzt und funktioniert, und am Tag der Aufführung gab es zwei erfolgreiche Veröffentlichungen. An Am 27. und 28. Mai wird es noch mehr ähnliche Fälle von Praktikern geben. Sie können immer noch in den letzten Wagen springen und oder nehmen Sie sich Zeit Fahrkarte. Treffen Sie uns in Skolkovo!
Source: habr.com