하나의 큰 릴리스 또는 몇 개의 작은 릴리스?

Question

기존 비즈니스 애플리케이션 라인에 대한 향상을 위해 노력할 때 변경 사항을 덜 빈번한 더 큰 릴리스로 배치하거나 소규모 릴리스에서 새로운 기능을 지속적으로 배송하는 것이 더 낫다고 생각하십니까? 하드웨어 업그레이드 또는 데이터베이스 업그레이드가 있다고 가정하면 릴리스와 함께 이러한 변경을 수행하거나 별도로 유지합니까?

모든 것을 함께 출시하면 비즈니스에 대한 혼란이 적고 시간이 줄어든 작업이 적용되었다는 이점이 있지만 나중에 발생하는 문제는 데이터베이스 업그레이드, 하드웨어 또는 여러 소프트웨어 변경으로 인한 문제가 될 수 있습니다.

거의 출시되면 종종 릴리스로 인한 문제를 쉽게 추적 할 수 있지만 더 많은 혼란과 회귀 테스트를 더 많이 사용합니다.

어떤게 더 좋아?

Answer 1

각 릴리스가 고객에게 어떤 영향을 미치는지 고려하십시오. 자주 소규모 릴리스가 중요한 문제를 더 빨리 해결하기 때문에 더 행복해 집니까? 이것이 당신의 판매와 평판을 향상시킬까요? 이러한 혜택이 추가 작업을 수행하지 않았는지 신중하게 추정 할 경우, 그렇지 않으면 더 편리한 경로를 따르십시오.

Answer 2

그것은 실제로 당신의 환경에 달려 있습니다. 일부 시나리오 :

많은 고객: 모든 고객이 가능한 한 동일한 릴리스를 갖기를 원합니다. 테스트 및 롤아웃 조정이 매우 비용이 많이 드리기 때문에 ANUAL, SEMIANUAL 또는 COXTLY BIG 릴리스를 갖는 것이 훨씬 쉽습니다. 이 경우 DB 변경 사항도 포함합니다.

"큰 인프라": 운영 체제 및 데이터베이스를 위해 전용 인원이있는 대기업 환경에서 일하는 경우, 릴리스의 전체 비용이 크기 때문에 더 큰 릴리스가 덜 빈번합니다.

간단히 말해서, Man Power, Business Interuption, Coordination, Testing에서 릴리스 비용을 계산하여 각 새로운 기능 또는 버그 수정의 이점과 관련하여이를 가져옵니다.

나는 보통 1 년에 1-2 개의 큰 릴리스가 있고 쇼 스토퍼를위한 버그 수정을하는 경향이 있습니다.

Answer 3

가장 좋은 대답은 다음과 같습니다. 둘의 혼합.

예를 들어, 눈 사탕을 추가했거나 텍스트 상자 이름을 "Ajaxy"라는 이름으로 만들었거나 새로운 유형의 보고서를 던졌을 때 "작은"릴리스로 만들 수 있습니다. 가능한 한 조기에 출시되고 자주 출시됩니다.

반면, 사용자를 대상으로 한 사용자를 대상으로 한 사용자를 대상으로 한 경우 사용자를 "재교육"으로 변경하거나 대규모 인프라 변경이 필요하다면 큰 릴리스로 이동하여 가능한 한 거의 릴리스되지 않습니다.

당신이 말했듯이, 혼란이 거의 없거나 전혀 없다면 가능한 한 자주 해보면 사용자가 더 행복해질 것입니다. 실제로 변경 사항에 연결된 모든 것을 테스트하면되므로 회귀 테스트에 시간이 줄어 듭니다. 당신이 만든.

Answer 4

나는 당신이 라인 아래로 문제를 해결해야하기 때문에 그것을 하나의 큰 릴리스로 만들고 패치하는 것이 더 낫다고 생각합니다.

개발자로서 가능한 한 강력한 문제를 예상하고 시스템의 문제를 예상해야합니다. 그것은 일반적으로 미리 많은 테스트를 의미합니다.

또한 최종 사용자는 제품의 더 작은 증분 비용을 지불하고 싶지 않으며 큰 업데이트를 기다릴 수도 있습니다. 이에 대한 좋은 예는 내가 Adobe Photoshop을 얻었을 때 매년 새 버전을 출시하는 것처럼 보이므로 시간이 옳은 것처럼 보일 때까지 기다렸습니다.

Answer 5

더 적은 수의 릴리스는 한 번에 모든 버그를 찾을 수 있음을 의미합니다. 어떤 코드 변경으로 인해 어떤 버그가 발생했는지 알기가 더 어려워집니다. 그런 다음 계단식 버그와 관련하여 더 많은 문제가 있습니다. 몇 달 전에 만든 코드 변경으로 인해 버그가 발생했지만 그 동안 몇 달 전에 소개 한 버그에 따라 다섯 번의 변경 사항이있었습니다.

더 작고 고품질의 릴리스가 더 좋습니다. 더 작은 릴리스는 고품질을 쉽게 가질 수있게합니다.

Answer 6

개인적으로, 나는 큰 릴리스를 선호합니다.

나는 집에 일주일에 여러 번 업데이트를 제공하는 소프트웨어가 있습니다. 자동 업데이트 기능이없고 계속 돌아 오는 알림 만 있으므로 성가신 일입니다.

이와 유사한 질문을 살펴보고 싶을 수도 있습니다. 소프트웨어 업데이트를 얼마나 자주 출시해야합니까?

Answer 7

사실 - 둘 다.
개발을 개발 및 릴리스 브랜치로 분할 할 수 있습니까? Rel Branch에서 최대한 빨리 문제가 발생하여 사용자에게 핫픽스로 보내야합니다. Rel Branch에 Hotfix를 적용하면 패치를 적용해야 할 필요성이 Dev Team에 전송됩니다 (참고 : REL에서 일부 문제를 해결하려면 약간의 빠른 코드를 작성해야하며 Dev Branch에서는 제안 된 수정 사항을 다시 생각하는 데 시간을 내야합니다. , Dev Branch의 조건이 변경되었을 수 있으므로 Dev 또는 Rel Branch에서 동일한 문제를 해결하기 위해 완전히 다른 코드를 작성하는 것이 일반적입니다).
새로운 버전의 개발이 완료되면 Rel에서 마이그레이션 된 새로운 기능과 패치를 테스트해야합니다. 모든 것이 정상이라면 새로운 Big Big 버전을 배포하고 현재 Dev를 REL으로 보관할 수 있으며 Old Rel은 이제 봉인됩니다.