Dev for Ops의 충돌 코스?

CompSci에서 우리는 주로 Java를 배웠지 만 학교에서 열정은 시스템이라는 것을 알게 되었기 때문에 항상 운영 부서에서 일했습니다. 스크립팅에 익숙하기 때문에 루비를 가르쳐 줄 사이트를 찾지 않고 하루 종일 여러분이하는 일에 대해 더 깊이 설명 할 수있는 것이 있습니다. 문화를 더 잘 이해하고 프로젝트의 많은 수의 파일, 즉 무형을 소화하는 방법을 이해하고 싶습니다.

오늘 배운 것을 월요일에 개발 팀으로 옮겼다면 이번 주말에 무엇을 읽고 싶습니까?

이 질문에 "culture"로 태그를 지정 했으므로 특정 응용 프로그램에 관심이 없지만 워크 플로 및 관리에 대한 광범위한 질문에 관심이 있다고 가정합니다.

아마 "The DevOps Handbook"으로 시작할 것입니다. 너무 깊이 다이빙하지 않고 고려해야 할 여러 가지 사항에 대한 좋은 개요입니다.

Jez Humble의 "Continuous Delivery"도 종종 언급됩니다. 아직 많이 읽지는 ​​않았지만 빌드의 소스 제어 및 자동화 개념을 다룹니다.

규모에 맞게 애플리케이션을 시작하기 시작한 경우 (이는 너무 많은 가정 일 수 있음) Limoncelli et al.의 "클라우드 시스템 관리 실무"라는 또 다른 좋은 책이 있습니다.

이것은 DevOps가 아니라 직접적인 소프트웨어 개발이라고 생각합니다.

문화를 더 잘 이해하고 싶습니다

음, "DevOps"각도가없는 직선 개발에서 가장 큰 것은 "민첩한"즉, 대부분의 스크럼입니다. 더 일상적인 버그 수정, 유지 보수 작업을 위해 SCRUM 또는 Kanban의 Agile Manifesto 또는 입문서를 읽고 읽는 것보다 더 나쁠 수 있습니다.

그 외에도 "문화"라는 말은 개발자 측에서 주로 발생하는 데 주로 DevOps 고유의 것입니다. 그렇습니다. 우리에게는 전도자도 있습니다. 특히 루비 나 골랑과 같은 새로운 것들을위한 것이지만 실제 패러다임 변화가 진행되는 데브 옵스 / 클라우드 세계만큼 극단적 인 것은 아닙니다.

프로젝트의 수많은 파일을 요약하는 방법

사소한 루비 애플리케이션에서 직접 작업 해 본 결과 큰 문제는 아닙니다. 이 파일들은 닐리-윌리 (Nilly-willy) 주변에 흩어져있는 것이 아니라 계층 구조, 규칙 등이 있습니다. 잘 설계된 프로젝트를 위해 실제로 모든 파일을 한 시점에 두지 않아도됩니다. 특정 영역에서 작업하는 경우 일반적으로 관련 파일의 위치가 매우 명확하며 쉽게 확대 할 수 있습니다. 동일 해야 다른 현대 프로그래밍 환경에 대한 이동합니다.

나쁜 응용 프로그램에서는 다릅니다. 그러나 개발자는 실제로 어떤 것도 "소화"하지 않고 하루 종일 열광적 인 상태로 종료됩니다. ;)