Crashkurs in Dev for Ops?

10

Ich habe in CompSci geschult, wo uns hauptsächlich Java beigebracht wurde, aber was ich dort gelernt habe, ist, dass meine Leidenschaft Systeme sind, also habe ich immer auf der Operationsseite gearbeitet. Ich kann gut mit Skripten umgehen, daher suche ich nicht nach einer Website, auf der ich Ruby lernen kann, sondern nach einer ausführlichen Erklärung, was Ihre Entwickler den ganzen Tag tun. Ich möchte die Kultur besser verstehen und wie Sie die schiere Anzahl von Dateien in Ihren Projekten verdauen - die immateriellen Werte.

Wenn ich heute erfahren würde, dass ich am Montag in ein Entwicklungsteam versetzt werde, was würde ich an diesem Wochenende lesen wollen?

— Stephen C.
quelle

3

Ich würde anfangen, meinen "Vertrag" zu lesen ... selbst wenn es nur wäre, wenn Sie Ihr Gehalt neu verhandeln müssten ... Abgesehen davon reicht ein Wochenende mit Sicherheit nicht aus, um etwas Relevantes zu lesen, besonders weil Sie es nicht tun Es scheint nicht zu wissen, mit welcher Art von "Infrastruktur" Sie arbeiten werden. Stellen Sie sich vor, es ist ein Mainframe, auf dem alle Arten von zLinux-Instanzen ausgeführt werden. Das "z" ist eine Abkürzung für null Ausfallzeiten (nicht verhandelbar). .. um Flugzeuge in der Luft zu halten ...

— Pierre.Vriens

@ Pierre.Vriens, Urkomischer Kommentar. Seien Sie versichert, dies geschieht nicht wirklich oder ich wäre gerade mit meinem LinkedIn-Konto beschäftigt, aber ich denke nicht, dass diese Art von Umzug heutzutage außergewöhnlich wäre. Einige Organisationen könnten wirklich davon profitieren, wenn sie einige Mitarbeiter zwischen Entwicklerteams und Ops austauschen, und ich bin sicher, dass einige Organisationen genau das während der Laufwerke tun, um "DevOps zu implementieren".

— Stephen C

8

Da Sie diese Frage als "Kultur" markiert haben, gehe ich davon aus, dass Sie nicht an einer bestimmten Anwendung interessiert sind, sondern an den umfassenderen Fragen des Workflows und der Verwaltung.

Ich würde wahrscheinlich mit "The DevOps Handbook" beginnen. Es ist ein guter Überblick über verschiedene Dinge, die zu beachten sind, ohne zu tief zu tauchen.

Oft wird auch auf "Continuous Delivery" von Jez Humble verwiesen; Ich habe noch nicht viel davon gelesen, aber es behandelt die Konzepte der Quellcodeverwaltung und Automatisierung von Builds.

Wenn Sie anfangen, sich mit maßstabsgetreuen Anwendungen zu befassen (dies ist möglicherweise eine zu große Annahme), ist ein weiteres gutes Buch "The Practice of Cloud System Administration" von Limoncelli et al.

— Stuart Ainsworth
quelle

1

Ich habe ungefähr 60% des Limoncelli-Buches gelesen, bevor ich es auf einmal verloren habe. Es hat mir definitiv viel beigebracht. Ich habe auch gerade "The Phoenix Project" von Gene Kim et al. Gestartet, was eine überraschend überzeugende Lektüre ist und gleichzeitig viel lehrt.

— Stephen C

Mir hat auch das Google SRE-Buch gefallen. Es passt eigentlich besser zu mir in meiner Organisation als einige der DevOps-Sachen, aber das Buch selbst ist unzusammenhängend. Sie müssen es nicht in der richtigen Reihenfolge lesen, die Kapitel auswählen, die Sie ansprechen, und den Rest überfliegen.

— Stuart Ainsworth

7

Hier geht es nicht um DevOps, sondern um reine Softwareentwicklung, nehme ich an.

Ich möchte die Kultur besser verstehen

Nun, die große Sache in der geraden Entwicklung (ohne den "DevOps" -Winkel) ist sicherlich "agil", dh größtenteils SCRUM. Sie könnten es schlimmer machen, als sich hinzusetzen und das Agile Manifest oder eine Einführung in SCRUM oder Kanban für die alltäglicheren, fehlerbehebenden Wartungsarbeiten zu lesen.

Abgesehen davon ist das Sprechen von "Kultur" von der Entwicklerseite meistens eine DevOps-spezifische Sache. Ja, wir haben auch unsere Evangelisten, speziell für neuere Dinge wie Rubin oder Golang, aber nicht so extrem wie in der DevOps / Cloud-Welt, in der es tatsächlich Paradigmenwechsel gibt.

und wie Sie die schiere Anzahl von Dateien in Ihren Projekten verdauen

Nachdem ich selbst an nicht trivialen Ruby-Anwendungen gearbeitet habe, ist das kein Problem. Sehen Sie, diese Dateien sind nicht nur gut oder schlecht verteilt, sondern es gibt auch eine Hierarchie, Konventionen und all das. Für ein gut gestaltetes Projekt müssen Sie nie alle diese Dateien zu einem bestimmten Zeitpunkt in Ihrem Kopf haben. Wenn Sie in einem bestimmten Bereich arbeiten, ist normalerweise ziemlich klar, wo sich die relevanten Dateien befinden, und Sie können sie ganz einfach vergrößern. Gleiches sollte für andere moderne Programmierumgebungen gelten.

In schlechten Anwendungen ist das anders, aber dann "verdaut" der Entwickler eigentlich nichts, sondern stolpert den ganzen Tag in Raserei herum, bis er aufhört. ;)

— AnoE
quelle