Ist DevOps auf Unternehmen mit SaaS-Produkten beschränkt?

Die Praktiken, die DevOps beschreiben, wie z. B. kontinuierliche Lieferung, Automatisierung usw., sind für Produkte relevant, die kontinuierlichen Service bieten, wie z. B. SaaS-Produkte.

Ein Softwareentwicklungsunternehmen, das zumeist Projekte für andere Kunden ausführt, wird diese möglicherweise nach Abschluss des Projekts nie mehr warten. Und Kundenprojekte werden nicht mit anderen Kunden geteilt, weil sie irrelevant sind.

Gilt DevOps auch für Unternehmen, die mehrere Projekte entwickeln, die einmalig sind? Welche DevOps-Praktiken gelten in diesem Fall, wenn überhaupt?

Absolut nicht!

Bei DevOps geht es darum, die traditionellen Silos (Abteilungen) aufzubrechen, um effizienter zu sein.

Eine bessere Kommunikation zwischen den Teams, eine verbesserte Sichtbarkeit und ein zuverlässiger und automatisierter Prozess sind Möglichkeiten, ein besseres Produkt zu erzielen.

Früher arbeitete ich für ein großes Medienunternehmen, in dem wir ein internes Tool unterstützten und öffentlich zugängliche Websites entwickelten.

Die Vorteile von DevOps in unserem Fall waren die folgenden:

• Durch kontinuierliches Bauen informieren wir das Entwicklungsteam eher früher als später, wenn es Integrations- oder Buildprobleme mit dem Code gibt. Sie können Probleme beheben, während sie sich noch mit dem Code befassen, den sie gerade geschrieben haben.
• Durch kontinuierliche Tests und Lieferung (in QA) haben wir es dem QA-Team ermöglicht, Probleme früher zu finden und früher zu melden. Dies reduzierte den Zeitaufwand für das Auffinden und Korrigieren von Fehlern sowie die Komplexität dieser Untersuchungen.
• Ohne Tools zum Sammeln und Zusammenfassen von Protokollen haben wir den Entwicklern Zugriff auf Dinge gewährt, die sie normalerweise nicht sehen würden (sie waren sehr an den Debuggern interessiert :). Durch das Verstehen, wie Protokolle von anderen Teams gesehen und verwendet werden, wurde die Gesamtqualität der Protokolle verbessert
• Wir haben oft Informationen ausgetauscht und Dokumentationen erstellt, um Wissen zwischen Teams auszutauschen und Mauern niederzureißen. Wenn wir die Anforderungen der Ops verstehen, erstellen wir ein paar Anleitungen, was beim Booten einer Anwendung immer beachtet werden sollte (wo / wie Eigenschaften verwaltet werden usw.). Durch das Verständnis der Realität des Entwicklers (Code mit mehr Funktionen, schneller, Gogogogo!) Konnten wir die Ops Server und Cluster erstellen lassen, die besser auf die Bedürfnisse des Entwicklers zugeschnitten waren.
• Die Gesamtqualität der Bereitstellungen wurde ebenfalls erheblich verbessert. Die Bereitstellung wurde von unserem Team durchgeführt, sodass wir sowohl für die Operations als auch für die Entwicklungsabteilung eine perfekte Sicht hatten. Dies beseitigte viele Probleme im Zusammenhang mit der "Codeübergabe", bei der der Entwickler ein Paket und ein einseitiges Dokument an die Ops mit der Aufschrift "Install this!" Übergab.

Alles in allem würde ich sagen, dass jedes Unternehmen unabhängig davon, ob Sie Ihre Produktionsumgebung einmal pro Tag oder einmal pro Monat aktualisieren und wie viele Kunden Sie haben oder über welches Geschäftsmodell Sie verfügen, eine bessere Kommunikation, bessere Tools, bessere Transparenz und schnelleres Feedback nutzen kann. etc.

Mein Team und ich sind verantwortlich für die Entwicklung von "einmaligen" Produkten, die dem Kunden zur Instandhaltung übergeben oder in einigen Fällen von uns gegen eine Gebühr verwaltet werden.

Wir müssen weiterhin eine solide Entwicklungs-Pipeline aufrechterhalten, um das ständige Feedback unserer Kunden zu verarbeiten und sicherzustellen, dass wir ihnen etwas Zuverlässiges liefern, das nachweislich funktioniert.

Obwohl sich der Kunde (in den meisten Fällen) nicht um DevOps kümmert, ist es dennoch hilfreich für uns. Mit DevOps können wir neue Builds schnell pushen, sodass Kunden innerhalb von Minuten und nicht Stunden Feedback erhalten, und wir sind auch in der Lage, Fehler / Bugs bei unseren Tests über Jenkins / Travis zu erkennen.

Um sicherzustellen, dass unsere Bereitstellungsstrategien projektübergreifend gleich sind, konzentrieren wir uns auf die Containerisierung unserer Anwendungen. Mit Docker können wir die Bewerbung problemlos an unsere Kunden weitergeben.

Die durch DevOps gesparten Kosten sind schwer zu bestimmen. Wir haben zusätzliche Kosten in Form von Software, die wir für die Pipeline verwenden (Travis, Jenkins, Puppet, was haben Sie), aber wir sparen auch Zeit und Geld, indem wir Fehler beheben / dem Kunden schnelles Feedback geben. Unsere schnelle Reaktionszeit sorgt dafür, dass unsere Kunden zufrieden sind und unsere Geldbörsen zufrieden sind.

Ich habe für Unternehmen gearbeitet, die Software als Shrink-Wrap-Produkte, als vollständig installierte und unterstützte Bereitstellungen und als eingebetteten Code in Geräten produzieren. In all diesen Unternehmen leistet DevOps wesentliche Unterstützung für die Entwicklung:

• Automatisierte, reproduzierbare Software-Builds mit bekannten, kontrollierten Konfigurationen von Compilern, Bibliotheken und anderen Build-Tools.
• Automatisierte, wiederholbare Systemtests für Regressionstests und für neue Funktionstests.
• Andere automatisierte und regelmäßige Aktionen (z. B. ständig aktualisierte Beispiel-Screenshots, die in allen unterstützten Sprachen verfügbar sind, von Übersetzern überprüft und von technischen Autoren in Benutzerhandbücher integriert werden können).

In allen Fällen sind dies Dinge, die einzelne Entwickler als einmalige Aktionen ausführen könnten , aber dies würde weder die Entwicklerzeit sinnvoll nutzen noch die gleiche Sicherheit hinsichtlich der Konfigurationskontrolle bieten, die die automatisierten Builds haben.

Die bisherigen Aktivitäten zur Entwicklung und Implementierung von Software erforderten keine tiefe Integration zwischen den Abteilungen. Für heute ist es jedoch notwendig, alle Abteilungen (Entwicklung, IT-Betrieb, Qualitätssicherung usw.) eng zusammenzuarbeiten.

Für Entwickler ist Veränderung das, wofür sie bezahlt werden. Unternehmen brauchen immer Veränderungen, um mit der modernen Welt Schritt zu halten. Dieses Verständnis drängt die Entwickler, die maximal mögliche Anzahl von Änderungen zu produzieren. IT-Profis haben ein anderes Verständnis, in dem Veränderung Schaden anrichtet. Jeder von ihnen denkt, dass es richtig funktioniert, was dem Geschäft zugute kommt. In der Tat, wenn wir sie getrennt betrachten, sind sie beide richtig.

Alle Mitarbeiter müssen verstehen, dass sie Teil eines einzelnen Prozesses sind. DevOps pflegt das Denken, was es ermöglicht zu erkennen, dass die persönlichen Entscheidungen und Handlungen aller auf die Verwirklichung eines einzigen Ziels gerichtet sein sollten. Der Erfolg sollte sich am gesamten Entwicklungszyklus und nicht am Erfolg einzelner Rollen messen lassen. In enger Zusammenarbeit zwischen Entwicklern und Instandhaltungsspezialisten entsteht eine neue Generation von Ingenieuren, die die besten Leistungen beider Disziplinen zum Nutzen des Anwenders kombinieren. Dies zeigt sich im Auftreten funktionsübergreifender Teams mit Erfahrung in Entwicklung, Konfigurationsmanagement, Datenbankmanagement, Test und Infrastrukturmanagement.

Die Methodik ist also nicht nur in SaaS nützlich.

Keineswegs. Zu diesem Thema gibt es bereits großartige Beispiele. Ich möchte jedoch eine eigene Anekdote veröffentlichen. Im Jahr 2001 erbte ich ein Softwareprojekt mit einer Veröffentlichung, die die Erstellung einer CD beinhaltete. Die Dokumentation für den Veröffentlichungsprozess enthielt 40 (!) Schritte, die von einem früheren Ingenieur dokumentiert wurden, einschließlich einiger lächerlicher handgeschriebener Anweisungen wie "Öffnen Sie diese Konfigurationsdatei und ändern Sie den Namen der .jar-Datei in Zeile 41, um die Versionsnummer von aufzunehmen die neue Version ".

Wir haben jeden Schritt dieses Erstellungsprozesses aggressiv automatisiert und handgeschriebene Anweisungen durch Dinge wie 'Patch' ersetzt, die mit Bash geschrieben wurden. Wir mussten sogar Tickets bei unserem Drittanbieter für Installationstools öffnen, um die Projektdateien patchfähig zu machen.

Sobald dieser Prozess automatisiert war, kauften wir eine 'CD Jukebox'. Jede Nacht, nachdem die Tests bestanden waren, erstellte die Build-Maschine automatisch eine neue Installations-CD. Unsere Tester könnten am nächsten Morgen kommen, sich eine Diskette schnappen und sicherstellen, dass alles installierbar ist.

Wir haben sicherlich engere Rückkopplungsschleifen, wenn wir Software als Service bereitstellen können, aber die Grundprinzipien für Automatisierung, Rückkopplung, Zykluszeit, kleine Releases usw. gelten.