[warrr-ui 디자인 시스템 개발기] CI/CD

이번 주에는 cicd + changeset이라는 주제로 과제를 해오기로 했다.

 

이전에 cli 프로그램을 npm에 배포한 적이 있었는데 그때 changeset을 활용해서 배포해 봤기 때문에 이번에는 좀 더 새로운 걸 해보고 싶었다.

cli 프로그램에 대해서 궁금한 사람은 아래 글을 읽어보도록 하자.

https://gugu76.tistory.com/138

 

디자인 시스템에 적용할 액션 탐방

어쨌든, 이번 주에는 우리 디자인 시스템에 써볼만한 액션들이 있는지 좀 둘러보는 시간을 가졌다.

깃허브 마켓플레이스를 하나씩 둘러보면서 디자인 시스템에 적합한 게 있나 찾아봤다.

생각보다 내가 몰랐던 것들이 많아서 신기해하면서 찾아봤다.

 

아래 액션들은 그렇게 찾아낸 것들이다.

 

아래 액션은 stark라는 웹 접근성 검사기 관련 액션인데, 예전에 팀원 중 한 명이 구글 크롬 익스텐션으로도 쓸 수 있다고 해서 우리도 적용해 볼 수 있지 않을까...라는 생각에 들고 오게 되었다.

https://github.com/marketplace/actions/stark-accessibility-checker

최근에 알게 된 사실인데, playwright를 사용하면 웹 접근성 테스트를 할 수 있고, storybook에서는 test runner와 a11y-addon을 사용하면 웹 접근성 자동화 테스트를 실행시킬 수 있다고 한다.

추후, 와우 디자인 시스템과 warrr-ui에도 둘 다 적용해볼 예정이다.

 

아래 액션은 번들 크기 변화를 PR에 코멘트를 달아주는 역할을 한다.

https://github.com/marketplace/actions/bundle-comparison

아래 예시를 보면 좋을 것 같아서 가지고 왔다.

https://github.com/github/webpack-bundlesize-compare-action/pull/50#issuecomment-1054919780

어쨌든 패키지 크기도 라이브러리 선택지에 있어 중요한 지표라고 생각해서 이런 것도 신경 써서 개발하면 좋지 않을까 하는 마음에 들고 왔다.

 

다음은 페이지 성능 관련 액션이다.

https://github.com/marketplace/actions/webpagetest-github-action

사실 지금까지는 페이지 성능보다는 기능 구현에 집중해서 개발을 해왔었는데, 이제는,,, 페이지 성능을 좀 더 챙겨보고 싶은 마음에 들고 왔다.

추후 문서 페이지 개발 시 꼭 넣어보고 싶은 액션 중 하나이다.

깃허브와 연결해주게 되면 아래와 같은 검사 결과를 PR 코멘트로 달아주게 된다.

 

꼭 위에 나온 액션이 아니더라도, lighthouse 검사 결과를 알려주는 액션도 있다고 해서 둘 중 하나 더 좋은 걸 선택해서 사용해 봐도 좋을 것 같다.

https://github.com/marketplace/actions/lighthouse-check

아래와 같이 여러 기능들을 포함하고 있어서 상당히 많은 도움이 될 것 같다.

 

대충 이 정도만 해도 충분한 것 같다.

 

유명 디자인 시스템 워크플로우 분석

사실, 여러 디자인 시스템 워크플로우들을 살펴봤지만, 대체로 비슷하긴 했다.

대체로 circleci보다는 github action을 사용했고, 아래 워크플로우들을 주로 사용했다.

1. npm 배포 자동화

2. 테스트 자동화 (단위 테스트, 타입스크립트 테스트, 브라우저 테스트, e2e 테스트, 시각적 회귀 테스트 등)

3. 크로마틱 배포

 

circleci와 github action의 차이점을 조금만 살펴보자면,

1. circleci는 하나의 yaml 파일로 존재하도록 하지만, github action 파이프라인은 각 워크 플로우에 대해 별도의 yaml 파일로 분할할 수 있다.

2. github action은 github에 내장되어 있어 저장소와 보다 밀접하게 통합되어 있다.

 

사실, 둘 다 거의 비슷하기는 한데, 깃허브를 사용하고 있는 입장에서는 github action이 편하기는 하다.

그래서 우리도 아마 github action을 사용할 것 같다.

 

이제, 좀 인상적이었던 워크 플로우들만 살펴보도록 하자.

먼저, 내가 좋아하는 당근 seed design이다.

아래 워크플로우는 icona, 즉 seed icon과 함께 사용하는 워크플로우이다.

https://github.com/daangn/seed-icon/blob/main/.github/workflows/icona-generate.yml

 

아마 seed icon에서 피그마와 깃허브를 연동시켜 모든 아이콘이 담긴 파일인 icons.json을 생성해 주는 기능을 제공하는 것 같고, 이 icons.json을 해당 워크 플로우에서 활용해서 개별 아이콘들로 분리하고 이를 깃허브에 올려주는 기능을 하는 것 같다.

 

당근뿐만 아니라 채널톡에서도 비슷하게 아이콘 관리를 하는 모습을 볼 수 있었다.

아래 워크플로우는 채널톡 디자인 시스템 레포지토리에서 가져온 것이다.

https://github.com/channel-io/bezier-react/blob/main/.github/workflows/generate-icon-files.yml

 

여기서도, icons.json 파일에서 개별 svg 파일들을 생성하고 깃허브에 올려준다.

개별 svg 파일을 생성하는 것은 자동화 스크립트를 통해서 하고 있는데, 이 부분에 대해서는 추후 자세히 알아보고 도입해보려 한다.

 

사실, 이번에 디자인 시스템들 워크 플로우 살펴보면서 웹 접근성 테스트를 별도로 하는 곳을 찾아볼 수는 없었다.

그래서, 살짝 아쉬웠는데, 스토리북에서 제공하는 웹 접근성 애드온을 활용해서 테스트를 자동화시켜볼 수 있다는 것을 알게 되었다.

추후, 이 부분도 꼭 도입해보도록 하겠다.