Was bedeutet QA für DevOps?

Was ist Qualitätssicherung?

Nun, in altehrwürdiger Manier zitiere ich direkt aus Wikipedia:

Qualitätssicherung (QA) bezieht sich auf die technischen Tätigkeiten, die in einem Qualitätssystem implementiert werden, damit die Anforderungen an ein Produkt oder eine Dienstleistung erfüllt werden.

Aber was bedeutet das für DevOps? Nun, das Endprodukt ist die Software oder Anwendung, die bereitgestellt wird, daher konzentrieren sich die meisten Menschen auf ihre Anforderungen, wenn sie über QA und DevOps sprechen.

Softwareentwicklung auf Basis von TDD/BDD und strikte Continuous-Integration-Praktiken werden häufig angesprochen.

Sind an diesen Dingen (TDD/BDD) in der Regel sowohl Entwicklungs- als auch Betriebsmitarbeiter beteiligt?

OKAY. Das klingt vernünftig. Es sind sicherlich Dinge, die man in einem IT-Team erwarten würde, das sich dazu bekennt, DevOps zu praktizieren. Sind an diesen Dingen in der Regel sowohl Entwicklungs- als auch Betriebsmitarbeiter beteiligt? Nein, das tun sie nicht. Wurden sie in Entwicklungsteams praktiziert, bevor DevOps zum Mainstream wurde? Ja, das waren sie oft (vielleicht aber nicht oft genug).

Diese Entwicklungspraktiken sind zwar Teil des DevOps-Puzzles, aber wenn Sie sich nur auf sie konzentrieren, wenn es um QA und DevOps geht, ist dies ein massives Versehen. Wie in der obigen Definition erwähnt, geht es bei der Qualitätssicherung darum, sicherzustellen, dass die Anforderungen (funktionale und nicht-funktionale) an Ihr Produkt oder Ihre Dienstleistung erfüllt werden. Im Falle des Testens von Code oder der Endanwendung bezieht es sich auf die Anforderungen des Kunden. Entscheidend, aber nicht die ganze Geschichte.

Worum geht es bei DevOps grundsätzlich?

Die Beziehung zwischen Entwicklungs- und Betriebsmitarbeitern. Betrachten wir vor diesem Hintergrund die Entwicklung für einen Moment als Kunden des Betriebs. Das Produkt, das sie benötigen, ist eine stabile, effiziente Infrastruktur, auf der sie ihre Anwendungen erstellen und hosten können. Die Qualitätssicherung muss in diesem Fall dann sicherstellen, dass die Anforderungen der Entwickler (und ihrer Anwendungen) erfüllt werden.

Es ist wichtig, dies zu verstehen, und die Wertschätzung durch den Betrieb wird einen großen Beitrag zur Lösung der Spannungen zwischen den beiden Teams leisten, für die die DevOps-Bewegung ins Leben gerufen wurde. Sie müssen sich nicht viel mit der Geschichte einer typischen IT-Abteilung befassen, um Beispiele für eine qualitativ hochwertige Infrastruktur (in den Augen des Betriebsteams) zu finden, die nicht den Anforderungen der Entwickler und ihrer Anwendung entspricht. Natürlich gibt es dafür häufig gute Gründe (z.B. Sicherheit), aber unter dem Strich wirkt sich der Grad, in dem die Infrastruktur für die Entwickler und ihre Anwendung fit ist, direkt auf den Grad aus, in dem die Anwendung für den Kunden fit for purpose ist.

... Wir können automatisieren. Das ist aber keine Garantie für Qualität, sondern nur für Konsistenz.

Wie können wir also die Qualität der Infrastruktur und Konfiguration sicherstellen?

Nun, wir können automatisieren. Das ist aber keine Garantie für Qualität, sondern nur für Konsistenz. Im Entwicklungsbereich ist BDD eine so mächtige Sache, weil es auf der Grundlage der Anforderungen des Endbenutzers testet. Zu sagen: "Ich muss meine Infrastruktur oder Konfiguration nicht testen, weil sie automatisiert ist", ist so, als würde ein Entwickler sagen, dass er seinen Code nicht testen muss, weil er das tut, wofür er geschrieben wurde. Der Punkt ist, dass Sie eine externe Bestätigung benötigen.

QA für DevOps ist und wird wahrscheinlich immer ein weit gefasster Begriff sein. Wenn Sie Ihre Infrastruktur und Anwendungskonfiguration jedoch nicht unabhängig und automatisch validieren können, besteht eine große Lücke in Ihrem Ansatz.