Testen und Freigeben sind Prozesse, die oft früh in einem Projekt eingerichtet und dann vergessen werden. Bei Projekten, die lange dauern (z.B. Jahre), wird die Verbesserung des Freigabe- und Testprozesses oft ignoriert, bis eine Organisation viel größer ist und die Skalierung zu Problemen mit den bestehenden Prozessen führt. Die Verbesserung der Entwicklerwerkzeuge eines Teams kann die Produktivität und die Zufriedenheit der Entwickler steigern und die Veröffentlichung von Korrekturen für Probleme, die bei Zwischenfällen gefunden wurden, erleichtern.
Abgesehen davon sind sowohl das Testen als auch das Freigeben ein sehr umfangreiches Thema. Wir werden uns ihnen hauptsächlich unter dem Aspekt der Zuverlässigkeit nähern. Sie werden lernen, wie Sie in sie investieren können und wie Sie mit Ihren Teamkollegen zusammenarbeiten können, um sie zu wertvollen Werkzeugen zu machen.
Prüfung
Etwas zu testen bedeutet, zu überprüfen, ob es wie erwartet funktioniert. Man kann so gut wie alles testen, und in gewisser Weise ähnelt das Testen der in den Postmortems, erwähnten Analyse.Anstatt jedoch eine Hypothese aufzustellen, nehmen Sie etwas , von dem sie wollen, dass es existiert , schaffen es und überprüfen dann, ob das von Ihnen geschaffene Ding das tut, was Sie wollen.
Beachten Sie das berühmte Dijstra-Zitat: „Testen zeigt das Vorhandensein, nicht das Fehlen von Fehlern.“ Dies ist eine andere Art zu sagen, dass Sie , egal welche Hypothese Sie testen, nicht unbedingt andere Hypothesen entkräften.
Zu der fast garantierten Notwendigkeit, Software zu ändern, wenn sich ihre Definition und Anforderungen ändern, kommt die Tatsache hinzu, dass Softwaretests anfälliger sein können als die Software selbst. Eines der bekanntesten Probleme in der Informatik ist das „Halteproblem“. Es besagt, dass wir nicht wissen können, ob ein Programm bei einem zufälligen Programm und zufälligen Eingaben beendet wird oder für immer läuft. Es handelt sich dabei um ein halbwegs kompliziertes Stück mathematischer Theorie , aber im Grunde genommen gibt es keinen einzigen Test oder eine Funktion, mit der man beweisen kann, ob ein Programm beendet werden kann. Man kann einen Test für ein einzelnes Programm schreiben, aber man kann nicht einen Test für jedes Programm schreiben. Alan Turing bewies dies 1936 in seiner Arbeit On Computable Numbers
Als einzelner Entwickler hat man häufig das Gefühl , dass man niemanden braucht, der seinen Code versteht. Sie können den gesamten Code, den Sie geschrieben haben, in Ihrem Kopf behalten. Sie haben den Großteil des Codes geschrieben, mit dem Sie eine Schnittstelle bilden, und Sie wissen, wie der Code verwendet wird, so dass der wahrscheinlich nicht kaputtgehen wird. Diese Annahme ist nicht falsch. Kleinere Projekte oder Funktionen werden oft von Einzelpersonen bearbeitet, aber dieser Glaube setzt zwei Dinge versus - dass Sie der Einzige sind , der an diesem Stück Code arbeitet, und dass Sie im Laufe der Zeit nicht vergessen werden, was Sie getan haben.
Software wird zu 20% erstellt und zu 80% gewartet wird. Wahrscheinlicher ist, dass sie von der Idee des Pareto-Prinzips herrührt, das besagt, dass 20% der Ursachen 80% der Wirkungen hervorrufen.
Freigabe von
Die Freigabe ode Bereitstellung ist der Vorgang, bei dem ein Haufen Code genommen, gebündelt und an die Benutzer verteilt wird. Es kann viele Formen annehmen, vom Kopieren vieler einzelner Dateien auf einen laufenden Server über die Erstellung eines Pakets und dessen Veröffentlichung in einem Repository, das die Benutzer herunterladen können, bis hin zur Erstellung eines physischen Mediums, das per Post verschickt wird. Die Art und Weise , wie Software in diesen Zustand gebracht wird, hat sich im Laufe der Jahre dramatisch verändert. Als Software noch auf physischen Datenträgern ausgeliefert wurde, bezeichnete man die Software als „Gold“, und das war die Version die an den Kunden verschickt wurde. Heutzutage ist es üblich, Software auf einem Server freizugeben oder verschiedene Möglichkeiten zu nutzen, um Iterationen des Codes aus der Ferne an die Benutzer zu übermitteln. Dadurch wird die Häufigkeit der Freigabe erhöht und die Zeit, die wir für jede einzelne Version aufwenden, verringert. Das Zeil ist nicht mehr die perfekte Version , sondern eine gute Version, damit wir weiter iterieren und das Produkt weiterentwickeln können.
Rollbacks
Ich habe Rollbacks bisher ein paar Mal erwähnt, ohne sie wirklich zu beschreiben. Ein Rollback ist die Rückgängigmachung einer Version. Je schneller und einfacher ein Rollback ist , desto mehr Risiko können Sie mit Ihren Veröffentlichungen eingehen. Denn wenn es einen einzigen Kopf gibt, den jemand drücken kann, um zu einer bekannten, funktionierenden Version zurückzukehren, kann jemand, der in Bereitschaft ist, einfach diesen Knopf drücken , wenn er etwas Schlechtes sieht und später Fragen stellen. Dies ist nicht immer möglich. Wenn Ihr Bereitstellungsprozess nur darin besteht, einige Dateien per sync auf einen Server zu übertragen, ist es oft schwieriger, diese Dateien auf eine korrekte Version zurücksetzen. Wenn Sie sich mit dem Hochladen von Dateien begnügen müssen, empfehle ich Ihnen , Ihre Versionskontrollsoftware auf dem Server zu installieren und bei der Freigabe einen Tag auszuhecken. Auf diese Weise werden alle Dateien auf die korrekte Version geändert.
Achten Sie nicht nur darauf , dass Ihre Rollbacks schnell sind, sondern auch darauf , dass Sie Ihre Rollbacks testen. Dies ist dem Testen von Datenbanksicherungen sehr ähnlich, wenn Sie ihren Prozess nicht testen, ist es gut möglich , dass er genau dann abbricht , wenn Sie ihn am meisten brauchen. Sie brauchen jedoch nicht nur zu testen, um sicherzustellen, dass Ihre Rollbacks funktionieren. Wenn Sie ein Rollback durchführen, müssen Sie eine Validierung durchführen, als ob Sie gerade freigegeben hätten, denn das haben Sie im Grunde getan.
Welche Fragen müssen wir uns stellen?
Was macht eine gute Version aus?
Wie können wir uns auf das verlassen, was wir liefern?
Wie können wir sicherstellen, dass wir bei der Bereitstellung nichts kaputt machen?
Woher wissen wir , ob die Version funktioniert hat?
Um sicherzustellen, dass der Build und die Verteilung konsistent und stabil sind, muss die Veröffentlichung in der Regel drei Eigenschaften aufweisen:
=> Wiederholbar
Wiederholbar ist eigentlich die umstrittenste dieser drei Möglichkeiten. Wiederholbare Builds bedeuten, dass derselbe Code, wenn er zweimal erstellt wird, genau die gleiche Ausgabe liefert. Traditionell waren nur sehr wenige Builds auf diese Weise, was bedeutete , dass zwei Personen, die den gleichen Code erstellten, nicht beide den den Hash der Ausgabe nehmen und vergleichen konnten. Dies war vor allem aus Sicherheitsgründen problematisch. Man kann nicht garantieren, dass man die richtige Binärdatei hat und dass sie nicht manipuliert wurde, wenn man nicht sagen kann, dass sie den richtigen Hash hat. Dies ist einfacher , wenn man nur Code kompiliert , da die meisten Compiler durchgängig die gleiche Binärdatei ausgeben. Es ist viel schwieriger, wenn Sie etwas wie ein Debian-Paket, ein Docker-Image oder ein Amazon Machine Image erstellen. Das liegt daran, dass oft Schritte erforderlich sind, um aktuelle Abhängigkeiten zu erhalten oder Dateien zu schreiben, die sich mit der Zeit ändern. Es ist nicht unmöglich und das Debian-Team hat große Anstrengungen unternommen, um jeden Debian-Build deterministisch und reproduzierbar zu machen. Sie können überprüfen, ob ihr Build reproduzierbar ist, indem Sie ihn auf zwei verschiedenen Systemen erstellen und eine Prüfsumme (z.B. SHA256) der Ausgabe vergleichen. Sie sollten gleichwertig sein, wenn sie auf ähnliche Weise erstellt wurden (zum Beispiel auf zwei verschiedenen Linux-Maschinen).
=> Getestet
Getestet ist ziemlich einfach. Sie wollen sicherstellen, dass Ihre Tests erfolgreich sind und dass sie tatsächlich etwas testen. Eine der Gefahren dabei ist die Ehrfurcht vor „grün“. Grün bedeutet, dass Ihre Tests alle bestanden haben. Wenn Ihre Tests nicht viel testen, dann bedeutet ein grüner Build gar nichts. Das ist ein guter Ausgangspunkt, aber es bedeutet auch, dass Sie wahrscheinlich nicht deployed sollten, wenn Ihr Build grün ist, wenn grün keine große Bedeutung hat. Wir werden bald über die Verifizierung einer Veröffentlichung sprechen, aber weniger Tests im Vorfeld bedeuten in der Regel mehr Validierung nach der Veröffentluchung.
=> Idempotisch
Idempotent ist dem Wiederholbar sehr ähnlich, konzentriert sich aber mehr auf die Bereitstellungs- und Verteilungsphase einer Version und weniger auf den Build-Aspekt. Idempotent ist ein Begriff aus der Mathematik, der besagt, dass die Operation bei mehrfacher Ausführung dasselbe Ergebnis liefert. Dies ist Wege der Skalierung wichtig. Sie benötigen ein Einsatzsystem, das unabhängig vom Zustand des eingegebenen Systems immer dasselbe System ergibt. Wenn Sie beispielsweise mit drei Servern beginnen, auf denen die Version 1.0.0 Ihres Codes läuft, und Sie 1.1.0 bereitstellen, erwarten Sie, dass sie alle 1.1.0 erhalten. Wenn Sie dann das System erweitern müssen, sollte derselbe Prozess in der Lage sein, einen leeren Server in den Zustand von 1.1.0 zu versetzen.
Der Sinn von idempotent ist jedoch, dass Sie , wenn Sie das Deployment-Skript jede Stunde über einen Server laufen lassen, den Server immer in denselben Zustand versetzen würden, egal was passiert. Idempotenz ist die Grundlage für die meisten Konfigurationsmanagement-Tools wie Chef und Ansible, da ihr Ziel darin besteht, ein System in einem beliebigen Zustand in einen identischen Endzustand zu versetzen.
Wann soll freigegeben werden?
Wir haben bereits früher die Idee eines SLO erwähnt - wir müssen nicht einmal einen Dienst haben, der immer in Ordnung ist.
Freigabe für die Produktion
Der nächste und letzte Schritt ist die Produktionsumgebung. Die Produiktionsumgebung ist die Umgebung, in der die Dienste laufen, mit denen die Benutzer tatsächlich kommunizieren. Während jede andere Umgebung jederzeit freigegeben werden kann, müssen Sie bei der Produktionsumgebung die Risiken berücksichtigen.
Automatisierung
Die Automatisierung von Freigaben und Tests ist eine häufige Aufgabe. Beide umfassen in der Regel viele Schritte, so dass die Schaffung eines konsistenten Ortes und einer konsistenten Methode für die Durchführung von von Tests und Freigaben die allgemeine Zuverlässigkeit verbessern kann. Andernfalls könnte ein Build oder Test jedes Mal auf einem anders konfigurierten Rechner stattfinden und unbekannte Variable einbringen. Eine unvollständige Konfiguration , nicht in der richtigen Reihenfolge ausgeführte Schritte oder falsch eingegebene Befehle haben schon so manchen Ausfall verursacht, so dass die Automatisierung dieses Prozesses von großem Wert ist.
Die Automatisierung von Tests und Freigaben erfordert in der Regel die Automatisierung von drei Dingen:
=> Bauen: Die eigentliche Erstellung eines Artefakts aus dem Quellcode
=> Testen: Validierung des erstellten Artefakts
=> Verteilen: Versenden des Artefakts an den Benutzer
Automatisierung gibt es, weil die Menschen vergesslich sind. Alle drei Dinge können mit ähnlichen Tools automatisiert werden. Fast alle diese Tools sind im Wesentlichen Job-Runner, die auf einer Ereigniswarteschlange laufen. Diese Warteschlange kann durch Aktionen gefüllt werden, z.B. durch Code , der in ein Versionskontroll-Repository übertragen wird, oder durch das Klicken auf eine Schaltflächen. Die Warteschlange kann auch mit zeitabhängige Ereignissen gefüllt werden, z.B. mit einem stündlichen Ereignis zur Ausführung von Integrationstests.
Das Wichtigste ist, dass sie ihre Tests und Veröffentlichungen automatisieren. Es wird ein Notfall eintreten, und Sie müssen eine schnelle Korrektur durchführen, oder jemand Neues muss eine Bereitstellung durchführen und weiß nicht, was er tun soll.
Durch die Automatisierung dieser Schritte können Sie dafür sorgen, dass die betreffende Person lediglich ein Ereignis auslösen muss sich dann zurücklehnen kann, um zu sehen, was passiert.
Kontinuierlich
Es gibt viele Wörter , die man gerne hinter „kontinuierlich“ setzt, und oft führen sie zu Diskussionen. In der Regel sind damit nur die drei Schritte gemeint , die oben im Abschnitt Automatisierung beschreiben wurden. Manche nennen das Ganze Continuous Integration, so nennen sich die meisten dieser Job-Runner-Dienstleister. Begriffe, die alle sehr ähnlich zu sein scheinen sind:
=> Kontinuierliche Integration
=> Kontinuierliche Freigabe
=> Koninuierliche Bereitstellung
=> Einsatz bei Grün
Der übergreifende Punkt ist, das die Dinge getestet, erstellt und geliefert werden, und das alles mit Automatisierung. Einige Systeme fügen menschliche Kontrollen in die Pipelines ein. Einige ermöglichen automatische Rollbacks, wenn Probleme auftreten. Bei einigen müssen Schaltflächen angeklickt oder Testbedingungen erfüllt werden. Es ist wichtig sich nicht in Diskussionen verstricken zu lassen sondern sich darauf zu konzentrieren , den Arbeitsablauf zu finden, der für Ihr Unternehmen am besten geeignet ist, und das Risiko zu minimieren, mit dem Ihre Mitarbeiter einverstanden sind.
Nichtsdestotrotz kann jede dieser Ideen und ihre feinen Unterschiede nützlich sein.
Kontinuierliche Integration bedeutet, dass bei jedem Commit eine Reihe von Tests durchgeführt werden sollte, um festzustellen, ob der Code Fehler enthält oder nicht.
Continuous Deployment ist die Idee , dass jeder Commit automatisch in die Produktion überführt wird.
Die kontinuierliche Bereitstellung ist ähnlich, konzentriert sich aber auf die Idee , dass die gesamte Bereitstsellung automatisch erfolgt, sobald Sie sich für die Bereitstellung von Code entscheiden.
Deploy on green ist die Idee , dass die kontinuierliche Bereitstellung immer dann erfolgen sollte , wenn die Tests erfolgreich sind.
Keine Kommentare:
Kommentar veröffentlichen