Dev for Opsのクラッシュコース？

私は主にJavaを教えられたCompSciで教育を受けましたが、そこで学んだことは、私の情熱がシステムであることです。そのため、私は常に運用面で働いてきました。私はスクリプティングが得意なので、Rubyを教えるためのサイトを探しているのではなく、開発者が1日に何をしているかをより詳しく説明するものを探しています。私は文化をよりよく理解し、プロジェクト内の膨大な数のファイル、つまり無形資産をどのように消化するかを理解したいと思います。

今日私が月曜日に開発チームに移動されたことを知った場合、今週末何を読みたいですか？

この質問に「文化」というタグを付けたので、特定のアプリケーションではなく、ワークフローと管理の幅広い質問に興味がないと想定しています。

私はおそらく「The DevOps Handbook」から始めるでしょう。深く掘り下げることなく、考慮すべきさまざまな事柄の概要がわかります。

Jez Humbleによる "Continuous Delivery"もしばしば参照されます。まだ多くは読んでいませんが、ソース管理とビルドの自動化の概念について説明しています。

大規模なアプリケーションに取り掛かり始めている場合（これは想定が多すぎる可能性があります）、別の優れた書籍は、Limoncelliらによる「クラウドシステム管理の実践」です。

これはDevOpsについてではなく、まっすぐなソフトウェア開発についてだと思います。

文化をもっと理解したい

まあ、まっすぐな開発（「DevOps」の角度なし）で重要なことは、確かに「機敏」、つまりほとんどの場合SCRUMです。あなたは座ってアジャイルマニフェストやSCRUMの入門書、あるいはより日常的なバグ修正やメンテナンスの仕事のためのかんばんを読むよりも悪いかもしれません。

それとは別に、「文化」といえば、開発側から見た場合、ほとんどがDevOps固有のものです。はい、伝道者もいます。特にルビーやゴランのような新しいもののためですが、実際のパラダイムシフトが起こっているDevOps / Cloudの世界ほど極端ではありません。

プロジェクト内の膨大な数のファイルをどのように消化するか

自明ではないルビーアプリケーションに自分で取り組んできたので、それは大したことではありません。ほら、これらのファイルは単にnilly-willyの周りに散らばっているだけでなく、階層、規則などすべてがあります。適切に設計されたプロジェクトの場合、特定の時点でこれらのすべてのファイルを頭に置く必要はありません。特定の領域で作業している場合、通常、関連するファイルの場所はかなり明確であり、かなり簡単に拡大できます。同じなければならない他の近代的なプログラミング環境のために行きます。

悪いアプリケーションではそれは異なりますが、開発者は実際には何も「ダイジェスト」せず、終わらせるまで1日中狂乱に出くわします。;）