엔지니어링

Elastic에서 끌어오기 요청을 처리하는 방법

By
Elastic Engineering

Elastic에서는 협력적인 노력을 통해 작업이 완료됩니다.

우리 엔지니어들은 새로운 제품과 기능을 개발하며 (원격 근무를 하는 회사답게 문자 그대로) 24시간 내내 일하고 있습니다. 세부적인 부분까지 꼼꼼히 살펴야 하는 엄청난 양의 작업입니다. 그러나 우리가 아무리 주의를 기울인다고 해도, 완벽할 수는 없습니다. 그리고 우리 프로젝트처럼 복잡한 모든 오픈 소스 프로젝트의 경우, 개선하려면 여전히 커뮤니티의 도움이 필요합니다.

수정 작업을 진행하는 금요일마다 작지만 중요한 문제들을 해결하면서, 우리는 제품을 개발하는 데 있어 우리 커뮤니티의 기여가 얼마나 우리의 지속적인 성공을 추진하는 요인인지 얘기했습니다. 오픈 소스 프로젝트로서 큰 장점 중 하나는 버그를 찾으려고 애쓰며 버그를 제거할 기회를 간절히 기다리는 대규모의 개발자 커뮤니티가 우리에게 있다는 것입니다.

커뮤니티의 새로운 구성원으로서 처음으로 끌어오기 요청(Pull Request, PR)을 제출하려고 하거나 어떤 프로세스를 거치게 되는지에 대해 질문이 있으시면, 잘 찾아오셨습니다! 이 포스팅에서는 끌어오기 요청이 Elastic에서 진행되는 방식, 끌어오기 요청을 받은 후 이루어지는 Elastic 프로세스, 기여해 주신 내용이 구현되지 못하게 되는 일반적인 실수를 피하는 방법에 대한 개요를 제공합니다.

끌어오기 요청을 어떻게 제출하나요?

PR을 제출하기 전에, GITHUB 저장소에서 프로젝트를 포크(fork)하고 코드를 변경하셔야 합니다. 이것은 보통 구성원 자신의 GitHub 계정에서 이루어지며, 그 구성원을 위한 소스 저장소 복사본을 만듭니다. 모든 프로젝트가 프로젝트 자체 GitHub 저장소에서 유지됩니다. 우리의 저장소 전체 목록은 GitHub의 Elastic 조직 페이지에서 보실 수 있습니다. 

일단 저장소를 포크하여 코드를 변경하고 나면, 제안된 변경 사항을 제품 저장소의 마스터 분기에 보내기 위해 PR을 생성하겠느냐는 질문을 받게 됩니다. 예를 들면, Elasticsearch 저장소가 아래에 나와 있습니다. 간단하게 하기 위해, 이 포스팅 전체를 통해 Elasticsearch 저장소의 예를 보여드리겠습니다.

“새 끌어오기 요청”을 클릭하면, 끌어오기 요청 템플릿이 나타납니다.

이 템플릿은 구성원의 PR이 첫 번째 검토를 마치는 데 도움이 될 만한 지침을 제공해 드립니다. 따라서 끝까지 잘 읽어보셔야 합니다. 각 제품마다 자체의 기준과 설명서가 있기 때문입니다. 템플릿은 구성원의 PR이 첫 번째 검토를 마치는 데 도움이 될 만한 지침을 제공해 드립니다.

제출하실 때 다음과 같은 일반적인 실수를 피하도록 하세요.

  • 중복 제출 - 먼저, 코드가 수정하고자 하는 버그를 이미 다루고 있는 진행 중인 PR이 있는지 검색해 보세요. 중복 제출은 일반적으로 거부됩니다.
  • 테스트를 포함하지 않음 - 코드 변경을 포함하는 PR은 새 코드의 동작을 보여 주는 테스트를 포함해야 합니다. 이 테스트가 PR이 수정하려는 문제를 재현할 수 있으면 가장 좋습니다. 코드가 없으면 테스트에 실패하고, 코드가 적용되면 테스트를 통과할 수 있도록 말입니다.
  • 마스터 분기만 - 코드를 변경하는 모든 PR은 관련 디렉터리에 있는 마스터 분기를 대상으로 만들어야 합니다.

템플릿에 써 있는 모든 요건을 완료하면, “끌어오기 요청 만들기”를 클릭합니다. 그럼 이제 그 구성원의 손을 떠난 것입니다.

심사 및 레이블 지정

우리가 취하는 첫 번째 단계는 PR이 (위에서 언급한 대로) 좋은 요청의 요건을 충족하고 있는지 확인하는 것입니다. 충족하고 있다면, 추후 심사를 위해 적절한 담당자에게 보내지도록 레이블을 이용해 PR에 태그를 지정합니다. 레이블에는 >bug, >feature 등이 포함될 수 있습니다. 끌어오기 요청에 레이블이 붙으면, 처리를 진행할 적절한 하위 팀에게 할당됩니다. 이 시점부터는 해당 영역을 담당하는 팀에서 요청 처리를 책임집니다.

프로세스 시작

PR에 레이블이 붙으면, 우리 개발자 중 한 사람이 작업을 시작합니다. 요청자에게 되도록 빨리 연락을 드리기 위해 노력하고 있으며, PR을 제출하실 때는 인내심을 갖고 기다려주실 것을 부탁드립니다. 24시간 내내 들어오는 요청의 수준과 난이도에 따라 요청을 처리하는 데 시간이 걸릴 수 있기 때문입니다. 

설명서 변경 사항 제출

참고: 문서를 수정하거나 변경하는 PR도 많이 받습니다. 이 프로세스는 코드 변경보다는 훨씬 간단합니다. 필요한 것은 Elastic 문서 페이지에서 “편집”을 클릭하고 변경하고 요청을 제출하는 것뿐입니다. 프로젝트를 포크할 필요도 없고 필수 테스트도 없습니다. 이러한 PR에는 “>doc”이라는 레이블을 붙이고 가능한 한 신속하게 처리합니다.

더 많은 작업이 필요한 경우

병합할 준비가 되려면 PR을 적절하게 변경해야 하는 경우도 자주 있습니다. 이 시점에서, PR은 토론이 발생하고, 변경 사항이 제안되고, 추가적인 커밋이 이루어지는 공동 작업 공간이 됩니다.

검토 프로세스 중에 우리는 PR에 대한 테스트를 실행합니다. 그 결과는 GitHub에서 보실 수 있습니다. 때로는, PR의 변경 사항이 적용되어도 테스트에 실패하기도 합니다. 제출된 테스트에서 제대로 통과한 경우라도 말입니다. 그러나 이렇게 끝나는 것은 아닙니다. 우리는 기여자가 기여된 코드를 수정하여 모든 테스트에 통과할 수 있도록 도와드립니다.

이 단계에서는 코드 및 명명 규칙과 코드 스타일도 살펴봅니다. 끌어오기 요청을 제출하는 사용자는 자신의 코드가 최소한 한 차례의 검토를 거치게 되리라는 것을 알고 있어야 합니다. 코드는 절대 완벽할 수 없고(우리 코드도 완벽하지 않습니다!) 제출될 때 병합할 준비가 완료된 상태일 수도 없습니다. 따라서 그 과정에서 어느 정도라도 공동 작업을 할 생각을 하고 계셔야 합니다.

PR을 커밋하는 데 시간이 얼마나 걸리나요?

PR이 처리되는 데 걸리는 시간은 다양합니다. 간단한 코드 한 줄은 금방 처리될 수 있지만 복잡한 코드 변경은 여러 차례의 검토를 거치게 됩니다. 제출된 PR이 아무런 조치 없이 너무 오래 걸린다는 생각이 들면 아직 활성 상태라는 알림 차원에서 티켓을 보내셔도 됩니다.

코드 커밋

모든 준비가 완료되면, 검토자는 승인 작업이라는 주석을 추가합니다. 이것은 LGTM("좋아 보입니다(Looks Good To Me)") 주석일 수도 있고, 그 비슷한 것이 될 수도 있습니다. PR이 수락된 후, Elastic 개발자는 끌어오기 요청을 마스터 분기로 병합한 다음, 필요에 따라 변경 사항을 개발 분기로 백포팅합니다.

이것으로 PR 진행 과정을 간단히 설명해 드렸습니다. 물론 끌어오기 요청은 다양합니다. 프로세스는 간단할 수도, 어려울 수도 있습니다. 프로세스에 대해 심도깊게 알 수 있는 유일한 방법은 팔을 걷어붙이고 직접 참여해 보는 것입니다.

첫 번째 PR을 제출할 준비가 되셨나요? GitHub에서 제공되는 Elastic 저장소를 통해 살펴보시고, 지침을 숙지하시고, 직접 해보세요. 프로세스에 대해 추가적인 질문이 있으시면, 토론 포럼에 가서 주제를 만드세요. 기꺼이 도와드리겠습니다.