Beste DevOps-Praktiken für Entwickler. Anton Boyko (2017)

Der Bericht wird über einige DevOps-Praktiken sprechen, allerdings aus der Sicht eines Entwicklers. Normalerweise verfügen alle Ingenieure, die sich DevOps anschließen, bereits über mehrere Jahre Verwaltungserfahrung. Das heißt aber nicht, dass es hier keinen Platz für den Entwickler gibt. In den meisten Fällen sind Entwickler damit beschäftigt, „den nächsten dringend kritischen Fehler des Tages“ zu beheben, und haben nicht einmal die Zeit, einen kurzen Blick auf den DevOps-Bereich zu werfen. Nach dem Verständnis des Autors ist DevOps zunächst einmal gesunder Menschenverstand. Zweitens ist es eine Chance, effektiver zu sein. Wenn Sie Entwickler sind, über gesunden Menschenverstand verfügen und als Teamplayer effektiver sein möchten, ist dieser Bericht genau das Richtige für Sie.

Darf ich mich vorstellen? Ich gebe voll und ganz zu, dass es Leute im Raum gibt, die mich nicht kennen. Mein Name ist Anton Boyko, ich bin ein Microsoft Azure MVP. Was ist MVP? Dies ist Model-View-Presenter. Model-View-Presenter ist genau ich.

Darüber hinaus bin ich derzeit als Lösungsarchitekt bei Ciklum tätig. Und erst kürzlich habe ich mir eine so schöne Domain gekauft und meine E-Mail-Adresse aktualisiert, die ich normalerweise bei Präsentationen zeige. Sie können mir schreiben unter: me [dog] byokoant.pro. Sie können mir bei Fragen eine E-Mail senden. Normalerweise beantworte ich sie. Das Einzige ist, dass ich keine Fragen per E-Mail erhalten möchte, die sich auf zwei Themen beziehen: Politik und Religion. Alles Weitere können Sie mir per E-Mail mitteilen. Es wird einige Zeit vergehen, ich werde antworten.

Ein paar Worte über dich:

• Ich bin jetzt seit 10 Jahren in diesem Bereich tätig.
• Ich habe bei Microsoft gearbeitet.
• Ich bin der Gründervater der ukrainischen Azure-Community, die wir 2014 irgendwo gegründet haben. Und wir haben es immer noch und entwickeln es weiter.
• Ich bin auch der Vater des Gründers der Azure-Konferenz, die wir in der Ukraine veranstalten.
• Ich helfe auch bei der Organisation des Global Azure Bootcamps in Kiew.
• Wie gesagt, ich bin ein Microsoft Azure MVP.
• Ich spreche ziemlich oft auf Konferenzen. Ich liebe es wirklich, auf Konferenzen zu sprechen. Im vergangenen Jahr konnte ich etwa 40 Mal auftreten. Wenn Sie an der Ukraine, Weißrussland, Polen, Bulgarien, Schweden, Dänemark, den Niederlanden, Spanien oder mehr oder weniger an einem anderen Land in Europa vorbeikommen, ist es durchaus möglich, dass Sie, wenn Sie zu einer Konferenz gehen, deren Stream ein Cloud-Thema enthält, Möglicherweise finden Sie mich auf der Rednerliste.
• Ich bin auch ein Star Trek-Fan.

Lassen Sie uns ein wenig über die Agenda sprechen. Unsere Agenda ist ganz einfach:

• Wir werden darüber sprechen, was DevOps ist. Lassen Sie uns darüber sprechen, warum das wichtig ist. Früher war DevOps ein Stichwort, das Sie in Ihren Lebenslauf schrieben und sofort ein Gehalt von über 500 US-Dollar erhielten. Jetzt müssen Sie beispielsweise Blockchain in Ihren Lebenslauf schreiben, um +500 Dollar zu Ihrem Gehalt zu bekommen.
• Und wenn wir dann ein wenig verstehen, was das ist, werden wir darüber sprechen, was DevOps-Praktiken sind. Aber nicht so sehr im Kontext von DevOps im Allgemeinen, sondern zu den DevOps-Praktiken, die für Entwickler von Interesse sein könnten. Ich erzähle Ihnen, warum sie für Sie von Interesse sein könnten. Ich erzähle Ihnen, warum Sie das überhaupt tun sollten und wie es dazu beitragen kann, dass Sie weniger Schmerzen haben.

Ein traditionelles Bild, das viele Menschen zeigen. Das passiert in vielen Projekten. Dann haben wir Entwicklungs- und Betriebsabteilungen, die unsere Software unterstützen. Und diese Abteilungen kommunizieren nicht miteinander.

Wenn Sie es in den Abteilungen DevOps und Operations nicht so deutlich spüren konnten, können Sie vielleicht eine Analogie zu den Abteilungen Dev und QA ziehen. Es gibt Leute, die Software entwickeln, und es gibt QA-Leute, die aus Entwicklersicht schlecht sind. Zum Beispiel übergebe ich meinen wunderbaren Code in das Repository, und da sitzt ein Schurke, der mir diesen Code zurückgibt und sagt, dass Ihr Code schlecht ist.

Dies alles geschieht, weil die Menschen nicht miteinander kommunizieren. Und sie werfen einander einige Pakete, einige Anwendungen durch irgendeine Mauer des Missverständnisses zu und versuchen, etwas damit anzufangen.

Genau diese Mauer soll die DevOps-Kultur zerstören, d. h. Zwingen Sie die Menschen dazu, miteinander zu kommunizieren und zumindest zu verstehen, was die verschiedenen Personen im Projekt tun und warum ihre Arbeit wichtig ist.

Und wenn wir über DevOps sprechen, wird Ihnen jemand sagen, dass DevOps eine kontinuierliche Integration des Projekts bedeutet; Jemand wird sagen, dass DevOps das ist, wenn das Projekt die „Infrastruktur als Code“-Praxis umsetzt. Jemand wird sagen, dass der erste Schritt zu DevOps Feature Branching und Feature Flags sind.

Im Grunde ist das alles auf seine Art wahr. Aber das sind nur die ultimativen Praktiken, die wir haben. Bevor ich zu diesen Praktiken übergehe, empfehle ich Ihnen, sich diese Folie anzusehen, die die drei Phasen der Implementierung der Dev-Ops-Methodik in Ihrem Projekt und in Ihrem Unternehmen zeigt.

Diese Folie hat auch einen zweiten inoffiziellen Namen. Sie können online suchen, um herauszufinden, was die drei Musketiere von DevOps sind. Es ist möglich, dass Sie diesen Artikel finden. Warum 3 Musketiere? Darunter steht: Menschen, Prozesse und Produkte, also PPP – Porthos, Porthos und Porthos. Hier sind die 3 Musketiere von DevOps. In diesem Artikel wird ausführlicher beschrieben, warum dies wichtig ist und was es beinhaltet.

Wenn Sie mit der Implementierung einer DevOps-Kultur beginnen, ist es sehr wichtig, dass diese in der folgenden Reihenfolge implementiert wird.

Zunächst muss man mit den Leuten reden. Und Sie müssen den Leuten erklären, was es ist und wie sie daraus Nutzen ziehen können.

Unsere Konferenz heißt DotNet Fest. Und wie mir die Organisatoren sagten, haben wir hier hauptsächlich ein Entwicklerpublikum eingeladen, daher hoffe ich, dass die meisten Leute im Saal an der Entwicklung beteiligt sind.

Wir reden über Menschen, wir reden darüber, was Entwickler jeden Tag tun wollen. Was wollen sie am meisten? Sie möchten neuen Code schreiben, neue Frameworks verwenden und neue Funktionen erstellen. Was wollen Entwickler am wenigsten? Beheben Sie alte Fehler. Ich hoffe, Sie stimmen mir zu. Das wollen die Entwickler. Sie wollen neue Funktionen schreiben, sie wollen keine Fehler beheben.

Die Anzahl der Bugs, die ein bestimmter Entwickler produziert, hängt davon ab, wie gerade seine Arme sind und wie weit sie aus seinen Schultern herauswachsen, und nicht aus seinen Gesäßtaschen. Wenn wir jedoch ein großes Projekt haben, kommt es manchmal vor, dass es unmöglich ist, den Überblick über alles zu behalten. Daher wäre es schön, wenn wir einige Ansätze verwenden würden, die uns helfen, stabileren und qualitativ hochwertigeren Code zu schreiben.

Was wünschen sich QAs am meisten? Ich weiß nicht, ob sie in der Halle sind. Es fällt mir schwer zu sagen, dass ich eine Qualitätssicherung möchte, weil ich noch nie eine solche war. Und keine Beleidigung für die Jungs, ich hoffe, dass ich es nie tun werde. Aber nicht aus dem Grund, weil ich ihre Arbeit für bedeutungslos und nutzlos halte, sondern weil ich mich nicht für jemanden halte, der diese Arbeit effizient erledigen könnte, und deshalb werde ich es nicht einmal versuchen. Aber soweit ich weiß, gefällt es der Qualitätssicherung am meisten nicht, morgens zu arbeiten, ständig irgendeine Art von Regressionstests durchzuführen, auf die gleichen Fehler zu stoßen, die sie den Entwicklern vor drei Sprints gemeldet haben, und zu sagen: „Wann wirst du?“ , Monsieur D'Artagnan, beheben Sie diesen Fehler.' Und Monsieur D'Artagnan antwortet ihm: „Ja, ja, ja, ich habe es bereits behoben.“ Und wie es dazu kommt, dass ich einen Fehler behoben und nebenbei fünf gemacht habe.

Die Leute, die diese Lösung in der Produktion unterstützen, möchten, dass diese Lösung fehlerfrei funktioniert, damit sie nicht jeden Freitag, wenn alle normalen Leute in die Bar gehen, den Server neu starten müssen. Die Entwickler haben am Freitag bereitgestellt, die Administratoren sitzen bis Samstag und versuchen, diese Bereitstellung einzurichten und zu reparieren.

Und wenn Sie den Leuten erklären, dass sie darauf abzielen, die gleichen Probleme zu lösen, können Sie mit der Formalisierung der Prozesse fortfahren. Es ist sehr wichtig. Warum? Denn wenn wir „Formalisierung“ sagen, ist es wichtig, dass Sie zumindest irgendwo auf einer Serviette beschreiben, wie Ihre Prozesse ablaufen. Sie müssen verstehen, dass die Bereitstellung beispielsweise in einer QA-Umgebung oder einer Produktionsumgebung immer in dieser Reihenfolge erfolgt. In diesen Phasen führen wir beispielsweise automatische Komponententests und UI-Tests durch. Nach dem Einsatz prüfen wir, ob der Einsatz gut oder schlecht verlaufen ist. Aber Sie haben bereits eine klare Liste von Aktionen, die bei der Bereitstellung in der Produktion immer wieder wiederholt werden müssen.

Und erst wenn Ihre Prozesse formalisiert sind, beginnen Sie mit der Auswahl von Produkten, die Ihnen bei der Automatisierung dieser Prozesse helfen.

Leider erlebe ich sehr oft, dass dies umgekehrt geschieht. Sobald jemand das Wort „DevOps“ hört, schlägt er sofort die Installation von Jenkins vor, weil er glaubt, dass er DevOps haben wird, sobald er Jenkins installiert. Sie installierten Jenkins, lasen die „How to“-Artikel auf der Jenkins-Website, versuchten, Prozesse in diese How to-Artikel zu stopfen, und kamen dann zu den Leuten und beugten sie vor und sagten, dass im Buch steht, dass man es auf diese Weise machen muss. also machen wir es so.

Es ist nicht so, dass Jenkins ein schlechtes Werkzeug ist. Ich möchte das in keiner Weise sagen. Aber das ist nur eines der Produkte. Und welches Produkt Sie verwenden, sollte Ihre letzte und keineswegs Ihre erste Entscheidung sein. Ihr Produkt sollte nicht von der Umsetzung von Kultur und Ansätzen angetrieben werden. Das ist sehr wichtig zu verstehen, deshalb verbringe ich so viel Zeit mit dieser Folie und erkläre das alles so lange.

Lassen Sie uns über DevOps-Praktiken im Allgemeinen sprechen. Was sind Sie? Was ist der Unterschied? Wie probiere ich sie an? Warum sind sie wichtig?

Die erste Praxis, von der Sie vielleicht gehört haben, heißt Continuous Integration. Vielleicht verfügt jemand im Projekt über Continuous Integration (CI).

Das größte Problem besteht darin, dass ich eine Person meistens frage: „Haben Sie CI für das Projekt?“ und er sagt: „Ja“, und als ich dann frage, was er macht, beschreibt er mir absolut den gesamten Automatisierungsprozess. Das ist nicht ganz richtig.

Tatsächlich zielt die CI-Praxis lediglich darauf ab, den Code, den verschiedene Leute schreiben, in eine Art einzige Codebasis zu integrieren. Das ist alles.

Neben CI gibt es in der Regel noch weitere Praktiken – etwa Continuous Deployment, Release Management, aber darüber sprechen wir später.

CI selbst sagt uns, dass verschiedene Leute Code schreiben und dieser Code kontinuierlich in eine einzige Codebasis integriert werden muss.

Was bringt uns das und warum ist es wichtig? Wenn wir DotNet haben, ist das gut, es ist eine kompilierte Sprache, wir können unsere Anwendung kompilieren. Wenn es kompiliert wird, ist das bereits ein gutes Zeichen. Das bedeutet noch nichts, aber es ist das erste gute Zeichen, das wir zumindest kompilieren können.

Dann können wir einige Tests durchführen, was ebenfalls eine separate Praxis ist. Die Tests sind alle grün – das ist das zweite gute Zeichen. Aber auch das hat nichts zu bedeuten.

Aber warum sollten Sie das tun? Alle Praktiken, über die ich heute sprechen werde, haben ungefähr den gleichen Wert, d. h. ungefähr den gleichen Nutzen und werden auch ungefähr auf die gleiche Weise gemessen.

Erstens ermöglicht es Ihnen, die Lieferung zu beschleunigen. Wie können Sie dadurch die Lieferung beschleunigen? Wenn wir neue Änderungen an unserer Codebasis vornehmen, können wir sofort versuchen, etwas mit diesem Code zu tun. Wir warten nicht, bis Donnerstag kommt, denn am Donnerstag geben wir es an die QA-Umgebung weiter, wir machen es genau hier und genau hier.

Ich werde Ihnen eine traurige Geschichte aus meinem Leben erzählen. Es ist lange her, als ich noch jung und gutaussehend war. Jetzt bin ich schon jung, schön und klug und bescheiden. Vor einiger Zeit war ich in einem Projekt. Wir hatten ein großes Team von etwa 30 Entwicklern. Und wir hatten ein großes, großes Unternehmensprojekt, das sich über etwa 10 Jahre entwickelte. Und wir hatten verschiedene Filialen. Im Repository hatten wir einen Zweig, in dem Entwickler gingen. Und es gab einen Zweig, der die Version des Codes anzeigte, die sich in der Produktion befindet.

Der Produktionszweig war drei Monate hinter dem Zweig zurück, der den Entwicklern zur Verfügung stand. Was bedeutet das? Das heißt, sobald ich irgendwo einen Fehler habe, der aufgrund des Verschuldens der Entwickler, weil sie ihn zugelassen haben, und aufgrund des Verschuldens der Qualitätssicherung, weil sie ihn sich angesehen haben, in Produktion geht, dann bedeutet das, dass, wenn ich einen erhalte Aufgabe für Hotfix für die Produktion, dann muss ich meine Codeänderungen vor 3 Monaten rückgängig machen. Ich muss mich daran erinnern, was ich vor drei Monaten hatte, und versuchen, es dort zu reparieren.

Wenn Sie diese Erfahrung noch nicht gemacht haben, können Sie es bei Ihrem Heimprojekt ausprobieren. Die Hauptsache ist, versuchen Sie es nicht mit einem kommerziellen. Schreiben Sie ein paar Codezeilen, vergessen Sie sie sechs Monate lang und kommen Sie dann zurück und versuchen Sie schnell zu erklären, worum es in diesen Codezeilen geht und wie Sie sie reparieren oder optimieren können. Es ist eine sehr, sehr aufregende Erfahrung.

Wenn wir über eine kontinuierliche Integrationspraxis verfügen, können wir diese hier und jetzt, sobald ich meinen Code geschrieben habe, mit einer Reihe automatisierter Tools überprüfen. Dadurch erhalte ich vielleicht nicht das vollständige Bild, aber dennoch werden dadurch zumindest einige der Risiken beseitigt. Und wenn es einen potenziellen Fehler gibt, werde ich sofort, also buchstäblich in ein paar Minuten, davon erfahren. Ich muss nicht drei Monate zurücksetzen. Ich muss nur 3 Minuten zurücksetzen. Eine gute Kaffeemaschine hat nicht einmal Zeit, in 2 Minuten Kaffee zuzubereiten, das ist also ziemlich cool.

Dies hat den Vorteil, dass es bei jedem Projekt immer wieder wiederholt werden kann, d. h. nicht nur der, auf dem Sie es eingerichtet haben. Sie können sowohl die Übung selbst wiederholen als auch CI selbst für jede neue Änderung, die Sie am Projekt vornehmen, wiederholen. Dadurch können Sie Ressourcen optimieren, da Ihr Team effizienter arbeitet. Sie werden nicht mehr in die Situation kommen, dass ein Fehler durch den Code entsteht, mit dem Sie vor drei Monaten gearbeitet haben. Sie müssen nicht mehr den Kontext wechseln, wenn Sie die ersten zwei Stunden damit verbringen, zu verstehen, was dann passiert ist, und sich mit der Essenz des Kontexts vertraut zu machen, bevor Sie anfangen, etwas zu korrigieren.

Wie können wir den Erfolg oder Misserfolg dieser Praxis messen? Wenn man dem großen Chef berichtet, was wir beim CI-Projekt umgesetzt haben, hört er bla bla bla. Wir haben es umgesetzt, ok, aber warum, was hat es uns gebracht, wie messen wir es, wie richtig oder falsch setzen wir es um?

Das erste ist, dass wir dank CI immer häufiger bereitstellen können, und zwar gerade deshalb häufiger, weil unser Code potenziell stabiler ist. Auf die gleiche Weise verkürzt sich unsere Zeit, einen Fehler zu finden, und die Zeit, diesen Fehler zu beheben, verkürzt sich gerade deshalb, weil wir genau hier und jetzt eine Antwort vom System erhalten, was mit unserem Code nicht stimmt.

Eine weitere Praxis, die wir haben, ist die Automatisierungstestpraxis, die am häufigsten mit der CI-Praxis einhergeht. Sie gehen Hand in Hand.

Was ist hier wichtig zu verstehen? Es ist wichtig zu verstehen, dass unsere Tests unterschiedlich sind. Und jeder automatisierte Test zielt darauf ab, seine eigenen Probleme zu lösen. Wir haben zum Beispiel Unit-Tests, die es uns ermöglichen, ein Modul separat zu testen, d. h. Wie funktioniert es im Vakuum? Das ist gut.

Wir führen auch Integrationstests durch, die es uns ermöglichen zu verstehen, wie verschiedene Module miteinander integriert werden. Es ist auch gut.

Möglicherweise führen wir UI-Automatisierungstests durch, mit denen wir überprüfen können, wie gut die Arbeit mit der UI bestimmte vom Kunden usw. gestellte Anforderungen erfüllt.

Die spezifischen Tests, die Sie ausführen, können sich darauf auswirken, wie oft Sie sie ausführen. Unit-Tests werden normalerweise kurz und klein geschrieben. Und sie können regelmäßig gestartet werden.

Wenn wir über UI-Automatisierungstests sprechen, ist es gut, wenn Ihr Projekt klein ist. Ihre UI-Automatisierungstests können einige Zeit in Anspruch nehmen. Aber normalerweise dauert ein UI-Automatisierungstest bei einem großen Projekt mehrere Stunden. Und es ist gut, wenn es ein paar Stunden sind. Das Einzige ist, dass es keinen Sinn macht, sie für jeden Build auszuführen. Es ist sinnvoll, sie nachts laufen zu lassen. Und als alle morgens zur Arbeit kamen: sowohl Tester als auch Entwickler, erhielten sie eine Art Bericht, dass wir den UI-Autotest nachts durchgeführt und diese Ergebnisse erhalten hatten. Und hier ist eine Arbeitsstunde eines Servers, der prüft, ob Ihr Produkt bestimmte Anforderungen erfüllt, viel günstiger als eine Arbeitsstunde desselben QA-Ingenieurs, selbst wenn es sich um einen Junior-QA-Ingenieur handelt, der für Essen und Dank arbeitet. Trotzdem ist eine Stunde Maschinenbetrieb günstiger. Deshalb ist es sinnvoll, darin zu investieren.

Ich habe ein anderes Projekt, an dem ich gearbeitet habe. Wir hatten zweiwöchige Sprints für dieses Projekt. Das Projekt war groß, wichtig für den Finanzsektor und es durfte kein Fehler gemacht werden. Und nach einem zweiwöchigen Sprint folgte auf den Entwicklungszyklus ein Testprozess, der weitere vier Wochen dauerte. Versuchen Sie, sich das Ausmaß der Tragödie vorzustellen. Wir schreiben zwei Wochen lang Code, dann machen wir ihn wie CodeFreeze, packen ihn in eine neue Version der Anwendung und stellen ihn den Testern zur Verfügung. Tester testen es noch weitere 4 Wochen, d.h. Während sie es testen, haben wir Zeit, zwei weitere Versionen für sie vorzubereiten. Das ist ein wirklich trauriger Fall.

Und wir haben ihnen gesagt, dass es für Sie sinnvoll ist, automatisierte Testpraktiken zu implementieren, wenn Sie produktiver sein wollen, denn genau das tut Ihnen hier und jetzt weh.

Üben Sie Continuous Deployment. Großartig, Sie haben den Build abgeschlossen. Das ist schon gut. Ihr Code wurde kompiliert. Jetzt wäre es schön, diesen Build in einer Umgebung bereitzustellen. Sagen wir, in einer Umgebung für Entwickler.

Warum ist es wichtig? Zunächst können Sie prüfen, wie erfolgreich Sie mit dem Bereitstellungsprozess selbst sind. Ich habe Projekte wie dieses kennengelernt. Wenn ich frage: „Wie stellt man eine neue Version der Anwendung bereit?“, antworten mir die Jungs: „Wir stellen sie zusammen und packen sie in ein Zip-Archiv.“ Wir senden es per Mail an den Administrator. Der Administrator lädt dieses Archiv herunter und erweitert es. Und das ganze Büro beginnt zu beten, dass der Server die neue Version übernimmt.“

Beginnen wir mit etwas Einfachem. Sie haben beispielsweise vergessen, CSS im Archiv abzulegen oder den Hashtag im Java-Script-Dateinamen zu ändern. Und wenn wir eine Anfrage an den Server stellen, geht der Browser davon aus, dass er diese Java-Script-Datei bereits hat, und beschließt, sie nicht herunterzuladen. Und es gab eine alte Version, da fehlte etwas. Im Allgemeinen kann es viele Probleme geben. Daher ermöglicht Ihnen die Praxis der kontinuierlichen Bereitstellung zumindest zu testen, was passieren würde, wenn Sie ein sauberes Referenzbild nehmen und es in eine völlig saubere neue Umgebung hochladen würden. Sie können sehen, wohin das führt.

Auch wenn Sie Code untereinander integrieren, d. h. Zwischen dem Befehl können Sie so auch sehen, wie er auf der Benutzeroberfläche aussieht.

Eines der Probleme, die auftreten, wenn viel Vanilla-Java-Script verwendet wird, besteht darin, dass zwei Entwickler vorschnell eine Variable mit demselben Namen im Fensterobjekt deklariert haben. Und dann, abhängig von Ihrem Glück. Wessen Java-Script-Datei als zweites herausgezogen wird, überschreibt die Änderungen der anderen. Es ist auch sehr spannend. Sie kommen ins Spiel: Eine Sache funktioniert für eine Person, eine andere funktioniert für eine andere nicht. Und es ist „wunderbar“, wenn alles in Produktion geht.

Die nächste Praxis, die wir anwenden, ist die Praxis der automatischen Wiederherstellung, nämlich das Zurücksetzen auf die vorherige Version der Anwendung.

Warum ist das für Entwickler wichtig? Es gibt immer noch diejenigen, die sich an die fernen, fernen 90er Jahre erinnern, als Computer groß und Programme klein waren. Und der einzige Weg zur Webentwicklung führte über PHP. Es ist nicht so, dass PHP eine schlechte Sprache ist, obwohl es eine ist.

Aber das Problem war ein anderes. Wie haben wir eine neue Version unserer PHP-Site bereitgestellt, als wir sie bereitgestellt haben? Am häufigsten haben wir Far Manager oder etwas anderes geöffnet. Und diese Dateien auf FTP hochgeladen. Und plötzlich wurde uns klar, dass wir einen kleinen, kleinen Fehler hatten. Wir hatten zum Beispiel vergessen, ein Semikolon einzufügen oder das Passwort für die Datenbank zu ändern, und es gab ein Passwort für die Datenbank, die sich auf dem lokalen Host befand. Und wir beschließen, schnell eine FTP-Verbindung herzustellen und die Dateien direkt dort zu bearbeiten. Das ist einfach Feuer! Das war in den 90ern beliebt.

Aber wenn Sie nicht auf den Kalender geschaut haben: Die 90er Jahre sind fast 30 Jahre her. Jetzt kommt alles etwas anders. Und versuchen Sie sich das Ausmaß der Tragödie vorzustellen, wenn sie Ihnen sagen: „Wir haben die Produktion in Angriff genommen, aber dort ist etwas schief gelaufen.“ Hier ist Ihr FTP-Login und Ihr Passwort. Stellen Sie eine Verbindung zur Produktion her und beheben Sie das Problem dort schnell.“ Wenn Sie Chuck Norris sind, wird das funktionieren. Wenn nicht, riskieren Sie, dass Sie durch die Behebung eines Fehlers zehn weitere machen. Genau aus diesem Grund können Sie mit dieser Vorgehensweise, auf die vorherige Version zurückzusetzen, viel erreichen.

Selbst wenn irgendwo etwas Schlimmes in die Produktion gelangt ist, dann ist es zwar schlimm, aber nicht tödlich. Sie können zur vorherigen Version zurückkehren. Nennen Sie es ein Backup, wenn es in dieser Terminologie einfacher zu verstehen ist. Sie können auf diese vorherige Version zurücksetzen, und Benutzer können weiterhin mit Ihrem Produkt arbeiten und Sie haben ausreichend Pufferzeit. Sie können das alles in aller Ruhe und ohne Eile lokal testen, reparieren und dann eine neue Version hochladen. Es macht wirklich Sinn, dies zu tun.

Versuchen wir nun, die beiden vorherigen Praktiken irgendwie miteinander zu kombinieren. Wir werden ein drittes bekommen, das Release Management heißt.

Wenn wir über Continuous Deployment in seiner klassischen Form sprechen, sagen wir, dass wir Code aus einem Zweig des Repositorys ziehen, ihn kompilieren und bereitstellen müssen. Es ist gut, wenn wir das gleiche Umfeld haben. Wenn wir mehrere Umgebungen haben, bedeutet das, dass wir den Code jedes Mal abrufen müssen, sogar aus demselben Commit. Wir werden es jedes Mal herausnehmen, wir werden es jedes Mal erstellen und wir werden es in einer neuen Umgebung bereitstellen. Erstens ist dies Zeit, denn die Erstellung eines Projekts kann mehrere Stunden dauern, wenn Sie ein großes Projekt haben und aus den 90er Jahren stammen.

Außerdem gibt es noch eine weitere Traurigkeit. Wenn Sie erstellen, erstellen Sie auch auf derselben Maschine dieselben Quellen. Sie haben jedoch keine Garantie dafür, dass sich diese Maschine in demselben Zustand befindet wie beim letzten Build.

Nehmen wir an, jemand ist vorbeigekommen und hat DotNet für Sie aktualisiert, oder umgekehrt hat jemand beschlossen, etwas zu löschen. Und dann haben Sie die kognitive Dissonanz, dass wir seit diesem Commit vor zwei Wochen einen Build erstellt haben und alles in Ordnung war, aber jetzt scheint es, als ob dieselbe Maschine, dasselbe Commit, derselbe Code zu erstellen wäre, aber es funktioniert nicht . Sie werden sich noch lange damit beschäftigen und es ist keine Tatsache, dass Sie es herausfinden werden. Zumindest werden Sie Ihre Nerven sehr verwöhnen.

Daher schlägt die Release-Management-Praxis die Einführung einer zusätzlichen Abstraktion vor, die als Artefakt-Repository, Galerie oder Bibliothek bezeichnet wird. Sie können es nennen, wie Sie wollen.

Die Hauptidee besteht darin, dass wir, sobald wir dort eine Art Commit haben, beispielsweise in einem Zweig, den wir in unseren verschiedenen Umgebungen bereitstellen möchten, Anwendungen aus diesem Commit sammeln und alles, was wir für diese Anwendung benötigen, packen in ein Zip-Archiv und speichern Sie es an einem zuverlässigen Speicherort. Und aus diesem Speicher können wir dieses Zip-Archiv jederzeit abrufen.

Dann nehmen wir es und stellen es automatisch in der Entwicklungsumgebung bereit. Wir fahren dort Rennen, und wenn alles gut ist, dann marschieren wir auf die Bühne. Wenn alles in Ordnung ist, stellen wir dasselbe Archiv in der Produktion bereit, dieselben Binärdateien, genau einmal kompiliert.

Darüber hinaus hilft uns eine solche Galerie auch, die Risiken zu bewältigen, die wir auf der letzten Folie angesprochen haben, als wir über das Zurücksetzen auf die vorherige Version gesprochen haben. Wenn Sie versehentlich etwas falsch bereitgestellt haben, können Sie jederzeit eine andere frühere Version aus dieser Galerie übernehmen und die Bereitstellung auf die gleiche Weise in diesen Umgebungen aufheben. Auf diese Weise können Sie problemlos zur vorherigen Version zurückkehren, wenn etwas schief geht.

Es gibt noch eine weitere tolle Praxis. Ihnen und mir ist allen klar, dass ein Rollback unserer Anwendungen auf eine frühere Version möglicherweise bedeutet, dass wir auch die Infrastruktur der vorherigen Version benötigen.

Wenn wir über virtuelle Infrastruktur sprechen, denken viele Leute, dass dies etwas ist, was Administratoren einrichten. Und wenn Sie beispielsweise einen neuen Server benötigen, auf dem Sie eine neue Version Ihrer Anwendung testen möchten, müssen Sie ein Ticket an die Administratoren oder Entwickler schreiben. Devops werden dafür 3 Wochen brauchen. Und nach 3 Wochen wird Ihnen mitgeteilt, dass wir eine virtuelle Maschine für Sie installiert haben, mit einem Kern, zwei Gigabyte RAM und einem Windows-Server ohne DotNet. Sie sagen: „Aber ich wollte DotNet.“ Sie: „Okay, komm in 3 Wochen wieder.“

Die Idee dahinter ist, dass Sie durch den Einsatz von Infrastructure as Code-Praktiken Ihre virtuelle Infrastruktur wie eine weitere Ressource behandeln können.

Wenn einer von Ihnen Anwendungen auf DotNet entwickelt, haben Sie vielleicht schon von einer Bibliothek namens Entity Framework gehört. Und Sie haben vielleicht sogar gehört, dass Entity Framework einer der Ansätze ist, die Microsoft aktiv vorantreibt. Für die Arbeit mit einer Datenbank ist dies ein Ansatz namens Code First. Dabei beschreiben Sie im Code, wie Ihre Datenbank aussehen soll. Und dann stellen Sie die Anwendung bereit. Es stellt eine Verbindung zur Datenbank her, ermittelt selbst, welche Tabellen vorhanden sind und welche nicht, und erstellt alles, was Sie benötigen.

Das Gleiche können Sie auch mit Ihrer Infrastruktur tun. Es gibt keinen Unterschied, ob Sie für ein Projekt eine Datenbank benötigen oder ob Sie für ein Projekt einen Windows-Server benötigen. Es ist nur eine Ressource. Und Sie können die Erstellung dieser Ressource automatisieren, Sie können die Konfiguration dieser Ressource automatisieren. Dementsprechend müssen Sie jedes Mal, wenn Sie ein neues Konzept oder einen neuen Ansatz testen möchten, kein Ticket an Entwickler schreiben. Sie können einfach eine isolierte Infrastruktur aus vorgefertigten Vorlagen und vorgefertigten Skripten für sich bereitstellen und diese implementieren Da sind alle deine Experimente. Sie können dies löschen, einige Ergebnisse erhalten und weiter darüber berichten.

Die nächste Praxis, die ebenfalls existiert und ebenfalls wichtig ist, die aber nur wenige nutzen, ist die Überwachung der Anwendungsleistung.

Zum Application Performance Monitoring möchte ich nur eines sagen. Was ist das Wichtigste an dieser Praxis? Dabei handelt es sich beim Application Performance Monitoring in etwa um dasselbe wie bei der Reparatur einer Wohnung. Dies ist kein Endzustand, es ist ein Prozess. Sie müssen es regelmäßig tun.

Im positiven Sinne wäre es gut, bei fast jedem Build eine Anwendungsleistungsüberwachung durchzuführen, obwohl dies, wie Sie wissen, nicht immer möglich ist. Es muss jedoch mindestens für jede Veröffentlichung durchgeführt werden.

Warum ist es wichtig? Denn wenn Sie plötzlich einen Leistungsabfall bemerken, müssen Sie den Grund dafür genau verstehen. Wenn Ihr Team beispielsweise zweiwöchige Sprints durchführt, sollten Sie Ihre Anwendung mindestens alle zwei Wochen auf einem separaten Server bereitstellen, auf dem Sie über einen eindeutig festgelegten Prozessor, RAM, Festplatten usw. verfügen. Und führen Sie dieselben Leistungstests durch . Sie erhalten das Ergebnis. Sehen Sie, wie es sich gegenüber dem vorherigen Sprint verändert hat.

Und wenn Sie herausfinden, dass der Rückgang irgendwo stark zurückgegangen ist, bedeutet das, dass dies nur auf die Veränderungen zurückzuführen ist, die in den letzten zwei Wochen stattgefunden haben. Dadurch können Sie das Problem viel schneller erkennen und beheben. Und auch das sind ungefähr die gleichen Kennzahlen, anhand derer Sie messen können, wie erfolgreich Sie es gemacht haben.

Die nächste Praxis, die wir haben, ist die Konfigurationsmanagement-Praxis. Es gibt nur sehr wenige, die das ernst nehmen. Aber glauben Sie mir, das ist tatsächlich eine sehr ernste Sache.

Kürzlich gab es eine lustige Geschichte. Die Jungs kamen zu mir und sagten: „Helfen Sie uns, eine Sicherheitsüberprüfung unserer Anwendung durchzuführen.“ Wir haben uns lange gemeinsam den Code angeschaut, sie haben mir von der Anwendung erzählt, Diagramme gezeichnet. Und im Plus oder Minus war alles logisch, verständlich, sicher, aber es gab ein ABER! Sie hatten Konfigurationsdateien in ihrer Quellcodeverwaltung, einschließlich derjenigen aus der Produktion mit der IP-Datenbank, mit Logins und Passwörtern für die Verbindung zu diesen Datenbanken usw.

Und ich sage: „Leute, okay, Sie haben Ihre Produktionsumgebung mit einer Firewall geschlossen, aber die Tatsache, dass Sie den Benutzernamen und das Kennwort für die Produktionsdatenbank direkt in der Quellcodeverwaltung haben und jeder Entwickler sie lesen kann, ist bereits ein großes Sicherheitsrisiko.“ . Und egal wie supersicher Ihre Anwendung aus Code-Sicht ist: Wenn Sie sie in der Quellcodeverwaltung belassen, werden Sie nirgendwo eine Prüfung bestehen.“ Das ist es, worüber ich rede.

Konfigurationsmanagement. Wir können in verschiedenen Umgebungen unterschiedliche Konfigurationen haben. Beispielsweise können wir unterschiedliche Logins und Passwörter für Datenbanken für Qualitätssicherung, Demo, Produktionsumgebung usw. haben.

Diese Konfiguration kann auch automatisiert werden. Es sollte immer von der Anwendung selbst getrennt sein. Warum? Da Sie die Anwendung einmal erstellt haben und es der Anwendung dann egal ist, ob Sie über diese oder jene IP oder diese und jene IP eine Verbindung zum SQL-Server herstellen, sollte es genauso funktionieren. Wenn also plötzlich einer von Ihnen immer noch die Verbindungszeichenfolge im Code fest codiert, denken Sie daran, dass ich Sie finden und bestrafen werde, wenn Sie mit mir am selben Projekt arbeiten. Dies wird immer in einer separaten Konfiguration abgelegt, beispielsweise in web.config.

Und diese Konfiguration wird bereits separat verwaltet, d. h. genau in diesem Moment können ein Entwickler und ein Administrator im selben Raum sitzen. Und der Entwickler kann sagen: „Sehen Sie, hier sind die Binärdateien meiner Anwendung. Sie arbeiten. Die Anwendung benötigt eine Datenbank, um zu funktionieren. Hier neben den Binärdateien befindet sich eine Datei. In dieser Datei ist dieses Feld für den Login zuständig, dieses für das Passwort, dieses für die IP. Stellen Sie es überall bereit.“ Und es ist für den Administrator einfach und klar. Durch die Verwaltung dieser Konfiguration kann er es wirklich überall einsetzen.

Und die letzte Praxis, über die ich sprechen möchte, ist eine Praxis, die sehr, sehr mit Wolken zu tun hat. Und die maximale Wirkung bringt es, wenn Sie in der Cloud arbeiten. Dies ist die automatische Entfernung Ihrer Umgebung.

Ich weiß, dass an dieser Konferenz mehrere Leute aus den Teams teilnehmen, mit denen ich zusammenarbeite. Und bei allen Teams, mit denen ich zusammenarbeite, wenden wir diese Praxis an.

Warum? Natürlich wäre es großartig, wenn jeder Entwickler eine virtuelle Maschine hätte, die rund um die Uhr funktioniert. Aber vielleicht ist das eine Neuigkeit für Sie, vielleicht haben Sie nicht aufgepasst, aber der Entwickler selbst arbeitet nicht rund um die Uhr. Ein Entwickler arbeitet normalerweise 24 Stunden am Tag. Auch wenn er früh zur Arbeit kommt, nimmt er ein großes Mittagessen zu sich und geht dabei ins Fitnessstudio. Lassen Sie es 7 Stunden am Tag sein, in denen der Entwickler diese Ressourcen tatsächlich nutzt. Gemäß unserer Gesetzgebung gelten bei uns 24 von 7 Tagen in der Woche als Arbeitstage.

Dementsprechend sollte diese Maschine an Wochentagen nicht 24 Stunden, sondern nur 12 Stunden arbeiten, und am Wochenende sollte diese Maschine überhaupt nicht funktionieren. Es scheint, dass alles sehr einfach ist, aber was ist hier wichtig zu sagen? Durch die Implementierung dieser einfachen Vorgehensweise nach diesem grundlegenden Zeitplan können Sie die Kosten für die Wartung dieser Umgebungen um 70 % senken, d. h. Sie haben den Preis für Entwicklung, Qualitätssicherung, Demo und Umgebung durch 3 geteilt.

Die Frage ist, was tun mit dem Rest des Geldes? Beispielsweise sollten die Entwickler ReSharper kaufen, falls sie dies noch nicht getan haben. Oder veranstalten Sie eine Cocktailparty. Wenn Sie zuvor eine Umgebung hatten, in der sowohl Entwickler als auch Qualitätssicherung tätig waren, und das war's, können Sie jetzt drei verschiedene Umgebungen erstellen, die isoliert sind und in denen sich die Leute nicht gegenseitig stören.

Was die Folie mit kontinuierlicher Leistungsmessung betrifft: Wie können wir die Leistung vergleichen, wenn wir im Projekt 1 Datensätze in der Datenbank hätten, zwei Monate später sind es eine Million? Wie kann man verstehen, warum und welchen Sinn die Leistungsmessung hat?

Das ist eine gute Frage, denn Sie sollten die Leistung immer auf denselben Ressourcen messen. Das heißt, Sie führen neuen Code ein und messen die Leistung des neuen Codes. Sie müssen beispielsweise verschiedene Leistungsszenarien testen. Nehmen wir an, Sie möchten testen, wie die Anwendung bei geringer Last funktioniert, wenn 1 Benutzer vorhanden sind und die Datenbankgröße 000 Gigabyte beträgt. Sie haben es gemessen und die Zahlen erhalten. Als nächstes nehmen wir ein anderes Szenario. Beispiel: 5 Benutzer, Datenbankgröße 5 Terabyte. Wir erhielten die Ergebnisse und erinnerten uns daran.

Was ist hier wichtig? Wichtig hierbei ist, dass man je nach Szenario, Datenvolumen, Anzahl der gleichzeitigen Nutzer etc. an gewisse Grenzen stoßen kann. Zum Beispiel bis zur Grenze einer Netzwerkkarte, oder bis zur Grenze einer Festplatte oder bis zur Grenze der Prozessorleistung. Das ist es, was Sie verstehen müssen. In verschiedenen Szenarien stößt man an bestimmte Grenzen. Und Sie müssen die Zahlen verstehen, wenn Sie sie treffen.

Sprechen wir über die Leistungsmessung in einer speziellen Testumgebung? Das heißt, das ist keine Produktion?

Ja, das ist keine Produktion, das ist eine Testumgebung, die immer gleich ist, sodass man sie mit früheren Messungen vergleichen kann.

Verstanden, danke!

Wenn es keine Fragen gibt, denke ich, dass wir fertig werden können. Danke!

Source: habr.com