Курс краху в Dev for Ops?

10

Я навчався в CompSci, де нас в основному навчали Java, але те, що я там дізнався , це те, що моя пристрасть - це системи, тому я завжди працював на стороні ops. Мені зручно писати сценарії, тож я не шукаю сайту, щоб навчити мене Рубі, а чогось більш глибоко пояснити, що ти робиш цілий день. Я хочу краще зрозуміти культуру і те, як ви перетравлюєте велику кількість файлів у своїх проектах - нематеріальні.

Якби я сьогодні дізнався, що мене перенесли в команду розвитку в понеділок, що я хотів би прочитати в ці вихідні?

— Стівен С
джерело

3

Я почав би читати свій "контракт" ... навіть якщо це було б лише якщо вам потрібно перемовити свою зарплату ... Крім того, просто вихідних точно не вистачає, щоб прочитати щось відповідне, особливо тому, що ви Здається, я не знаю, з якою "інфраструктурою" ви будете працювати ... уявіть, що це мейнфрейм, який працює з усіма екземплярами zLinux ... при цьому "z" є ярликом до нульового простою (не доцільно). .. щоб тримати літаки в повітрі ...

— Pierre.Vriens

@ Pierre.Vriens, веселий коментар. Будьте впевнені, це насправді не відбувається, або я зараз зайнятий своїм обліковим записом LinkedIn, але я не думаю, що подібний крок був би надзвичайним в ці дні. Деякі організації можуть дійсно отримати вигоду, торгуючи деякими співробітниками між командами розробників та операторами, і я впевнений, що деякі організації роблять саме це під час приводів для "впровадження DevOps".

— Стівен C

8

Оскільки ви позначили це питання як "культура", я припускаю, що вас цікавить не конкретна програма, а більш широкі питання робочого процесу та управління.

Я б, мабуть, почав з "Посібника з DevOps"; це хороший огляд різних речей, які слід враховувати, не занурюючись занадто глибоко.

Про "безперервну доставку" від Jez Humble також часто посилаються; Я ще багато цього не читав, але він охоплює поняття управління джерелами та автоматизацію побудов.

Якщо ви починаєте надходити в додатки в масштабі (це може бути занадто великим припущенням), ще одна хороша книга - "Практика адміністрації хмарної системи" Limoncelli et al.

— Стюарт Ейнсворт
джерело

1

Я прочитав близько 60% книги Лімончеллі, перш ніж втратити її в ході. Це, безумовно, мене багато чому навчило. Я також нещодавно розпочав "Проект Фенікса" Джина Кіма та ін., Який напрочуд переконливо читає, а також багато навчає.

— Stephen C

Мені також сподобалась книга Google SRE; це насправді краще підходить для моєї організації, ніж деякі речі DevOps, але сама книга роз'єднана. Ви повинні читати це не в порядку, вибираючи глави, які звертаються до вас, та решту прочищаючи решту.

— Стюарт Ейнсворт

7

Мова йде не про DevOps, а про пряму розробку програмного забезпечення.

Я хочу краще зрозуміти культуру

Ну, велика річ у прямому розвитку (без кута "DevOps"), безумовно, "спритний", тобто здебільшого SCRUM. Вам може бути гірше, ніж сісти і прочитати Agile Manifesto або буквар на SCRUM або Kanban для виконання щоденних завдань, виправлення помилок та обслуговування.

Крім того, що говорити про "культуру" взагалі є, що йде з боку dev, здебільшого специфічною для DevOps речі. Так, у нас є і наші євангелісти, спеціально для нових матеріалів, таких як рубін або голанг, але не такі екстремальні, як у світі DevOps / Cloud, де відбуваються фактичні зміни парадигми.

і як ви перетравлюєте велику кількість файлів у своїх проектах

Пропрацювавши над нетривіальними рубіновими програмами, це не велика проблема. Дивіться, ці файли не просто розсіяні навколо неволі-волі, але є ієрархія, конвенції та все таке. Насправді вам не потрібно мати усі ці файли в голові в один момент часу для добре продуманого проекту. Якщо ви працюєте в певній області, зазвичай досить зрозуміло, де знаходяться відповідні файли, і ви можете збільшити масштаб на них досить легко. Те саме має стосуватися інших сучасних середовищ програмування.

У поганих програмах це інакше, але тоді розробник насправді нічого не «перетравить», а просто спотикається цілком у шаленстві цілий день, поки він не вийде. ;)

— AnoE
джерело