Mincho 프로젝트의 이번주 #3 - 깃허브 봇들과 함께해요
소개글
주간레터
이번 주 개발 팁은 적은 사람들이 오픈소스 개발을 할 때 커다란 도움이 될 거에요.
사람이 많아도 사전 필터링이 한번은 될테니, 도움이 될테구요.
봇들과 함께하는 개발
여러분의 프로젝트에서는 어느정도로 자동화를 하고 있나요?
회사라면 상당히 많은 자동화 파이프라인이 가동될 수도 있겠지만, 개인 프로젝트들에서는 생각보다 쉽지 않습니다.
이 글에서는 몇가지 유용한 자동화를 소개하려 합니다.
저희 레포에서 풀리퀘스트를 발생시키면 봇들이 돌아가는데요, 같이 확인해봅시다.
1. CI로 체크하기
저희의 CI는 pre_job과 build라는 2개의 과정으로 이루어져 있어요
pre_job은 git의 커밋 해시를 인식해 한번 돌아간적이 있다고 인식되면 build 과정을 pass 시켜버려요.
커밋을 다시하는 상황이라면 모를까, 다음의 상황에서 또 CI를 돌릴 필요는 없잖아요?
push되어 CI가 돌아간 이후에 PR을 열기
fast-forward merge가 된 상황
그렇다면 build 과정에서는 어떤 일이 일어날까요?
먼저 레포와 캐시를 다운받고요
워크플로우 및 액션등에 대한 lint를 돌립니다.
.yml파일 작성을 잘못해서, PR에서는 통과했지만 릴리즈를 해야할 때 안돌아간다던가, 이슈폼이 제대로 나타나지 않는다던가 하는 일들이 있으면 억울하잖아요?? 그래서 저희는 체크를 따로 하고 있어요.이후
yarn test:all이라는 명령어로 각종 테스트를 진행해요.
어떤 테스트를 돌릴까요?
린트: 린트로 정적 분석을 하고, 포매팅도 함께 검사해요
타입 체크: 저희는 타입스크립트 프로젝트이니 타입을 만족하는지 체크해야지요.
빌드: 당연하지만 빌드는 항상 되어야 합니다.
테스트 코드: 유닛 테스트들을 모두 만족해야 합니다.
이 테스트 과정은 turborepo를 이용해 의존성을 파악하고, 병렬로 실행합니다.
캐시와 병렬화 덕분에 1분 정도면 CI 과정은 마무리되요.
2. 코드리뷰
아니.. 코드리뷰를 자동으로 해주는 봇이 있다고요??
저희는 Coderabbit이라는 봇을 도입 후 매우 잘 사용하고 있습니다. (오픈소스는 공짜!!)
PR을 올리면 먼저 기다려달라는 귀여운 메세지가 뜨고요.
제 PR을 요약해줍니다.
상세한 코멘트는 별도죠.
리뷰가 필요하다 생각하면 댓글도 달아주고, 주고받고 할 수 있습니다.
특히 문서화 PR에서 폭풍 코멘트를 날려주셨어요..제..슬픈 영어 실력...ㅠㅠ
코드 리뷰는 상대적으로 덜 빡센 편인데요, 그래도 가끔씩 유용한 리뷰들을 남겨주어 좋습니다.
3. Fast forward 체크
저희는 fast-forward라는 git merge 방식을 주로 사용해요. (자세한건 다음에 설명하겠습니다)
깃허브에서는 지원하지 않는데요.
merge 커밋이 생성되 추적이 어려운 점을 방지하고, rebase나 squash와 달리 커밋기록과 해시가 보존하고 싶었어요.
Fast forward merge봇이 fast-forward가 가능한지 체크해주고, 가능하다면 다음과 같이 댓글을 달아서 merge하도록 구성해놨어요.
의존성 업데이트 및 보안 체크
깃허브 레포의 settings/security_analysis에 가면 다양한 설정이 있습니다.
먼저 Dependa bot.
뭔가 싶겠지만 한번쯤 본적이 있을거에요.
저희는 여러개가 한꺼번에 열리는 귀찮은 점을 방지하기 위해 그룹으로 한꺼번에 업데이트하도록 설정해두었어요.
그리고 Code scanning을 통해 자동적으로 보안감사를 하도록 구성해두었습니다.
아직 저희는 패키지를 배포하고 있지는 않아서 배포하는 액션은 없는데요,
8월 중에는 아마 생길 것 같습니다.
이번주에 한일
이번주에도 많은 일을 했어요.
1. 문서화
먼저 제 프로젝트들의 특징 중 하나라고 하면, 문서양이 규모에 비해 많은 편 입니다.
보는 사람이 편하고, 관리하기도 편하더라고요.
이번에는 README, Code of Conduct, Contributing 등의 문서를 모두 완전히 다시 썼어요.
특히 Contributing 문서에는 명문화된 개발 프로세스들이 많은데요,
나중에 주간레터에서 하나씩 소개드리도록 하겠습니다.
2. 팀원과 업무 할당 및 공유
팀원이 아마 이번주까지는 할 일 때문에 참여를 많이 못할 것 같아요.
그래도 정기 미팅으로 일요일에 만나고 있습니다.
이번주 일요일에는 Stacked Diff PR을 위한 선형 커밋 로그를 만드는 방법에 대해 알려주고,
패키지 배포에 대해 함께 논의하였답니다.
3. debugLog
디버깅을 하다가 너무 힘들어서 만든 패키지에요.
호출 될때마다 카운트가 증가하고요,
JSON을 이쁘게 보여주고
비교도 할 수 있어요.
4. 번들링 설정
이제 슬슬 배포가 다가오기 때문에 번들링 관련 설정을 했어야 합니다.
의존성: 원래 설정은 Node.js에서 모든 의존 패키지가 번들링되어 하나의 JS 파일로 나왔는데요, 어플리케이션이 아니기 때문에 외부 패키지는 설치하도록 변경했습니다.
ESM & CJS: ESM(
index.js,index.d.ts)과 CJS(index.cjs,index.d.cts)를 export 할 수 있도록 했어요.플러그인: 위에 나온 debug-log를 vite plugin으로까지 만들었어요. 자세한건 다음에. ㅎㅎ
5. property reference 구현
property를 참조할 수 있는 기능이랍니다.
export const myCss = css({
width: "50px",
height: "@width",
margin: "calc(@height / 2)"
});다음과 같이 컴파일 되겠죠?
export const myCss = style({
width: "50px",
height: "50px",
margin: "calc(50px / 2)"
});이번주에는 생각보다 다른 할 일이 많았습니다.
이제 기능은 1개만 더 만들면 되네요!!
다음주에는 debug-log부터 배포를 시작해볼거에요!!
혹시 개발에 관심이 있으시다면 댓글을 달아주시거나 alstjr7375@daum.net에 연락을 주셔도 좋습니다.
하단의 업보트와 깃허브 스타를 찍어주셔도 매우 큰 도움이 됩니다!!
- 세번째 뉴스레터 끝 -
디자인시스템을 위한 CSS in JS 프레임워크
댓글
로그인 후 댓글을 남길 수 있습니다.
어제 밤에 급하게 썼더니 문장들이 좀 꼬여있었네요. ㅎㅎ 수정했습니다.