지속적인 통합을 수행 할 때 코드 검토는 언제해야합니까?

지속적인 통합 환경으로 전환하려고하지만 언제 코드 검토를 수행해야할지 확실하지 않습니다. 지속적인 통합에 대해 읽은 내용에서 하루에 여러 번 코드를 체크인하려고 시도해야합니다. 나는 이것이 아직 완성되지 않은 기능을 의미한다고 가정합니다.

문제는 언제 코드 검토를합니까?

코드를 체크인하기 전에는 할 수 없습니다. 하루에 여러 번 체크인하지 않아도 매일 체크인을 할 수없는 프로세스가 느려지기 때문입니다.

또한 우리가 체크인하는 코드가 단순히 컴파일 만되었지만 기능이 완료되지 않은 경우, 코드 검토는 기능이 완성 될 때 대부분의 코드 검토가 가장 잘 이루어 지므로 무의미합니다. 이는 기능이 완료 될 때 코드 검토를 수행해야하지만 검토되지 않은 코드가 리포지토리에 들어가는 것을 의미합니까?

IMO는 메인 라인에 코드가 게시되기 전에 코드를 검토하여 메인 라인에 최고 품질의 코드 만 포함되도록해야합니다.

OTOH는 'CI 테스트 자동화가 실행되지 않은 경우 검토를 귀찮게하는 이유는 무엇입니까?'라는 좋은 지적을 할 수 있으므로 개발자에게 각각 CI 서버가 구축하고 테스트 할 개인 브랜치를 제공하는 것이 가장 좋습니다. . 그런 식으로 그들은 먼저 커밋하고 푸시 한 다음 통과되면 검토 한 다음 메인 라인으로 병합합니다 (CI 서버를 통해 다른 실행을 얻습니다).

기능이 완성되지 않은 코드를 반드시 검토하여 향후 기능에 대한 스캐 폴딩이 존재하는지 또는 적어도 미래 기능을 구현할 수있는 항목이 없는지 확인해야합니다.

또한 코드 검토가 느리거나 동기적일 필요는 없습니다. gerrit 또는 reviewboard와 같은 도구는 비동기적이고 상당히 고통스럽지 않을 수 있습니다.

(전체 공개 : 코드 검토 도구 인 Code Collaborator의 제조업체 인 SmartBear에서 근무했습니다.)

페어 프로그래밍을 설정 하시겠습니까?

프로세스를 확장하거나 다른 단계를 도입하지 않고 입력 할 때 모든 코드가 검토됩니다.

연속 전달 저자의 발췌 내용은 다음과 같습니다.

Jez Humble은 다음과 같이 씁니다.

현재이 주제에 대한 블로그 게시물을 작성 중입니다. 짧은 대답은 다음과 같습니다.

• 코드를 검토하는 가장 좋은 방법은 페어 프로그래밍을 이용하는 것입니다
• 공식적인 검토 프로세스에서 별도의 브랜치를 생성하여 메인 라인으로 병합하는 것은 좋지 않습니다. 이를 통해 지속적인 통합 (불량한 변경의 위험을 줄이는 가장 좋은 방법)을 막을 수 있습니다. 이는 실제로 달성하려는 목표입니다.
• Gerrit는 훌륭한 도구라고 생각하지만 체크인 후에 사용해야합니다 (실제로 디자인 된 방식입니다). 선임 개발자의 역할 중 일부는 모든 체크인을 검토하는 것입니다. 예를 들어 피드를 구독 할 수 있습니다.

요약하면 : 코드 검토가 좋습니다. 페어 프로그래밍과 커밋 검토를 통해 지속적으로해야합니다. 선임 개발자가 잘못된 커밋을 발견하면 커밋 한 사람과 쌍을 이루어 문제를 해결하도록 도와야합니다.

공식 검토에서 병합을 메인 라인으로 게이팅하는 것은 좋지 않으며, 그렇게하는 지점을 만드는 것은 피처 지점이 나쁜 것과 같은 이유로 매우 나쁩니다.

감사,

이즈

원래 링크는 https://groups.google.com/forum/#!msg/continuousdelivery/LIJ1nva9Oas/y3sAaMtibGAJ

그것이 최선의 방법인지는 모르겠지만 ... 어떻게하는지 설명하겠습니다. 한 명 이상의 개발자가 특정 브랜치에서 작업하고 다른 방법으로는 발생하지 않은 병합 시간 낭비를 피하기 위해 가능한 한 자주 코드를 커밋합니다. 코드가 준비되었을 때만 코드가 커밋됩니다. 이제 커밋과 브랜치 / 헤드를위한 것입니다.

코드 검토는 Sonar 를 지속적인 통합 도구 (Sonar와 상호 작용하기위한 Maven / Jenkins)로 사용하여 매일 아침마다 새로운 테스트 결과, 코드 적용 범위 및 자동 코드 검토 (빌딩은 매일 밤 수행)를 제공합니다. 개발자는 매일 아침 최대 1 시간 동안 문제 / 코드 냄새를 해결할 수 있습니다. 각 개발자는 자신이 작성하고있는 기능에 대해 책임을집니다 (자부심이 있습니다!). 이제는 자동 코드 검토로 잠재적 인 기술적 / 건축 적 문제를 발견하는 것이 좋지만, 더 중요한 것은 이러한 새로운 구현 기능이 비즈니스가 원하는 것을 제대로 수행하고 있는지 테스트하는 것입니다.

이를 위해 통합 테스트와 피어 코드 검토라는 두 가지가 있습니다. 통합 테스트는 새 코드가 기존 코드를 손상시키지 않는다는 것을 확신하는 데 도움이됩니다. 피어 코드 검토에 관해서는 금요일 오후에 수행하고 있습니다.이 작업은 약간 더 편안한 시간입니다 .-) 각 개발자는 자신이 작업하지 않는 지점에 할당되어 있으며 요구 사항을 읽는 데 약간의 시간이 걸립니다. 새로운 기능을 먼저 수행 한 다음 수행 된 작업을 확인합니다. 그의 가장 중요한 임무는 요구 사항에 따라 새로운 코드 가 예상대로 작동하고 , 우리 자신의 "규칙"을 위반하지 않고 (이 오브젝트는 사용하지 말고) 읽기 쉽고, 허용하는 것입니다. 쉬운 확장.

따라서 자동 검토와 "휴먼"의 두 가지 코드 검토가 있으며 검토되지 않은 코드가 HEAD 분기에 커밋되지 않도록합니다. 이제는 ... 여러 가지 이유로 때때로 발생하지만 완벽하지는 않지만 품질과 비용 (시간)간에 공정한 균형을 유지하려고합니다.

@pjz도 좋은 답변을 제공하며 코드 검토 도구를 언급합니다. 나는 아무것도 사용하지 않았으므로 그것에 대해 아무 말도 할 수 없습니다 ... 우리는 이미 JIRA를 사용하고 있기 때문에 Crucible 과 함께 일해 보려고 유혹했지만 .

도움이 될 주요 개념은 "스테이징"영역의 개념이라고 생각합니다.

예, 고장난 코드를 체크인하고 싶지 않습니다. 그러나 코드를 자주 체크인해야합니다. 이것이 완벽 함을 의미합니까? ;) 아니요. 여러 영역과 git와 같은 DVCS를 사용하십시오.
이렇게하면 테스트를 통과 할 때까지 테스트하고 개발할 때 로컬로 변경하고 자주 커밋합니다. 그런 다음 코드 검토를 위해 준비 영역으로 푸시합니다.

그런 다음 스테이징에서 브라우저 테스트 및 사용자 테스트와 같은 다른 QA 노력으로 추진해야합니다. 마지막으로 볼륨 테스트 영역으로 이동 한 다음 최종적으로 생산할 수 있습니다.

메인 브랜치에서 작업하거나 모든 노력에 개별 브랜치를 사용하는 것과 같은 워크 플로우도 있습니다.

지속적인 통합 자체도 여러 수준에서 발생할 수 있습니다. '테스트가 통과 할 때까지'개발자 머신에 로컬 일 수 있으며 코드가 전달 될 때 준비 및 QA 영역에있을 수도 있습니다.

코드 검토 및 지속적인 통합 분리!

왜 당신이 그들을 결합?

리포지토리에 git flow 를 사용 하고 개발 브랜치에 병합 할 때 코드 검토를 수행합니다.

개발중인 모든 것은 완벽하고 배포 가능하며 코드를 검토합니다.

또한 개발 및 마스터 지점을위한 CI를 설정했습니다.

나는 실제로이 작업을 자연스럽게하려면 DVCS (예 : 수은, 자식)가 필요하다고 생각합니다. CVCS를 사용하면 브랜치가 필요하며 어떤 신에게도 합병이 일어나지 않기를 바랍니다.

DVCS를 사용하는 경우 통합 프로세스를 계층화하여 CI 서버에 도착하기 전에 코드에서 이미 검토하도록 할 수 있습니다. DVCS가없는 경우 코드 검토자가 변경 사항을 제출하기 전에 각 개발자의 컴퓨터에서 코드를 검토하지 않으면 코드가 CI 서버에 도착합니다.

개인 저장소 (예 : bitbucket, github, rhodecode)를 게시 할 수있는 저장소 관리 소프트웨어가없는 경우이를 수행하는 첫 번째 방법은 계층 적 통합 역할을하는 것입니다. 다음 다이어그램에서 중위가 개발자의 작업을 검토하고 중위자가 중위가 작업을 병합 한 방법을 검토하도록 독재자가 될 수 있습니다.

저장소 관리 소프트웨어가있는 경우이를 수행하는 다른 방법은 다음과 같은 워크 플로우를 사용하는 것입니다.

리포지토리 관리 소프트웨어는 일반적으로 리포지토리 (예 : 이메일, rss)에 활동이 있고 풀 요청 을 허용 할 때 알림을 보내는 데 도움이됩니다 . 풀 요청은 일반적으로 사람들이 대화에 참여하여 코드를 통합하기 때문에 코드 검토는 풀 요청 중에 유기적으로 발생할 수 있습니다. 가지고 이 공용 풀 요청 예로한다. 통합 관리자는 실제로 코드의 요구가 해결 될 경우 코드가 축복 저장소 (일명 "중앙 저장소")에 도달 할 수 없습니다.

가장 중요한 것은 DVCS를 사용하면 중앙 집중식 워크 플로우를 계속 지원할 수 있기를 원치 않으면 다른 멋진 멋진 워크 플로우를 가질 필요가 없지만 DVCS를 사용하면 중앙 개발 저장소를 CI와 분리 할 수 ​​있습니다 서버 와주고 다른 사람에게 코드 검토 세션이 완료되고 나면 CI의 REPO에 dev에 환매 특약의 변경을 밀어 수있는 권한을 .

추신 : 이미지에 대한 크레딧은 git-scm.com으로 이동 하십시오.

하나 이상의 저장소가없는 이유는 무엇입니까? 하나는 "일일"작업, 지속적인 통합 서버 구동, 모든 단위 테스트 및 통합 테스트를 실행하여 빡빡한 피드백 루프를 얻는 것, 다른 하나는 커밋이 덜 빈번하지만 검토가 필요한 "안정된"작업을위한 것입니다.

변경 사항이 시스템을 통과하면서 이동하는 경로에 따라 약간 복잡한 솔루션이 될 수 있으며 Git 또는 Mercurial Queues와 같은 도구를 사용할 때 가장 효과적 일 수 있습니다 (캐비티 : 분노하지 않았습니다) 그러나 많은 조직들이 비슷한 일을합니다.

이는 기능이 완료 될 때 코드 검토를 수행해야하지만 검토되지 않은 코드가 리포지토리에 들어가는 것을 의미합니까?

위의 방법은 지속적인 통합을 집중적으로 사용하는 적어도 세 개의 프로젝트에서 내가 본 방식과 내 기억에 따라 매력처럼 작동했습니다. 이 관행은 커밋 후 코드 검토 -이 용어에 대한 웹 검색 으로 알려져 있습니다.

• ^{반면에, CI와 사전 커밋 코드 검토 를 "결혼"하려는 프로젝트에 참여한 유일한 경우는 다소 고통 스러웠습니다. 상황이 100 % 원활하게 진행되면 문제가 없었지만, 가끔씩 (주 및 백업 검토자가 몇 시간 동안 사용할 수없는 경우와 같이) 간헐적 인 중단으로 인해 현저한 스트레스를 받았습니다. 또한 팀 사기가 다소 고통을 겪는 것을 발견했습니다. 약간의 갈등이있었습니다.}

먼저 "연속 통합"의 개념을 명확히해야합니다. 기존의 개발 방법에서 지속적인 통합이란 소스 코드 저장소를 매일 통합하고 구축 할 수 있다는 것을 의미하며 "통합 지옥"의 함정을 피할 수 있습니다. 코드 검토는 항상 코딩과 단위 테스트 기간 사이에 있습니다. 브랜치에 병합 된 코드가 오류없이 컴파일 될 수 있도록 보장해야합니다. 인터페이스의 일관성과 컴파일 오류를 처리하기가 어렵 기 때문에 기능의 일부가 브랜치에 병합되는 상황은 거의 없습니다.

지속적인 통합은 익스트림 프로그래밍 프로세스에서 널리 사용됩니다. 테스트 중심 개발에는 코드 검토 프로세스의 일부인 페어 프로그래밍이 추가되어 지속적인 통합을 쉽게 구현할 수 있습니다. Extreme Programming 자체는 지속적인 코드 검토 및 통합 프로세스입니다. 코드 검토는 모든 곳에 존재합니다.

일부 오픈 소스 커뮤니티에서 코드 검토는 코드가 지점에 병합되기 직전에 실행됩니다. 코드 검토를 수행하고 코드를 기본 지점에 병합 할 수 있는지 여부를 결정하는 것은 항상이 팀에서 가장 숙련 된 사람들입니다. 이런 식으로 연속 통합 기간은 조금 더 길지만 코드 품질은 조금 더 좋습니다.

질문으로 돌아갑니다. 코드 검토시기에 대한 표준 답변은 없으며 원래 개발 프로세스와 실제 통합 구현에 따라 다릅니다.