Essay· 12 min
Storybook + Chromatic 시각 회귀 자동화 — pilot에서 머지 블로킹까지
Chromatic을 PR마다 자동으로 돌리되 false positive로 팀에 마찰을 주지 않는 단계적 도입법. baseline 관리, TurboSnap, dangerouslyIgnoreUnhandledErrors까지.
tag
안녕하세요, 로건이에요 👋
어떤 글을 찾고 계세요?
최신 글
AWS SDK가 SSO 토큰 캐시를 끌고 들어왔다 — publish 직전에 발이 두 번 걸린 이야기
📚 Visual Builder OSS(Open Source Software) 분리기 · 32편 끝에서 살짝 언급했던 함정 이야기로 시작할게요. publish 직전에 발을 걸리게 한 바로 그 함정이요. OSS의 createS3Storage가 기존 프로젝트 webpack 위에서 처음으로 돌아간 날이었어요. 빌드는 멀쩡히 통과했어요. 그런데 storybook을 열어보니 콘솔에 이런 게 뜨더라고요. fs.promises.writeFile. 처음엔 황당했어요. 우리는 그런 코드를 짠 적이
OSS 본체부터 만들 뻔했다가, 기존 프로젝트 안에서 먼저 갈아엎고 옮긴 건에 대하여..
📚 Visual Builder OSS(Open Source Software) 분리기 · 21편에서 어댑터 세 개를 그렸다면, 2편은 그걸 들고 실제로 옮긴 이야기예요. 기존 프로젝트에서 25개 commit, OSS repo에서 20개 commit이 나왔어요. 숫자만 보면 평범한 리팩토링 같은데, 사실 이 분리 작업에서 가장 중요했던 결정은 순서였어요. 한 줄로 적자면 — OSS 본체 코드를 만들기 전에, 기존 프로젝트 안에서 먼저 어댑터 모양으로 갈아엎었다. 처음엔 그럴 생각이
스토리북에 박혀있던 Visual Builder를 npm으로 분리하기로 한 날
📚 Visual Builder OSS(Open Source Software) 분리기 · 1사내 storybook에서 굴러가던 Visual Builder를 npm으로 분리하기로 했어요. 결과만 먼저 말하면 @bdmakers/visual-builder@0.1.1이라는 회사 OSS로 떨어졌고, 기존 프로젝트에 남은 빌더 관련 코드는 300줄 남짓이 됐어요. 분리하기 전에 기존 프로젝트에 박혀 있던 양이 8,400 줄이었으니까, 8,100 줄 정도가 라이브러리 쪽으로 넘어간 셈이죠. 그
파이프라인은 끝의 일 — GitLab CI · preflight · 비밀 마스킹 · Dooray로 묶다
📚 EAS Update Playbook · 4여러분, 4편의 제목을 한 줄로 다시 적어볼게요. "파이프라인은 끝의 일." CI/CD 글을 쓸 때 자주 빠지는 함정이 있어요. 파이프라인을 시작에 두는 것 — 마치 파이프라인 설계가 운영 디자인의 출발점인 것처럼 쓰는 거죠. 저희 팀에서는 반대로 봅니다. 코드(13편)가 이미 정직한 동작을 보장하고, 그 다음에야 파이프라인이 그 위에 얇은 한 겹을 덮어요. 그 한 겹의 일은 단순합니다 —