기존 업무용 응용 프로그램의 향상된 기능을 개발할 때 자주 사용하지 않는 버전으로 변경 사항을 일괄 처리하거나 소규모 릴리스에서 새 기능을 지속적으로 제공하는 것이 더 좋다고 생각하십니까? 하드웨어 업그레이드 또는 데이터베이스 업그레이드가 있다고 가정하면 릴리스에서도 이러한 변경을 수행합니까, 아니면 별도로 유지 하시겠습니까?하나의 큰 릴리스 또는 몇 가지 작은 것들?
모든 것을 함께 릴리스하면 비즈니스 중단 시간이 줄어들고 작업 시간이 단축되지만 나중에 발생할 수있는 문제는 데이터베이스 업그레이드, 하드웨어 또는 여러 가지 소프트웨어 변경으로 인한 것일 수 있다는 이점이 있습니다.
릴리스 중 발생하는 모든 문제를 추적하기가 쉽지만 종종 중단 및 회귀 테스트에 더 많은 시간이 소요됩니다.
어느 것이 더 낫습니까?
각 릴리스가 고객에게 미치는 영향을 고려하십시오. 중요한 문제를 더 빨리 해결할 수 있기 때문에 소량의 출시로 인해 더 행복해질 수 있습니까? 이것이 판매 및 평판을 향상시킬 것입니까? 이러한 혜택이 과도한 추가 작업을 초과하는지 여부를 신중하게 예측한다면 그렇지 않으면보다 편리한 경로를 따라야합니다.
개인적으로 나는 큰 릴리스를 선호합니다.
나는 일주일에 여러 번 업데이트를 제공하는 집에서 소프트웨어를 가지고 있습니다. 자동 업데이트 기능이 없기 때문에 성가시다. 계속 알림이 돌아와야한다.
당신이 비슷한 질문을 살펴 걸릴 수도 있습니다나는 그것의 더 나은 하나 개의 큰 버전으로 작업하고 선 아래로 문제를 해결해야하기 때문에 패치 생각합니다.
개발자는 가능한 한 강력한 문제를 만들기 위해 가능한 문제를 예측하고 시스템을 중단해야합니다. 그것은 대개 사전에 많은 테스트를 의미합니다.
또한 최종 사용자가 제품에서 더 작은 증분을 지불하고 싶지 않을 수도 있으며 큰 업데이트를 기다릴 수도 있습니다. 이것의 좋은 예는 내가 어도비 포토샵을 받았을 때, 그들은 그 시간이 정말 환경에의 의존 바로
같았다 때까지 매년 그래서 단순히 기다렸다 새 버전을 출시 할 것입니다 일부 시나리오 :.
많은 고객 : 가능한 한 모든 고객이 동일한 릴리스를 갖기를 원합니다. 테스팅 및 롤아웃 조정은 비용이 많이 들기 때문에, 연극, 세미 또는 분기 별 대규모 릴리스를 갖는 것이 훨씬 쉽습니다. 이 경우 DB 변경도 포함됩니다.
"큰 인프라" : 운영 체제 및 데이터베이스 전용 담당자가있는 대기업 환경에서 작업하는 경우 다시 릴리스의 전체 비용이 크기 때문에 더 큰 릴리스의 빈도가 적습니다.
간단히 말해, 인력, 비즈니스 중단, 조정, 테스트에서 릴리스 비용을 계산하고 각각의 새로운 기능 또는 버그 수정의 이점과 관련시켜야합니다.
저는 보통 1 년에 1-2 번의 대규모 릴리스가 발생하고 쇼 스토퍼에 버그가 수정됩니다.
더 적은 수의 릴리스가 있으면 모든 버그를 한꺼번에 발견 할 수 있습니다. 어떤 코드 변경으로 인해 어떤 버그가 발생했는지 알기가 더 어려워집니다. 그런 다음 계단식 버그에 대한 문제가 더 많습니다. 한 달 전에 한 번 코드를 변경하면 버그가 발생하지만, 그 전에는 몇 달 전에 도입 한 버그에 따라 다른 다섯 가지 변경 사항을 적용했습니다.
품질이 더 작고 품질이 더 우수합니다. 릴리즈가 작을수록 고품질을 쉽게 얻을 수 있습니다.
이는 불행히도 일반적인 경우 최종 고객이 테스트를 수행하는 경우에 해당됩니다. 다행히도이 방법으로 개발 된 항공기는 없습니다. –
사실 - 둘 다.
DEVEL 및 RELEASE 분기로 개발을 분할 할 수 있습니까? 긴급한 문제는 REL 분기에 최대한 빨리 처리하여 핫픽스로 사용자에게 전송해야합니다. REL 브랜치에 핫픽스를 적용한 후 패치를 적용 할 필요가 DEV 팀에게 전달됩니다 (참고 : REL의 일부 문제를 해결하려면 빠른 코드를 작성해야하지만 DEV 브랜치에서는 제안 된 수정 사항을 다시 생각해 볼 시간이 필요합니다) DEV 브랜치의 조건이 변경되었을 수 있으므로 DEV 또는 REL 브랜치에서 동일한 문제를 수정하기 위해 완전히 다른 코드를 작성하는 것이 일반적입니다.
새로운 버전의 개발이 완료되면 REL로부터 마이그레이션 된 새로운 기능과 패치를 테스트해야합니다. 모든 것이 정상이라면 새로운 큰 버전을 배포하고 현재 DEV를 REL에 보관할 수 있으며 오래된 REL은 봉쇄됩니다.
나는 가장 좋은 대답은 다음과 같다고 생각합니다.
예를 들어 아이 캔디를 추가하거나 이름 텍스트 상자를 "ajaxy"로 만들거나 새로운 유형의 보고서를 던진 경우 "작은"릴리스로 만듭니다. 가능한 한 빨리 릴리스하고 자주 발표하십시오.
한편 사용자가 "재교육을 받도록"강제하는 사용자 대면 프로세스를 변경하거나 대규모 인프라 변경이 필요한 경우 - 큰 릴리스의 경우 가능한 한 최소화하십시오.
당신이 말했듯이, 거의 없거나 전혀 중단이 없다면 사용자는 더 행복 할 것입니다. 그리고 모든 것을 테스트해야하기 때문에 회귀 테스트에 더 많은 시간을 보내고 있습니다. 변경 사항과 연결됩니다.
@Lieven : 자동 업데이트를 만들면 문제가 해결 될 것입니다. 릴리즈가 적어 질 것입니다. –
@ John Saunder : 내가 듣는다. 보안 수정을위한 자동 업데이트, 새로운 기능의 수동 업데이트를 선호한다고 말하면서 다시 말씀 드리겠습니다. 수동 업데이트 (알림)의 빈도는 1 주 이상이어야합니다. –