DevOps bedeutet, dass Entwickler jetzt die Verantwortung für die Infrastruktur und die Freigabe übernehmen - aber was sind die Treiber für diese Änderung?

18

Ich lege meine Karten auf den Tisch: Ich bin Entwickler und habe sowohl in "DevOps" als auch in Nicht-Kulturen gearbeitet. Sich um die Infrastruktur und Releases sowie die Qualitätssicherung und die damit verbundene Zeremonie sorgen zu müssen, ist eine enorme Ablenkung vom Schreiben von gutem Code.

Aber die Branche bewegt sich in diese Richtung. Was sind die Gründe dafür? Welche Probleme brachte das "alte" Modell der Rollenspezialisierung mit sich?

process devops

— Ben
quelle

4

Wollen Sie damit sagen , dass der Code Qualität nach unten geht , weil Sie andere Dinge zu tun, oder Code Menge nach unten geht.

— Caleth

1

Nehmen Sie bitte Ihre Karten vom Tisch. Dies liest sich wie eine Beschwerde so, wie sie ist.

— Svidgen

7

@svidgen Wenn diese Frage nur ein Scherz wäre, wäre das anders, aber das OP hat das Recht, seine Meinung zu äußern und eine vollkommen gültige Frage zu stellen.

— Robbie Dee

1

@ Robbie sicher. Sie werden bemerken, dass ich es trotzdem beantwortet habe ... aber der "Meinungs" -Teil dieser Frage nimmt mehr als die Hälfte des Körpers ein und wird zwischen derselben Grundfrage, die wiederholt wird, eingeklemmt. In diesem Fall lenkt er von der potenziellen Reinheit der Grundfrage ab. Aber ja. Immer noch eine Antwort wert ..

— Svidgen

19

Der Hauptgrund ist die Wolke.

Früher wurde Ihr Code auf Diskette und dann auf CD ausgeliefert und dann auf einem Server und dann auf zwei Servern bereitgestellt (aus Gründen der Ausfallsicherheit). Die gesamte Bereitstellung konnte manuell erfolgen von einem Menschen, also wurden die Menschen darin geschult.

Heutzutage wird Ihr Code häufig von Dutzenden oder Hunderten von Servern verwendet. Das Bereitstellen, Konfigurieren und Bereitstellen auf diesen Servern kann von einem Menschen nicht realistisch manuell durchgeführt werden. Sie müssen Ihre Systemadministratoren mit genügend Skripten vertraut machen, um diesen Prozess zu automatisieren, da Sie jetzt Chef oder seine Verwandten verwenden. Aber ehrlich gesagt, gab es nicht genug Systemadministratoren, die das konnten. Also wurden Entwickler herangezogen, um die Lücke zu schließen.

Und ja, wenn man den ständig wachsenden Anforderungen von Entwicklern mehr Fähigkeiten hinzufügt, verringert sich natürlich auch ihre Kompetenz an anderer Stelle. Die Idee ist, dass Entwickler einen Einblick in den Build- / Release-Prozess erhalten, Probleme besser antizipieren können oder die Autonomie haben, diese zu verbessern. Die Idee ist, dass die Qualität von allem zunimmt, seit die Veröffentlichungsgewinne die Codeschreibverluste überholen.

Ich bin skeptisch, dass sich der Kompromiss so oft lohnt, wie die Leute es sich vorstellen.

— Telastyn
quelle

2

Du hast mich bei " Der Hauptgrund ist der Hintern " verloren.

— Tedder42

15

Es gibt viele verschiedene Gründe für verschiedene Organisationen, zu DevOps zu wechseln.
Ich werde versuchen, diejenigen aufzulisten, die oft auftauchen.

Verkürzung der Zeit für den Änderungszyklus
Zwischen der Anforderung einer Änderung und der tatsächlichen Bereitstellung und Verwendung in der Organisation liegt häufig viel Zeit. Zunächst wird es von den Entwicklern in einem der Entwicklungszyklen geplant und nach der Auslieferung in einem der Release-Zyklen des Betriebs. Beide Zyklen beinhalten Tests und bei festgestellten Problemen werden beide Zyklen zurückgesetzt. Durch die Integration der Entwicklungs- und Betriebsabteilungen können wir beide Prozesse rationalisieren.

Probleme mit Software oder Hardware
Erinnern Sie sich an den Bugs Bunny-Cartoon, in dem sich Bugs und Daffy streiten, ob es Entenzeit oder Hasenzeit ist? Stellen Sie sich vor, wir haben es stattdessen mit Entwicklern und Vorgängen gemacht, bei denen Entwickler argumentieren, dass es sich um ein Hardwareproblem handelt, und bei Vorgängen, dass es sich um ein Softwareproblem handelt. Für den Endverbraucher ist dies eine Unterscheidung ohne Unterschied. Sie wollen nur, dass es repariert wird.
Indem sie Entwickler und Betriebe zusammenbringen, müssen sie die Probleme beheben. Und es könnte sich herausstellen, dass es sich um ein Software- und Hardwareproblem handelte.

Wir gegen sie
In vielen Unternehmen wuchs die Distanz zwischen Testern und Entwicklern, da es sich um separate Abteilungen handelte und der Entwicklungszyklus immer formalisierter und standardisierter wurde.
Mit dem Erscheinen von Agile haben Entwickler und Tester enger zusammengearbeitet und wir haben begonnen, die Sichtweise des anderen im Entwicklungszyklus zu sehen und vielleicht sogar zu respektieren.
Ähnliches muss zwischen Entwicklern und Betrieben geschehen, da mit der weiteren Formalisierung und Standardisierung der beiden Bereiche und Prozesse die Distanz zwischen diesen Abteilungen zunimmt. Eines der Probleme mit dem traditionellen Modell ist, dass es für Entwickler und Betriebe gleichermaßen wie "wir" gegen "sie" aussieht. Beide verstehen die Schwierigkeit der Verantwortlichkeiten des anderen nicht ganz.

Erwartungen / Vorteile
Mit DevOps lernen beide Fachbereiche einige der Fähigkeiten, die traditionell von den anderen ausgeübt werden. Niemand wird erwarten, dass ein Systemadministrator ein Softwareentwickler oder ein Entwickler ein Netzwerktechniker wird, aber von beiden wird erwartet, dass sie einen Teil der Verantwortung des anderen übernehmen. Das heißt, wenn Sie wirklich zusätzliche Hände brauchen, sind sie da.

Und es gibt einige Vorteile für Entwickler: Sie haben jetzt mehr Kontrolle über Ihre Testumgebungen, es ist einfacher, Software für die Benutzer bereitzustellen und mehr Mitarbeiter in Ihrem Unternehmen zu haben, mit denen Sie Ihre Vorliebe für das Handwerk teilen können.

— Miguel van de Laar
quelle

4

+1 - Weil es um den Endbenutzer geht und nicht nur um den Code.

— JeffO

3

Das Schreiben von Qualitätscode reicht einfach nicht aus. Sie sind entweder Teil des Problems oder Teil der Lösung.

Für viele Programmierer schreiben Sie Software, die von einem Endbenutzer bezahlt wird. Das Schreiben von Qualitätscode ist eine gute Sache, aber Kunden / Manager gehen auch davon aus, dass Sie immer schnell handeln sollten. Es ist, als würde man sagen, ein Tischler schneidet Bretter genau, aber baut man tatsächlich etwas, wofür jemand bezahlen möchte?

DevOps gibt den Entwicklern mehr Kontrolle und erzwingt hoffentlich, dass ihr Code mit dem Endergebnis übereinstimmt. Wer ist am besten geeignet, um den Betriebsprozess zu automatisieren? Die Zufriedenheit der Endbenutzer ist der wichtigste Maßstab. Sie müssen nicht nur einen Qualitätscode schreiben, sondern auch den Kunden zufrieden stellen. Entschuldigung, aber niemand verwendet mehr Codezeilen. Es ist ihnen egal, ob Sie Ihr eigenes ORM-Framework von Grund auf neu erstellt haben, genau wie es dem durchschnittlichen Käufer von Eigenheimen egal ist, ob Sie den Baum gefällt und Ihre eigenen Boards erstellt haben. Möchte jemand alle Konfigurationsdateien wiederholen, weil Ihr "Upgrade" sie auf die Standardeinstellungen zurücksetzt?

Sie möchten Ihre Entwickler-Chops zur Schau stellen? Bauen Sie etwas, das die Leute kaufen möchten und das die gesamte Benutzererfahrung einschließt. Es ist großartig, dass Sie Qualitätscode schreiben, aber leider erhalten Sie möglicherweise keinen Bonus, wenn er nicht zur Zufriedenheit des zahlenden Kunden freigegeben wird. Sie können QA gerne beschuldigen, aber Ihr Unternehmen hat immer noch nicht genug Geld, um Sie mehr zu bezahlen.

— JeffO
quelle

2

Ich bin sicher, Sie wissen, wie schwer es ist, gute Software-Entwickler einzustellen. Und jetzt müssen sie gute Business-Analysten sein, an einer QS-Zeremonie interessiert sein und sich um die Freigabeprozesse sorgen. Die Anzahl der Leute, die die neue Bar treffen, wird verschwindend gering sein.

— Ben

2

@ Ben: Es gibt kein "und jetzt"; Dies sind Dinge, die gute Entwickler jahrzehntelang getan haben, bevor jemand dachte, DevOps sei etwas Neues und prägte den Begriff. Ihre Aufgabe als Entwickler ist es, Probleme zu lösen, die von der Notwendigkeit einer Lösung für jemanden reichen, um sicherzustellen, dass die Leute, die mit Ihrem Code umgehen müssen, nachdem Sie ihn geschrieben haben, keine Schwierigkeiten haben. Sparen Sie etwas davon und niemand wird sich darum kümmern, wie schön Ihre quadratischen Stifte sind, wenn sie einen zehn Pfund schweren Schlitten benötigen, um sie in runde Löcher zu treiben.

— Blrfl

Dies scheint ein Argument gegen die Spezialisierung zu sein. Dass eine Person ein Alleskönner sein sollte, der nichts beherrscht. Das wird in keiner anderen Branche empfohlen, es gibt keine Elektrizitäts-Maurer-Klempner-Dachdecker, die versuchen, jede Kleinigkeit über das Bauen eines Hauses zu verstehen

— Richard Tingle,

2

@RichardTingle: Niemand sagt, dass Sie alles verstehen müssen, aber Sie müssen die Dinge verstehen, die Ihr Produkt beim Gebrauch berührt. Ein Klempner muss genug darüber wissen, was Elektriker tun - oder zumindest mit einem zusammenarbeiten -, um zu wissen, dass es unsicher ist, eine Kaltwasserleitung durch einen Unterbrecherkasten zu führen, obwohl dafür Aussparungen vorhanden sind.

— Blrfl

Macht sich nicht einmal die Mühe, die Frage zu beantworten. -1

— RubberDuck

2

Es ist etwas, das mit Agile & Scrum Hand in Hand gegangen ist. Es gibt keine klar definierten Rollen mehr - jeder ist ein "Entwickler".

Und es ist nicht nur Ops. Entwickler müssen häufig Geschäftsanalysen, Tests, Datenbankadministration und Build-Manager übernehmen - die Liste geht weiter.

Im Zentrum des Problems stand die sogenannte Abwanderung . Je mehr verschiedene Rollen an einem Projekt beteiligt waren, desto mehr Besprechungen, Missverständnisse und Ressourcenkonflikte traten auf. Software schnell in den Griff zu bekommen, ist das Endspiel und alles, was dem in den Weg kommen könnte, ist auf der Strecke geblieben.

Das ist nicht ganz eine schlechte Sache. Ihr durchschnittlicher Entwickler erweitert seine Fähigkeiten, obwohl der Stau jetzt sehr dünn wird. Außerdem werden Streitigkeiten zwischen Programmierern und Serveradministratoren in Bezug auf mögliche Probleme bei der Bereitstellung vermieden. Entwickler möchten häufig Lösungen mit modernster Technologie herausbringen, und die Serveradministratoren haben oft keine Ahnung, was dies von einem Administrator-POV bedeutet, bis ihnen das Installationsset präsentiert wird.

Die klügeren und vorausschauenderen Unternehmen beginnen endlich zu begreifen, dass T-förmige Menschen eine gute Sache sind. Es gibt jedoch einen Unterschied zwischen der Annahme, dass sie eine gute Sache sind und der Erwartung, dass dies auf magische Weise geschieht, wenn zuvor eine traditionelle Kultur angenommen wurde.

— Robbie Dee
quelle

-1 "sind nicht mehr klar definierte Rollen - jeder ist ein Entwickler." Das stimmt überhaupt nicht. Ein Scrum-Team soll sich aus verschiedenen Personen zusammensetzen, zu denen Entwickler, Grafiker, IT-Mitarbeiter usw. gehören. Die Rollen verschwinden nicht, aber die Idee ist, dass sie jetzt alle in einem einzigen Team sind, nicht getrennte Abteilungen.

— Andy

1

@Andy Ich würde vorschlagen, dass Sie den Scrum-Leitfaden erneut lesen : Scrum erkennt keine Titel für andere Mitglieder des Entwicklungsteams als Entwickler, unabhängig von der von der Person ausgeführten Arbeit. Es gibt keine Ausnahmen von dieser Regel . Die Leute sind natürlich spezialisiert, aber von Natur aus soll es eine sich selbst organisierende Einheit sein.

— Robbie Dee

Wenn ein Entwickler jemanden anruft, dessen Spezialität das Erstellen von Grafiken in Photoshop ist, oder dessen Rolle das Übersetzen ist, ist dies irreführend, da unter Entwickler in Softwareprojekten allgemein Softwareentwickler zu verstehen sind. Der Scrum Guide ist einfach falsch mit dieser Aussage.

— Andy

0

Ich bin mir sicher, dass es nicht wenige gute Gründe für Entwickler gibt, auch die Abläufe und die Qualitätskontrolle (manchmal) zu verwalten. Hier sind drei davon:

Interesse
Einige Entwickler möchten eigentlich alle Aspekte des Produkts bearbeiten. Wenn sie gut darin sind und eine Lücke im Team füllen oder vorhandene Teammitglieder in anderen Rollen gut unterstützen, gibt es möglicherweise keinen Grund, sie zu stoppen.
Kosten
Große Unternehmen können sich spezialisierte Mitarbeiter leisten. Kleine Unternehmen können das manchmal nicht. In einigen dieser Unternehmen können 1 oder 2 oder 3 Entwickler eingestellt werden, die in der Lage sein müssen, einfach Arbeitsaufgaben zu erledigen.
Projektgröße
Nicht jedes Projekt ist ein Mehrpersonenprojekt. Wenn Sie eine "kleine" Anwendung erstellen, kann es einfach übertrieben sein, wenn mehr als eine Person sie vollständig bearbeitet. Darüber hinaus sind kleine Projekte mit vielen Personen, die bestimmte Rollen spielen, beängstigend . Niemand hat genug zu tun - auch wenn Sie es sich leisten können , sie alle sechs Monate lang mit den Daumen zu drehen, bleiben die Guten nicht. Wenn sie sich nicht langweilen, bekommen sie Angst, oder Sie werden feststellen, dass Sie einiges für nichts bezahlen. In jedem Fall verlassen Ihre guten Mitarbeiter das Unternehmen und fordern alle auf, sich von Ihnen fernzuhalten.

... und andere Gründe, da bin ich mir sicher.

— Svidgen
quelle

0

"Sich um die Infrastruktur und Releases sowie die Qualitätssicherung und die damit verbundene Zeremonie sorgen zu müssen, ist eine enorme Ablenkung vom Schreiben eines guten Codes."

Meiner Meinung nach macht sich DevOps Gedanken über Infrastruktur und Releases, und die Qualitätssicherung schreibt guten Code.

In früheren Rollen in Nicht-DevOps-Kulturen hatte ich zahlreiche Probleme, die eine DevOps-Kultur möglicherweise hätte verhindern können. Leistungsprobleme in Bezug auf Code, der auf nicht repräsentativen Plattformen entwickelt wurde, Zeichencodierungsprobleme, bei denen die Entwickler die von einem Client verwendeten Zeichencodierungen nicht kannten, Bereitstellungsanweisungen, die manuell codiert wurden und für das Ops-Team ohne ein gewisses Maß an Vermutung unzureichend waren -Arbeit.

Nun könnte man argumentieren, dass wir durch die zunehmende Spezialisierung sowohl auf der Dev- als auch auf der Ops-Seite einige dieser Probleme überwinden können. Dennoch können viele Probleme nur durch den Austausch von Wissen und Arbeit zwischen unseren Teams gelöst werden.

— matt freake
quelle

0

DevOps muss nicht "Dev jetzt auch Ops" bedeuten. Der Begriff bedeutete ursprünglich "Dev und Ops arbeiten eng in einem Team zusammen". Es tut , dass die Leute von Ops mehr wie Devs werden müssen, weil das Automatisieren von Dingen eine Art Programmierung erfordert und der alte manuelle Weg dies nicht verhindert (siehe die anderen Antworten für detailliertere Erläuterungen zu diesem Punkt).

Aus Wikipedia :

DevOps (eine abgeschnittene Mischung aus Entwicklung und Betrieb) ist eine Kultur, Bewegung oder Praxis, die die Zusammenarbeit und Kommunikation sowohl von Softwareentwicklern als auch von anderen IT-Fachleuten betont und gleichzeitig den Prozess der Softwarebereitstellung und Änderungen der Infrastruktur automatisiert

Meiner Meinung nach ist dies eine Fehleinschätzung des Managements, wenn Sie als Entwickler die gleichen alten Verantwortlichkeiten und zusätzlich jetzt die operativen Verantwortlichkeiten haben. Durch die Automatisierung ist es durchaus möglich, dass Sie weniger Ops-Mitarbeiter benötigen und somit tatsächlich Kosten einsparen. Aber DevOps bedeutet sicherlich nicht "Lasst uns alle Ops-Leute loswerden und die Devs der zusätzlichen Arbeit überlassen".

Wie so oft bei Buzzwords passiert eine semantische Diffusion und plötzlich denken die Leute: "Lassen Sie uns Devs dazu bringen, auch Ops zu machen, und ich denke, wir können Geld sparen ..."

— jhyot
quelle