Waterfall과 Agile의 차이점을 설명하는 데 도움이되는 릴리스 관리 측면은 무엇입니까?


12

누군가에게 DevOps를 설명 할 때 다음과 같은 질문이 나타납니다.

애자일 방법론을 사용한 릴리스 관리는 Waterfall과 어떻게 다릅니 까?

그렇다면 이러한 차이를 이러한 청중에게 설명하기 위해 어떤 종류의 기준을 사용할 수 있습니까?

답변:


11

IMO DevOps는 민첩한 방법론을 선택하지 않고 Agile과 매우 유사한 문화입니다. 따라서 DevOps를 "하지"마십시오.

DevOps Culture의 일부로 Continuous Delivery라는 릴리스 방법을 "수행"합니다. (전체 공개, 나는 CD를 이전에 릴리스 방법론이라고 언급 한 적이 없다고 생각하지만, 제압 상태에서는 작동한다고 생각합니다)

만약 당신이 그것을 사면, 다음은 같은 제목으로 책을 쓴 사람들 중 하나 인 Jez Humble 에서 Continuous Delivery의 정의입니다 .

Continuous Delivery는 새로운 기능, 구성 변경, 버그 수정 및 실험을 포함한 모든 유형의 변경 사항을 프로덕션으로 또는 사용자의 손에 안전하고 빠르게 지속 가능한 방식으로 가져올 수있는 기능입니다.

우리의 목표는 대규모 분산 시스템, 복잡한 프로덕션 환경, 임베디드 시스템 또는 앱 등 배포시 필요할 때 수행 할 수있는 일상적인 업무를 배포하는 것입니다.

우리는 매일 수천 명의 개발자 팀이 직면하더라도 코드를 항상 배포 가능한 상태로 유지함으로써이 모든 것을 달성합니다. 따라서 코드 동결뿐만 아니라 전통적으로 "dev complete"를 따르는 통합, 테스트 및 강화 단계를 완전히 제거합니다.

따라서 애자일 방법론을 통해 비즈니스에 입증 할 수있는 소프트웨어를 보유하고 적절한 자동화 된 테스트를 수행하고 변경 사항과 폭포수보다 더 나은 모든 사항을 적절히 대응할 수 있습니다. 그렇다고해서 실제로 프로덕션 환경에 배포 할 수 있는 것은 아닙니다 .

다음과 같이 끝납니다. CD가없는 민첩

따라서 반복적 인 접근 방식이 없다면 실제 사용자가 본 적이 없기 때문에 소프트웨어를 사용하는 것이 더 나을 것입니다.

정말로 원하는 것은 다음과 같이 보입니다.

여기에 이미지 설명을 입력하십시오

반복 할 때마다 무언가가 프로덕션에 배포됩니다. 따라서 소프트웨어가 배포 됩니다. 당신이 다운로드를 만들 웹 서버를 열거 나하기로 결정하는 경우 그러나 당신은 그것의 사용자의 손에 소프트웨어를 얻을 발표 .

이런 젠장!? 나는 DevOps에 대해 물었다! 아무도 Continuous Delivery에 대해 물었습니다!

그렇다면 DevOps는 이것과 어떤 관련이 있습니까?

팀이 DevOps 문화에서 일하지 않는 한 원하는 때에 소프트웨어를 배포 할 수있는 상태로 소프트웨어를 구축하는 것은 매우 어렵습니다 (불가능한 접근). 시스템 관리자, DBA, SRE, 보안 담당자, 개발자, QA 등이 모두 단일 팀의 일부이며 핸드 오프가있는 조직의 일부가 아닌 문화.

참고 :

이 답변에 게시 된 의견의 일부에 대해 다음과 같습니다.

(비행기에서) "자동 파일럿"소프트웨어에 대해 생각 나게 ... 그것에 대해 내가 가장 좋아하는 질문 : 당신의 "당신이 원하는 때마다 배포 할 수있는 상태에서 ... 소프트웨어 ..."정보 " 업데이 트를 상상해 기내에있는 동안 이러한 소프트웨어에 적용되는 ... 어떻게 ... 기내 있도록하는 것에 대해 느낄 것? ".

나는 그 질문을 좋아한다 (위 인용문에서 굵게 표시)! "정말 준비 되었습니까?"라는 아이디어 내가 항상 블로그 에 대해 욕구가있다 . IMO CD를 연습하려면 보안, 성능 및 기타 "보조"테스트에 대해 확신을 갖고 있어야합니다. 기능이 완료되면 완료되지만 해커는 항상 있습니다.


흥미로운 견해 / 답변 및 반짝이는 이미지에 감사드립니다. 나는 용어 릴리스에 대해 들어 본 적이 인정해야 방법론 출시하지만, 관리는 내가 꽤 잘 알고 무엇인가 (2 년 이상 ...). "... 제목"과 함께 "원하는 때마다 배포 할 수있는 상태의 소프트웨어 ..."정보 (비행기에서) "자동 파일럿"소프트웨어에 대해 상기시켜줍니다 ... " 그런 소프트웨어에 업데이트가 적용 되었다고 상상해보십시오. 기내에서하는 동안 기분이 어떻습니까? ".
Pierre.Vriens

1
나는 그 질문을 좋아한다! "정말 준비 되었습니까?"라는 아이디어 내가 항상 블로그 에 대해 욕구가있다 . IMO CD를 연습하려면 보안, 성능 및 기타 "보조"테스트에 대해 확신을 갖고 있어야합니다. 기능이 완료되면 완료되지만 해커는 항상 있습니다.
Ken Mugrage

1
"이러한 소프트웨어에 업데이트가 적용되었다고 상상해보십시오. 기내에서하는 동안 기분이 어떻습니까?"
Ken Mugrage

그리고 제발 편집하십시오, 나는 여기에 n00b입니다 :)
Ken Mugrage

흥미로운 의견을 통합하기 위해 제안 된 편집 내용을 검토하십시오. 마음에 들지 않으면 이전 버전으로의 롤백을 수행하고 (링크는 "개정"내에 있음) 원하는대로 추가로 개선 / 확장하십시오. 내 "권한"중 일부가 "인플 라이트"된 것으로 보입니다 ... 이러한 제안 편집을 위해 여전히 "승인"이 필요하기 때문에 이미 너무 많은 담당자가있는 것처럼 보입니다 ... 행운은 우리가 단지 일부 SE- 소프트웨어 (항공 교통 관제의 사전 승인없이 일부 노선 노선에 대해 제안 된 업데이트가 아님). Oeps 2 (수정) : 광속에서 승인되었습니다 ...
Pierre.Vriens

2

다른 것이 없는지 확실하지 않지만 다음은 내가 사용하는 기준입니다.

+-------------------+-----------+-----------+
! Criteria          ! Agile     ! Waterfall !
+-------------------+-----------+-----------+
! Release Events    ! Frequent  ! Rare      !
! Risk              ! Less      ! High      !
! Required Effort   ! Smoother  ! Peaks     !
! Volume of changes ! Small     ! Huge      !
+-------------------+-----------+-----------+

그리고 실제로 일부 소프트웨어의 사용자로서 차이를 경험하고 싶다면 Linux 배포판과 같은 일부 소프트웨어를 사용하여 해당 릴리스 중 하나를 사용할 수 있습니다.

  • " Rolling"릴리스 (==> 애자일).

  • " Long Term Support"릴리스 (==> 폭포).


1
리눅스의 예는 수도 매우 영감을하지 :) 개인적으로 나는이 때문에 롤링 릴리스 싫어하는 : 1. 품질 수준과 2. 오히려 산만 변경 (필자는 리눅스에 I가 사용하고 있지, 내 작품에 초점을 선호하는 내 작업). 그래서 나는 가장 긴 용어를 사용하고 (종종 EOL을 지나쳐) 2-3 년마다 한 번만 주요 업데이트에만 집중합니다. 노화로 인해 변화에 대한 광고가 증가하지 않는 한? :)
Dan Cornilescu

@DanCornilescu이 리눅스 예제는 두 가지 방법론 모두에 대한 "a"릴리스 관리 측면 (즉, 릴리스 빈도)의 극단적 인 예라고 생각하기 때문에이 Linux 예제를 사용했습니다. "개인적으로"비록 당신이 언급 한 것과 같은 이유로 롤링 릴리스를 싫어하는 것에 전적으로 동의합니다.
Pierre.Vriens
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.