리팩토링과 병합 필요성 사이의 긴장을 어떻게 처리합니까?

Question

새 버전을 제공할 때 우리의 정책은 VCS에 브랜치를 생성하고 이를 QA 팀에 처리하는 것입니다.후자가 승인을 받으면 제품에 태그를 지정하고 출시합니다.브랜치는 기술 릴리스를 생성할 수 있도록 버그 수정만 수신하도록 유지됩니다.해당 버그 수정 사항은 이후 트렁크에 병합됩니다.

이 시간 동안 트렁크는 주요 개발 작업을 확인하며 잠재적으로 리팩토링 변경 사항이 적용될 수 있습니다.

문제는 안정적인 트렁크가 있어야 한다는 것 사이에 긴장이 있다는 것입니다(버그 수정 병합이 성공하려면). 코드가 다음과 같은 경우에는 일반적으로 불가능합니다.다른 메소드로 추출하거나 다른 클래스로 이동) 및 새로운 기능을 도입할 때 리팩터링해야 할 필요성.

우리의 정책은 충분한 시간이 지나고 지점이 충분히 안정되기 전에는 리팩토링을 수행하지 않는 것입니다.이 경우 트렁크에서 변경 사항 리팩토링을 시작할 수 있으며 버그 수정은 트렁크와 브랜치 모두에서 수동으로 커밋됩니다.

그러나 이는 개발자가 리팩토링 변경 사항을 트렁크에 커밋하기 전에 상당한 시간을 기다려야 함을 의미합니다. 이로 인해 브랜치에서 트렁크로의 후속 병합이 중단될 수 있기 때문입니다.그리고 브랜치에서 트렁크로 버그를 수동으로 포팅해야 하는 것은 고통스럽습니다.아무래도 개발에 지장을 주는 것 같더라구요...

이 긴장감을 어떻게 처리하나요?

감사해요.

Answer 1

이것은 실질적인 문제입니다. 지원 해야하는 몇 가지 버전이 있으면 각각에 대해 분기 된 경우 악화됩니다. 진정한 R & D 지점이 있다면 여전히 더 나쁩니다.

저의 선호는 메인 트렁크가 정상적인 속도로 진행할 수있게하고 방출 시간이 상업적으로 중요한 환경에서는 코드가 안정화되어야한다고 주장 할 수 없었기 때문에 ( "무엇을 의미 하는가, 당신은 당신이 의미합니다. 불안정한 상태로 릴리스? ").

핵심은 버그가 메인 브랜치로 마이그레이션 될 때 버그 수정을 위해 생성 된 장치 테스트가 전환되었는지 확인하는 것이 었습니다. 새 코드 변경이 진정으로 다시 요점 인 경우 기존 테스트는 똑같이 잘 작동해야합니다. 변경 사항이 더 이상 유효하지 않도록 변경되면 어떤 경우에도 수정 할 수 없으며 새 코드 스트림의 수정에 대해 다른 사람을 생각해야합니다.

이런 종류의 문제를 꽤 많이 관리 한 후에는 적절한 지원과 범위를 제공하기 위해 최소 4 개의 코드 스트림이 필요하며 코드를 통한 코드를 관리하기 위해 매우 엄격한 프로세스 모음이 필요하다고 결론을 내 렸습니다. 그것은 4 가지 색상으로 맵을 그릴 수있는 문제와 비슷합니다.

나는이 주제에 대한 정말 좋은 문헌을 찾지 못했습니다. 필연적으로 릴리스 전략 및 고객과 서명하는 SLA에 연결됩니다.

부록 : 또한 지점의 릴리스 일정에 특정 이정표로 지점 합병을 작성해야한다고 언급해야합니다. 작업을 구현하는 기능을 수행하는 열심히 일하는 개발자 모음이 있다면 지점을 모으는 데 수반되는 작업의 양을 과소 평가하지 마십시오.

Answer 2

내가 일하는 경우, 우리는 사소한 변화 (기능 추가 또는 버그 픽스)마다 일시적이고 짧은 수명 (하루 미만-몇 주 미만) 작업 지점을 만듭니다. 트렁크는 안정적이며 (이상적으로) 잠재적으로 방출 가능합니다. 뿐 완료 항목이 병합됩니다. 트렁크에서 저지른 모든 것이 매일 작업 지점으로 합병됩니다. 이것은 대부분 자동화 될 수 있습니다 (우리는 Hudson, Ant 및 Subversion을 사용합니다). (이 마지막 요점은 일반적으로 나중에 나중에 갈등을 해결하는 것이 더 낫기 때문입니다.)

우리가 사용하는 현재 모델은 훌륭한 기사의 영향을 받았습니다.내가 전에 꽂았습니다) by Henrik Kniberg : 여러 애자일 팀을위한 버전 제어.

(우리의 경우, 우리는 하나의 코드베이스에서 작업하는 두 개의 스크럼 팀이 있지만,이 모델이 한 팀에서도 유익 할 수 있다고 생각하게되었습니다.)

여분 svn merge --reintegrate 편리합니다). 그리고 아니요, 나는 임시 분기를 항상 만들지 않습니다. 예를 들어, 트렁크에 대한 커밋으로 쉽게 완성 할 수있는 더 작고 위험이 낮은 리팩토링 (현재 직장중인 주요 품목과 관련이 없음)을위한 것입니다.

우리는 또한 중요한 버그가 수시로 고정되는 오래된 릴리스 브랜치를 유지합니다. 물론, 코드의 특정 부분이 지점에 비해 트렁크에서 크게 진화 한 경우 수동 (때로는 지루한) 병합 작업이있을 수 있습니다. (트렁크 (내부)에서 지속적으로 증분을 출시하고 마케팅 및 제품 관리가 외부 릴리스를 수행 할시기를 결정하게하면서 희망적으로 문제가되지 않습니다.)

이것이 귀하의 질문에 직접 답변하는지 또는 귀하가 귀하의 환경에 적용 할 수 있는지 확실하지 않습니다 (별도의 QA 팀과 함께). 그러나 적어도 당신이 묘사하는 긴장은 우리에게 존재하지 않으며 우리는 언제든지 리팩터를 재현 할 수 있습니다. 행운을 빕니다!

Answer 3

개발 프로세스에 다음 요소를 추가하면 긴장감을 조절할 수 있다고 생각합니다.

1. 지속적인 통합
2. 자동화된 기능 테스트(이미 단위 테스트를 포함하고 있다고 가정합니다)
3. 자동 배송

지속적인 통합을 통해 모든 커밋은 모든 단위 테스트가 실행되는 빌드를 의미하며 문제가 발생할 경우 경고를 받습니다.head로 더 많은 작업을 시작하면 코드 기반을 분기하는 경향이 줄어듭니다.

자동화된 기능 테스트를 통해 버튼 클릭만으로 애플리케이션을 테스트할 수 있습니다.일반적으로 이러한 테스트는 시간이 더 걸리기 때문에 야간에 실행됩니다.이로 인해 버전 관리의 고전적인 역할이 중요성을 잃기 시작합니다.버전과 성숙도에 따라 출시 시기를 결정하는 것이 아니라 비즈니스 결정에 더 가깝습니다.단위 및 기능 테스트를 구현했고 팀에서 테스트된 코드를 제출하는 경우 헤드는 항상 릴리스 가능한 상태여야 합니다.버그는 지속적으로 발견되고 수정되며 릴리스가 제공되지만 이는 더 이상 순환 프로세스가 아니라 지속적인 프로세스입니다.

아마도 두 가지 유형의 비방자가 있을 것입니다. 이는 오랫동안 뿌리를 내린 관행을 바꾸는 것을 의미하기 때문입니다.첫째, 지속적인 전달의 패러다임 변화는 관리자에게 직관에 반하는 것처럼 보입니다."우리는 주요 버그를 배송 할 위험이 없습니까?" Linux 또는 Windows 배포판을 살펴보면 이것이 바로 그들이하는 일입니다.고객에게 릴리스를 추진합니다.그리고 자동화된 테스트 제품군을 사용하므로 위험이 더욱 줄어듭니다.

다음은 QA팀 또는 부서입니다.(어떤 사람들은 문제가 그 존재 자체에 있다고 주장합니다!) 그들은 일반적으로 테스트 자동화를 싫어할 것입니다.이는 새롭고 때로는 복잡한 도구를 배우는 것을 의미합니다.여기서 가장 좋은 것은 행함으로써 설교하는 것입니다.우리 개발팀은 지속적인 통합 작업을 시작했으며 동시에 기능 테스트 제품군을 작성하기 시작했습니다. 셀렌.QA팀은 도구가 실제로 작동하는 것을 보고 구현에 반대하기가 어려웠습니다.

마지막으로, 제가 설명한 프로세스는 개발 프로세스에 3가지 요소를 추가하는 것만큼 간단하지 않습니다.이는 소프트웨어 개발 방식에 큰 변화가 있음을 의미합니다.

Answer 4

어쩌면 git (또는 다른 DVC)이 파일을 비교하는 것보다 (실제로) 변경을 관리한다는 사실 덕분에 업데이트 된 코드와 합병하는 데 더 나은 것일 수 있습니다. 조엘은 말한다 :

분산 버전 제어를 사용하면 합병이 쉽고 잘 작동합니다. 따라서 실제로 안정적인 지점과 개발 지점을 갖거나 배치 전에 물건을 테스트하는 QA 팀을위한 오래 지속 된 지점을 만들거나 새로운 아이디어를 시도하고 어떻게 작동하는지 확인할 수 있습니다.

그래도 아직 시도하지 않았습니다 ...

Answer 5

내가 일하는 곳에서, 우리는 메인 브랜치의 리팩토링을 유지합니다. 합병이 까다로워지면, 그들은 단지 임시로 다루어야한다면, 그들은 모두 할 수 있지만 때로는 약간의 시간이 걸립니다.

Answer 6

어쩌면 우리의 문제는 우리에게는 꽤 긴 수명 (최대 18 개월)이 있어야하는 지점이 있다는 사실에서 비롯 될 수 있으며, 그들에 대해해야 할 많은 수정 사항이 있습니다.

우리가 극도로 안정적인 코드에서만 분기되도록하는지 확인하면 아마도 도움이 될 수 있지만 그렇게 쉽지는 않을 것입니다 ... :(