안녕하세요, 저는 Wxh16144입니다. Ant Design의 컴포넌트 라이브러리를 학습하고 커뮤니티에 기여하면서 개발 효율과 코드 품질을 향상 시킬 수 있는 몇 가지 도구를 발견했습니다. 이를 통해 여러분이 Ant Design을 더 잘 이해하고, 이러한 기술들을 자신의 프로젝트에 적용하는 데 도움이 되기를 바랍니다.
서론
Ant Design은 오픈 소스로 GitHub에서 호스팅되어 전 세계 개발자들과 소통하고 협업하기에 용이합니다. 또한 개발자들이 issue와 PR을 제출할 수 있도록 지원합니다. GitHub Actions와 CI/CD 기능을 활용하면 코드 저장소를 효과적으로 관리하고 테스트, 배포 등의 작업을 자동화할 수 있습니다. 이 글에서는 Actions가 제공하는 기능에 대해 자세히 알아보겠습니다.
GitHub Actions란 무엇인가요?
GitHub Actions는 소프트웨어 개발 워크플로를 자동화하는 플랫폼입니다. 개발자는 .github/workflows 디렉토리에 YAML 형식의 파일을 추가하여 자신의 워크플로를 쉽게 사용자 정의하고 구성할 수 있습니다. 이를 통해 CI(지속적 통합)를 구현할 수 있습니다. GitHub Actions를 이해하면 워크플로 내의 다양한 개념들을 파악할 수 있습니다.
Event(이벤트): 워크플로 실행을 발생시키는 요소로, 예를 들어 누군가 issue를 생성하거나, PR을 만들거나, 브랜치에 코드를 푸시할 때 발생합니다.
Job(작업): 워크플로는 기본적으로 병렬로 실행되는 하나 이상의 Job으로 구성됩니다. 그러나 Job을 순차적으로 실행하도록 설정할 수도 있습니다. 각 Job은 여러 단계를 포함할 수 있습니다.
Step(단계): 특정 작업을 수행하는 단위입니다. 각 Step는 별도의 프로세스로 실행되며, 하나의 Step는 하나 이상의 명령어나 쉘 스크립트로 구성될 수 있습니다.
아래의 GitHub 공식 문서에서 제공하는 이미지를 보면 Event, Job 그리고 Step간의 관계를 더욱 직관적으로 이해할 수 있습니다:
사용 방법
위에서 설명한 내용을 바탕으로, Ant Design의 모든 워크플로는 .github/workflows 디렉토리에서 관리된다는 것을 알 수 있습니다.
Ant Design의 CI는 다음과 같은 영역을 다룹니다:
커뮤니티 관리: GitHub Actions를 이용하여 issue와 PR에 대한 품질 검사를 수행하고, 댓글과 레이블을 통해 협업 효율성을 높입니다.
코드 품질: ESLint와 Prettier를 사용하여 코드 스타일을 일관되게 유지하고 코드 품질을 향상시킵니다.
테스트: Jest와 testing-library를 사용하여 단위 테스트와 스냅샷 테스트를 수행하여 코드의 정확성과 안정성을 보장합니다.
빌드: ES5와 ES6 모듈 형식의 파일을 빌드하여 다양한 환경에서 라이브러리를 사용할 수 있도록 합니다.
Issue는 GitHub 플랫폼의 기능으로, 커뮤니티 피드백과 문제들을 수집하는 중앙 집중식 정보 허브 역할을 합니다. Collaborator는 레이블, 마일스톤, 담당자를 추가하여 작업과 프로젝트를 더 효율적으로 관리할 수 있습니다.
Issue의 품질 보장
Issue에 충분한 정보가 포함되어 있어야 Ant Design 팀에서 issue를 분석하고 우선순위를 정할 수 있습니다. 이를 위해 이슈 생성 프로세스를 도움을 주는 issue 도우미를 제공하고, GitHub Actions를 이용해 생성된 issue를 검사합니다. Issue 도우미의 기준을 충족하지 못하는 issue는 Invalid 레이블이 부여되고 자동으로 닫히며, issue를 작성자에게 올바른 질문 방법을 알려주는 댓글이 달립니다. 예를 들어 이렇게 됩니다:
하지만 issue 도우미를 사용하더라도, 때로는 제공된 정보가 부족하여 문제를 해결하기 어려운 경우가 있습니다. 이러한 경우에는 팀원들이 수동으로 issue에 🤔 Need Reproduce, needs-more-info 또는 help wanted 등의 레이블을 추가하여 issue 작성자에게 더 자세한 정보를 요청합니다. 이와 관련된 다양한 레이블이 어떤 댓글 답변 Job를 실행 하는 지에 대한 기록은 issue-labeled.yml 파일에 있습니다:
일반적인 Issue FAQ
자주 발생하는 issue에 대해서는 팀이 상세한 답변을 제공하여 개발자가 문제를 더 빠르게 해결할 수 있도록 돕습니다. 예를 들어, 문제 제목에 웹사이트, 다운, 접속 불가, IE 등의 키워드가 포함된 경우, issue-open-check.yml#L43-L94 Job은 정의된 표준 답변이 달리고 해당 issue를 자동으로 닫습니다.
정기적인 Issue 정리
GitHub Actions의 예약 작업을 사용하여 issue를 관리하고 닫는 과정을 자동화하면 처리되지 않은 issue가 과도하게 쌓이는 것을 효과적으로 방지할 수 있습니다.
issue-close-require.yml: 🤔 Need Reproduce 또는 needs-more-info 태그가 달린 issue를 정해진 시간에 확인합니다. 만약 이 태그들이 3일 이내에 제거되지 않으면, 자동으로 댓글이 달리고 issue가 닫힙니다.
issue-check-inactive.yml: 최근 30일 동안 활동이 없는 issue를 15일마다 확인하여 Inactive 레이블을 추가하지만, issue는 닫지 않습니다. issue가 수정되거나 새로운 댓글이 달리면 Inactive와 needs-more-info 레이블이 자동으로 제거됩니다.
Pull Request
Ant Design 팀은 커뮤니티의 Pull Request (PR) 참여를 적극 장려합니다. PR을 제출하기 전에 《기여자 개발 및 유지보수 가이드》 문서를 읽고, PR 제출 시 지켜야 할 규칙을 확인해야 합니다. 품질과 원활한 소통을 위해 몇 가지 규칙을 준수해야 합니다. 또한, GitHub Action을 활용하여 PR에 대한 요구 사항과 검토를 진행하여 코드 품질을 유지하고 프로젝트의 장기적인 안정성을 확보합니다.
PR 사전 테스트
PR을 생성하면 PR 템플릿을 통해 설명 내용이 자동으로 생성되며, 이 중에는 업데이트 로그 항목도 포함되고, 해당 항목은 개발자가 작성해야 합니다. pr-open-check.yml Job은 이를 확인하며, 만약 작성되지 않았다면 CI가 댓글로 이를 알립니다. 다음과 같이 표시됩니다:
또한, PR에 언급된 issue에 🎱 Collaborate PR only 레이블이 붙어 있을 경우, PR은 자동으로 닫히며 댓글로 알림이 전송됩니다.
verify-files-modify.yml 작업(Job)은 PR에서 변경된 파일을 검사하여 특정 디렉토리(예: ./github/, scripts/) 또는 파일(예: CHANGELOG.md)이 포함되어 있는 경우 커뮤니티 기여를 거부하고 PR을 자동으로 닫으며 핵심 멤버에게 할당합니다.
verify-files-modify.yml Job은 PR에서 변경된 파일을 검사하여 특정 디렉토리(예: ./github/, scripts/) 또는 파일(예: CHANGELOG.md)이 포함되어 있는 경우 커뮤니티 기여를 거부하고 PR을 자동으로 닫은 후 핵심 멤버에게 할당합니다.
PR이 생성될 때마다 GitHub Action를 통해 자동으로 해당 PR을 빌드하고 배포를 시도합니다. 이를 통해 문서가 정상적으로 동작하는지 확인할 수 있을 뿐만 아니라, PR이 문서 또는 컴포넌트 데모에 어떤 영향을 미치는지도 미리볼 수 있습니다. PR 배포는 여러 Job으로 나뉘며, 구체적인 과정은 다음과 같습니다:
먼저 preview-start.yml Job이 실행되어 PR에 자리 표시용 댓글을 남기고, 개발자에게 미리보기 빌드가 진행 중임을 알립니다. 자주 보게 되는 "Preview Preparing..." 메시지가 바로 이것입니다.
마지막으로, preview-deploy.yml Job은 preview-build.yml이 완료될 때까지 기다린 후 해당 작업을 수행합니다. 빌드가 성공하면 Surge를 사용해 배포되며, 배포 주소는 https://preview-{PR-id}-ant-design.surge.sh 형식으로 생성됩니다. 이후, 이전에 댓글에 있는 자리 표시 이미지가 빌드 성공 이미지로 변경되며 (이미지를 클릭하면 해당 주소로 이동), 반대로 빌드 실패인 경우에는 실패 이미지를 표시합니다.
최근 인기 있는 ChatGPT를 팀에서는 GitHub Action에 추가하여 AI가 먼저 코드를 검토하도록 하였습니다. 구체적인 Job은 chatgpt-cr.yml 파일에서 확인할 수 있습니다.
단위 테스트
단위 테스트는 컴포넌트 라이브러리의 품질을 보장하는 가장 중요한 요소 중 하나입니다. 코드가 푸시될 때마다, 개발자가 생성한 PR이나 메인 브랜치 업데이트를 포함하여 자동화된 테스트를 수행하는 CI가 실행됩니다.
빌드 테스트
팀은 코드가 업데이트될 때마다 빌드 및 패키지된 결과물이 생성되기를 원했습니다. Ant Design은 test.yml 파일에 Dist Job과 Compile Job을 추가하여 저장소가 올바르게 빌드되고 패키지될 수 있도록 보장하고 있습니다.
기능 테스트
모두가 알다시피, 매번 테스트 관련 Job이 실행될 때 최대 30개까지 이루어집니다.
팀은 단위 테스트에 매우 신중하며, 주요 React 버전(일반적으로 16, 17, 18번 버전)에서 실행되는 상황을 고려해야 합니다. 메인 브랜치가 업데이트되면 프로젝트 빌드 결과물(일반적으로 dist, es, lib)이 세 가지 React 버전에서 어떻게 동작되는지도 확인해야 합니다. 현재 Ant Design의 모든 컴포넌트에는 4,000개 이상의 테스트 케이스가 있는 것으로 알려져 있습니다. 테스트 효율성을 더욱 높이기 위해 분산 테스트 환경도 구축했습니다.
이러한 모든 기능은 GitHub Action의 Job 매트릭스 전략 덕분에 가능하며, 이를 통해 여러 Jobs를 한 번에 구성하여 테스트 작업을 실행할 수 있습니다. Normal test와 Module test는 Ant Design이 매트릭스 전략을 사용하여 테스트하는 Jobs입니다.
웹사이트 배포
여기서 설명하는 배포와 빌드 과정은 앞서 언급한 PR 미리보기 배포와 빌드 과정과 매우 유사하지만, 빌드 결과물을 배포하는 위치가 다르다는 점이 특징입니다.
모두가 알고 있듯이 https://ant.design 공식 웹사이트는 항상 최신 버전을 유지하지만, 가끔 특정 버전의 문서를 확인해야 할 필요가 있습니다. Deploy to Surge Job은 새로운 버전이 출시될 때마다 사이트를 Surge에 배포하며, URL 형식은 https://ant-design-{major}-{minor}-{patch}.surge.sh 입니다. 이 URL은 각 릴리스 커밋에 댓글로 남겨집니다:
기타
위에서 Ant Design이 CI/CD를 활용하여 수행하는 핵심 내용의 대부분을 설명했습니다. 하지만 실제로는 자세히 소개되지 않은 Job들이 몇 가지 더 있습니다. 여기서 추가적으로 설명해 드리겠습니다.
IM 알림 통합
개발자와 커뮤니티 구성원이 관련 정보를 가능한 한 빨리 알 수 있도록 IM 통합이 Action에서 제공하는 이벤트를 사용하여 구현되었습니다:
생성된 PR이 CI Job을 올바르게 실행하였고, 우리의 pnpm 저장소가 캐시되었습니다. 이제부터는 CI가 실행될 때마다 pnpm-lock.yaml 파일의 내용에 따라 캐시를 직접 읽을지를 결정하게 됩니다.
위의 Setup pnpm cache 단계에서 7일 동안 접근하지 않은 캐시 항목은 삭제됩니다. 저장할 수 있는 캐시 수에는 제한이 없지만, 저장소의 모든 캐시 총 크기는 10GB로 제한됩니다. 더 많은 내용은 작업 흐름을 빠르게 하기 위해 의존성 캐싱을 읽어보시기 바랍니다.
마무리
이 글이 Ant Design에 대한 더 깊은 이해에 도움이 되었기를 바랍니다. Ant Design 토론에서 토론에 참여하고 프로젝트에 기여해 주시기 바랍니다.
