민첩한 소프트웨어 개발 은 오늘날 소프트웨어 상점에서 선택하는 방법론입니다. 그러나 여전히 DevOps 도입에 관심이있는 소프트웨어 개발에서 Agile을 실행하지 않는 조직이 있습니다.

Agile Software Development라고 할 때 Agile Software Development 선언에서 나온 자손을 의미합니다 . 같은 익스트림 프로그래밍 , 스크럼 , 소프트웨어 개발 린 과 다른 사람을.

애자일 소프트웨어 개발은 ​​조직 수준에서 DevOps를 채택하기위한 필수 전제 조건입니까?

애자일 소프트웨어 개발은 DevOps를 수행 할 필요 는 없지만 , DevOps의 가치 제안이 애자일 없이도 훨씬 낮다는 주장을 할 수 있다고 생각합니다.

DevOps는 많은 것이지만 자동화 는 중심 주제입니다. 자동화의 가치는 Development가 새로운 릴리스를 생성하는 빈도에 비례하여 증가합니다. 빈번한 배포는 특정 유형의 제품, 특히 소비자 응용 프로그램에 긍정적 인 영향을 미칩니다. 소프트웨어 제공 라이프 사이클 전체에서 고속은 각 반복에 대한 값을 반환합니다 (좀비가 앱에서 새로운 기능을 원하는 CA 광고를 본 사람이 있습니까?)

애자일이 없으면 고주파 방출은 불가능하지는 않지만 극히 어렵습니다. 개발 팀이 분기에 1 회 또는 1 년에 2 회 소프트웨어를 배포하는 경우 DevOps는 프로세스를 자동화 할 수 있지만 요점은 무엇입니까? DevOps를 채택하기위한 시간, 교육 및 리소스에 대한 투자는 품질이 부분적으로 반환 될 수 있지만 최상의 가치는 배송 수명주기 동안 고속을 유지하는 것입니다.

DevOps를 채택 한다면 Agile도 채택 하지 않는 이유 는 무엇일까요? 그것들을 모두 작동시키고 잘 작동시키는 원리. Agile없이 DevOps 자체를 실행하면 Ops와 Dev간에 불균형이 발생하여 Ops가 서비스 제공 측면에서 Dev보다 성능이 뛰어납니다.

아니

Mature DevOps 작업에는 Mature Agile 프로세스 가 필요 하다고 주장합니다 . 성숙한 애자일 프로세스 없이도 배포 프로세스를 지속적으로 배포하거나 개발자가 배포 프로세스를 시작할 수 있도록 완전히 확신 할 수는 없습니다 .

그러나 조직이 DevOps 문화 및 인프라를 구축하기 전에 민첩한 프로세스를 채택 할 필요가 없음을 분명히하는 것이 매우 중요하다고 생각합니다. 실제로 회사에서 기본 DevOps를 사용하고 있다면 Agile을 채택하는 것이 실제로 더 쉽다고 주장합니다. Agile은 DevOps의 전제 조건이 아니라 민첩한 구현을 개선하는 데 도움이되도록 DevOps를 사용하는 것이 좋습니다.

Andrew Agile 2008 컨퍼런스에서 Andrew Clay Shafer와 Patrick Debois 는 "Agile Infrastructure"에 대해 논의했습니다 . 이것이 DevOps 운동의 시작이었습니다.

그러나 DevOps는 Agile Manifesto에 뿌리를두고 있지만 개발 팀이 Agile이어야하는 것은 아닙니다. 대부분의 애자일 원칙 을 따르는 것이 중요하지만 구체적인 애자일 방법론 은 규정되어 있지 않으며 개발 팀이 자신의 업무 방식을 생각 해낼 수 있다면 애자일 원칙을 어느 정도 유지하면서 이점을 실현할 수 있습니다.

반드시 그런 것은 아닙니다. 다른 답변에서 언급했듯이 애자일 방법론과 DevOps 사고 방식은 서로를 구축 할 수 있지만 DevOps는 민첩하거나 마른 개발 노력보다 광범위합니다. DevOps를 채택한 회사는 운영, 개발, 제품 설계, 마케팅, 보안 등을 포함한 전체 가치 흐름을 살펴보고 있습니다. 장벽을 해체하려는 의도로 모든 사일로 내에서 운동이 시작될 수 있습니다.

이럴 그것은하지 않습니다 필요 합니다.

에서 개발 운영 (강조 광산) :

DevOps ( "소프트웨어 개발"및 "정보 기술 OPerationS"의 잘린 조합)는 프로세스를 자동화하면서 소프트웨어 개발자와 IT (IT) 전문가의 협업 및 커뮤니케이션을 강조하는 일련의 사례를 지칭하는 용어입니다. 소프트웨어 제공 및 인프라 변경. 1 [2] 소프트웨어의 구축, 테스트 및 출시가 신속하고 빈번하며보다 안정적으로 이루어질 수 있는 문화와 환경을 구축하는 것을 목표로 합니다.

나는 can happen그것이 아닌 것으로 강조 했다 must happen.

위의 설명에서 실제로 민첩한 개발 방법론이 필요 하지 않습니다 .

그러나 필자는 종종 DevOps 로의 전환이 개발 프로세스에서 서로 잘 맞도록 민첩한 방법론을 삽입하는 경우가 종종 있다고 생각합니다.

Devops의 개념은 민첩한 확산으로 인해 정확하게 발생했기 때문에 민첩한 방식으로 Devops 접근 방식을 사용하는 것이 적절합니다. 예를 들어, 민첩하고 지속적인 통합 (개발자 접근 방식의 일부), 테스트 및 제품 환경을위한 새로운 릴리스 테스트 및 롤아웃을위한 서비스 및 컨테이너 오케스트레이션이 사용됩니다.