GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Der Software-Release-Lebenszyklus in DevOps:Warum das Modell neu erfinden?

In meinem vorherigen und ersten Artikel dieser Reihe habe ich eine neue Form und ein neues Modell von DevOps vorgestellt und seine wesentlichen Komponenten und Arbeitsabläufe beschrieben.

In diesem Artikel werde ich die Bedeutung des Release-Zyklus einer Anwendung und die wichtige Rolle, die er in unserem DevOps-Modell spielt, untersuchen.

Aber bevor ich beginne, ist es notwendig, dass ich kurz einige wesentliche Abschnitte aus meinem vorherigen Artikel zusammenfasse, insbesondere SDLC, und auch eine Tatsache noch einmal betrachte, die viele von uns in der Informatik-Akademie möglicherweise seit Jahrzehnten versehentlich verfolgt haben. P>

Ich werde die Schritte nicht noch einmal im Detail ausführen, da der vorherige Artikel bereits hier verlinkt wurde. Aber das SDLC-Diagramm schaue ich mir gleich nochmal an.

Bedeutung des Software-Release-Lebenszyklus in DevOps

Der Software Release Life Cycle, kurz SRLC, ist ein obligatorisches Verfahren, das während der Entwicklung einer Anwendung durchgeführt wird. Dies ist eine entscheidende Notwendigkeit, da hochwertige Software für hochwertige DevOps sorgt. Das kann nur effektiv gewährleistet werden, wenn die verschiedenen Phasen effizient vorangetrieben werden.

Der Software-Release-Lebenszyklus

Ein Software-Release-Lebenszyklus oder SRLC ist die Abfolge verschiedener Phasen, durch die sich die Entwicklung einer Software von einer Pre-Alpha-Phase in eine Produktionsphase entwickelt. Es ist ein kontinuierlicher Prozess, da jede Software immer ihre aktualisierte Version hat, bis sie das Ende ihrer Lebensdauer (EOL) erreicht.

Die Namen und Praktiken können von Entwickler zu Entwickler variieren. Aber im Allgemeinen gibt es fünf wesentliche Phasen:

  1. Pre-Alpha :Die erste Phase in Softwareversionen, die nur die Hauptfunktionalität umfasst und höchstwahrscheinlich die maximale Anzahl von Fehlern aufweist. Es wird nur von Entwicklern und Testern getestet.
  2. Alpha :Die zweite Phase der Software-Releases wird als Feature-Complete angesehen und weist wahrscheinlich immer noch Fehler auf, aber viel weniger als Pre-Alpha. Es wird von Entwicklern und Testern getestet. Abhängig von diversen NDAs kann es aber auch punktuell oder weltweit der Öffentlichkeit zugänglich gemacht werden.
  3. Betaversion :Die dritte Phase konzentriert sich hauptsächlich auf die Behebung von Fehlern und Problemen, die in den vorherigen zwei Phasen aufgetreten sind. Wie die Pre-Alpha-Version basiert auch die Verfügbarkeit von Beta-Software auf NDAs.
  4. Release Candidate :Eine Release Candidate-Version der Software ist eine Vorabversion, die das Potenzial hat, ein endgültiges stabiles Produkt zu sein. In der Regel erhält eine Release Candidate-Version keinen neuen Quellcode mehr zum Programm. Änderungen am Quellcode werden nur vorgenommen, wenn beim Testen auf Produktionsebene immer noch Fehler auftreten.
  5. Produktionsfreigabe :Wie es sehr offensichtlich ist, ist eine Produktionsversion das Endprodukt, das der breiten Öffentlichkeit als stabiles Produkt zur Verfügung gestellt wird.

Hinweis :Das Konzept der Geheimhaltungsvereinbarungen hat im Bereich der Open-Source-Software aufgrund eines transparenten Modells keinen großen Wert.

Basierend auf unserem neuen Modell arbeitet SRLC tatsächlich in zwei Phasen:

1. Entwicklungs-Release-Phase in ADLC

Die Anwendung wird in dieser Phase zu ihrer allerersten Version und durchläuft die meisten Release-Phasen (oben erwähnt), wenn sie ausgereifter und praktikabler wird. Bugs werden schrittweise reduziert und die Effizienz steigt im Laufe der Zeit.

2. Stabile Release-Phase in SDLC

Dies ist die Produktionsphase von SRLC, in der eine Entwicklungsversion zu ihrer ersten verfügbaren stabilen Version wird, die von Kunden und Benutzern verwendet werden kann.

Warum ist es ein "Lebenszyklus"?

Seit Jahrzehnten im akademischen Fach Software Engineering , haben die Informatik-Lehrpläne an verschiedenen Universitäten das Software-Release-Prozessmodell als Zyklus erwähnt. Aber das dargestellte Diagramm ist ziemlich widersprüchlich. Typischerweise wird es wie folgt beschrieben:

Basierend auf einer einfachen Beobachtung ist es sehr offensichtlich, dass das obige Diagramm überhaupt keine "zyklischen" Eigenschaften zeigt. Basierend auf diesem konventionellen Modell wird es Zyklus genannt, obwohl das Diagramm keine solche Charakteristik zeigt … es kann nicht Zyklus genannt werden … es ist ein Flussdiagramm.

Um es wie einen Zyklus aussehen zu lassen, müsste die Produktionsphase zurück in die Pre-Alpha-Phase gehen, und das würde keinen logischen Sinn ergeben, es sei denn, das gesamte Szenario wird noch einmal kritisch überprüft:

Sie können deutlich erkennen, dass die Software in der stabilen Version ihr volles Potenzial erreicht hat und in der Produktion eingesetzt werden kann. Obwohl es im Diagramm nicht angezeigt wird, warum wird es dann als "Lebenszyklus" bezeichnet?

Hier ist der Grund

Wenn die Produktionsversion von Benutzern/Kunden angenommen wurde, nehmen die Entwickler der Software immer noch Verbesserungen daran vor, indem sie weitere Funktionen hinzufügen, vorhandene optimieren, Fehler und Sicherheitslücken während der Produktion beheben und andere Änderungen vornehmen, die im Laufe der Zeit erforderlich wären . Daher ist hinter den Kulissen immer eine Entwicklungsversion am Werk.

Unabhängig davon, wie kritisch eine Software getestet wird, gibt es bestimmte Fehler, die sich nur in einem realen Szenario zeigen würden, und diese Fehler werden in der aktualisierten Version jeder Produktionsversion behoben.

Lassen Sie uns einen Moment darüber nachdenken. Kann ein Produktionsrelease wirklich als Endprodukt bezeichnet werden, wenn die Software in Form von aktualisierten Versionen kontinuierlich weiterentwickelt wird?

Wie kann man das Diagramm und seine Szenarien als echten Zyklus überprüfen?

Um diesen Prozess als Zyklus wahrnehmen zu können, müssen wir unser zuvor beschriebenes neues SDLC-Modell noch einmal betrachten:

Wenn Sie es nur aus Sicht der Softwareversion betrachten möchten, kann das SDLC-Modell in SRLC umgewandelt werden:

Eine Softwareanwendung bezieht sich nur auf ihre Entwicklung, während ein Softwaresystem sowohl die Entwicklung der Anwendung als auch der systemischen Prozesse betrifft, unter denen sie bereitgestellt und gewartet wird. Wenn wir weiter vereinfachen, können wir es uns wie folgt neu vorstellen:

Lassen Sie uns in die Entwicklungsversion(en) hineinzoomen Zone, um zu sehen, was tatsächlich vor sich geht, und unseren "Lebenszyklus" abzuleiten:

Hier können Sie beobachten, dass die ersten vier wesentlichen Phasen nun als Teil eines tatsächlichen Zyklus dargestellt werden. Jede dieser Phasen wird auch Anwendungsentwicklung unterzogen basierend auf ADLC (im Diagramm als ADLC bezeichnet), wenn sie zur nächsten Phase übergehen. Sobald die Softwareentwicklung die Release Candidate-Phase verlässt, wird sie der Systementwicklung unterzogen basierend auf SDLC (im Diagramm als SDLC gekennzeichnet), um schließlich eine stabile Version zu werden, die durch Produktionsbereitstellungen wie Endbenutzer- und Kundenumgebungen aktiv wäre.

Warum muss eine stabile Version jetzt in einen Pre-Alpha-Zustand zurückkehren? Nur um sich als Lebenszyklus darzustellen? Definitiv nicht.

Eine stabile Version muss erneut einem Pre-Alpha-Level-Screening unterzogen werden, um durchgängig die höchstmögliche Qualität aufrechtzuerhalten.

Da das Produkt bereits als stabile Version veröffentlicht wurde, dauert das Debuggen und Testen in den Pre-Alpha-, Alpha- und Beta-Phasen nicht sehr lange. Sie müssen also bedenken, dass ein neues Produkt, nachdem es für die Öffentlichkeit freigegeben wurde, sich schnell dem Release Candidate-Screening nähert, nachdem es tatsächlich bereitgestellt und von allen Arten von Benutzern geprüft wurde.

Fehler auf Produktionsebene in Echtzeit sind unvermeidlich, und wie auch immer sie aussehen mögen, es ist notwendig, sie mit einem Pre-Alpha-Ansatz neu zu bewerten. Nur so kann durchgängig Qualitätssoftware mit optimaler Geschwindigkeit und Effizienz gewährleistet werden.

Daher kann dieses überarbeitete Modell nun endlich als tatsächlicher Zyklus bezeichnet werden und nicht als herkömmliches Flussdiagramm, dem viele von uns in der Entwickler-Community möglicherweise seit Jahrzehnten versehentlich folgen! Es handelt sich um einen kontinuierlichen Prozess, weshalb er als Software-Release-"Lebenszyklus" bezeichnet wird.

Wenn Sie Vorschläge, Feedback oder Kommentare zu diesem Thema haben, teilen Sie uns dies bitte im Abschnitt unten mit. Wir würden uns freuen, wenn Sie sich an solch interessanten Ansätzen beteiligen würden. Seien Sie gespannt auf den nächsten Artikel dieser Reihe :)


Linux
  1. Warum hat der Server meine IP blockiert?

  2. Warum funktioniert das ~/.bash_profile nicht?

  3. Warum würde der Kernel Pakete fallen lassen?

  4. Linux – Warum kann der Kernel Init nicht ausführen?

  5. Warum kann ich die Linux-Anzeige nicht exportieren?

Die 7 besten Rolling-Release-Linux-Distributionen für Leute, die den neuesten und besten Kernel und Software wollen

Warum nicht Softwarepakete aus dem Internet installieren

DevOps vs. Software Engineer:Was ist der Unterschied?

Hauptaufgaben eines DevOps-Ingenieurs

So aktualisieren Sie Linux Mint auf die neueste Version

Warum kann ich im Terminal nicht scrollen?