Disclaimer: gestartet für 5y als Entwickler, seit 3y Ops, selbst immer in kleinen Unternehmen, aber durch Kunden auch Einblicke in größere gehabt. Ich finde meine Rolle in der international gängigeren Bezeichnung SRE gut beschrieben.
Ich hab schon verschiedene Ausprägungen davon gesehen. Meines Erachtens gibt es da ein paar Missverständnisse, die sich mancherorts mittlerweile etabliert haben. Nach meinem Verständnis bezeichnet DevOps ein mindset, also eine geistige Haltung, die man versuchen sollte, in seinem Team zu etablieren. Ziel ist es, den Graben zwischen Entwicklern (Dev) und Betrieb (Ops) zu überwinden. Es war nämlich lange Zeit so (und ist leider vielerorts immer noch so), dass seitens der Entwickler eher eine "Über-Den-Zaun-Werf"-Mentalität vorherrschte.
Das hängt auch mit der hierzulande geliebten Schuldfragen-Mentalität zusammen. Wenn es kracht, geht es reflexartig darum zu klären, auf wen mit dem Finger zu zeigen ist. Wenn man die Kultur pflegt, dass die Verantwortlichkeit des Entwicklers am Rande seines IDE-Fensters endet, dann fördert man das natürlich.
Gleichzeitig hat sich auf Ops-Seite dadurch eine eher ablehnende, ausbremsende, teils schikanierende Haltung etabliert. Ist ja auch logisch - wenn ich ab Entgegennahme des Binarys für alles was ab dann passiert den Kopf hinhalten muss (d.h. z.B. auch die Nachtschicht einlegen muss, wenn der Mist im Betrieb abraucht), dann gehe ich lieber skeptischer an alles ran, was aus Richtung Entwickler kommt.
Das ist dem Gesamtunternehmen alles nicht zuträglich, weder ökonomisch, noch atmosphärisch. Ein Team, in dem alle an einem Strang ziehen, wird innovativer und produktiver vorankommen.
Eine völlig fehlgeleitete Ausprägung von DevOps, die mir schon untergekommen ist, ist die Fehlinterpretation des Slogans "you build it, you run it". In einigen Firmen führt das dazu, dass originäre Ops-Aufgaben von Entwicklern "einfach so" mitgemacht werden. Das spart die Schnittstelle und damit Reibungsverluste. Es ist aber eine Illusion, dass der gemeine (ich rede hier also von der Mehrheit, natürlich gibt es Ausnahmen) Entwickler geeignet ist, ein halbwegs sicheres und verlässliches Produktiv-System zu betreiben. Ich weiß aus der Praxis, dass das Ende vom Lied "chmod 777" (symbolisch zu betrachten) ist, weil "läuft doch".
Soviel mal vornweg und nun gehe ich auf den konkreteren Teil deiner Frage ein, ob du Docker- und CI-Pipeline-Files schreiben kannst/sollst. Du merkst an der Stelle vielleicht schon, dass du nach Details fragst.
Ich sehe die Verantwortung für Docker- und Pipeline-Files grundsätzlich bei den Entwicklern. Nun ist es aber so, dass gerade Docker bei nicht-banalen Anwendungsaufbauten sehr schnell low level wird, d.h. man wildert tief im Dschungel, in dem sich sonst nur Ops bewegt. Die Bedürfnisse (Abhänigkeiten) deiner Anwendung kennst du als Entwickler am besten. Ops hat aber gewisse Anforderungen, die das System betreffen, auf dem die Anwendung mal laufen wird:
* wohin wird wie viel in welcher Form geloggt?
* mit welchen Rechten läuft die Anwendung und entspricht das dem nötigen Minimum?
* welche Ports müssen nach außen durchgeschliffen werden und welche Container müssen untereinander kommunizieren können?
* mit welchen sonstigen Parametern (z.B. Umgebungsvariablen) muss Ops Container starten?
* etc....
Nun ist es aber so, dass nicht ständig das Rad neu erfunden werden muss. Vieles kann man einmal gemäß Richtlinien lösen und dann zur Orientierung für künftige Projekte nutzen. Ich handhabe es daher so, dass ein Entwickler mit exotischen Anforderungen bei mir (Ops) aufschlagen kann, dann diskutiere ich ein paar Sachen weg, die unnötig sind und dann löse ich das Delta als proof of concept und stelle es der Entwicklung zur Verfügung. Ich erwarte also nicht, dass sich ein Entwickler in diese Materie einliest, denn das ist nicht seine Kernkompetenz. Ich möchte dafür auch nur so abstrakt wie möglich von der Fachlogik wissen und nicht von zig Projekten tausende Seiten Spezifikation lesen müssen.
Bei Pipelines (in meinem Fall Jenkinsfiles) verhält es sich so ähnlich, wobei ich hier die Entwickler noch mehr in der Pflicht sehe. Ich hab da zwar viel Pionierarbeit bei uns im Haus geleistet, da es in meinem Sinne ist, dass der Bauprozess in Code gegossen ist, aber wenn alles irgendwo schon mal gelöst wurde, soll sich der Entwickler bitte daran orientieren und bei nötigen Erweiterungen mal selbst die Suchmaschine bemühen.
Im Kern sollen sich alle zum gleichen Ziel bekennen, nämlich die Software des Hauses effizient herzustellen und an den Mann zu bringen. Das geht am besten, wenn die Leute miteinander statt gegeneinander arbeiten. Am Ende des Tages ist es völlig egal, wer das Dockerfile geschrieben hat. Es ist Teil der Arbeit, die gemacht werden muss und jeder sollte nach seinen Stärken eingesetzt werden, ohne dadurch aber Silos entstehen zu lassen. Wenn der CI-Server rot ist, geht das alle an (denn es gibt oft technische Gründe wie CI-Server-Updates, die das verursachen und da muss dann Ops mit ran). Wenn das Produktiv-System abraucht, geht das im ersten Moment erst einmal alle an (denn es könnte die Folge defekter Anwendungslogik sein). Wenn der Code nicht kompiliert, weil die neusten Versionen der Abhängigkeiten nicht mehr kompatibel sind, dann ist das Sache der Entwickler. Gehen Pakete im Netzwerk verloren, weil ein Switch kaputt ist oder die Firewallkonfiguration daneben ist, dann ist das Sache von Ops.
