티스토리 뷰

나의 첫 직장에서는 백엔드 개발자가 서비스 론칭을 위한 서버 세팅을 도맡아 하고 있었다.

그러다보니 프론트 개발자나 아이폰 개발자와 같은 다른 개발자들은 실서버 배포를 진행할 일이 거의 없었고, 있다고 하더라도 백엔드 개발자에게 요청을 넣고 기다리는 형태로 배포를 진행했었다.

그러다보니 프론트 개발자가 구문 오류를 확인하지 못하고 배포 요청을 진행할 경우 백엔드 개발자가 배포를 진행하다가 빌드 에러가 터져서 검토 요청을 다시 넣고, 프론트 개발자가 검토 요청을 확인하고 재검토를 진행하며 재배포 요청을 넣을 때 까지 상당한 시간이 소모 되는 경우가 많았다.

배포만이 문제가 아니다. 특이하게도 개발자 한 명이 프로젝트 하나를 도맡아 처리하는 성향이 강했던 기업이라 브랜치가 사실 의미가 별로 없었다. 어차피 혼자 개발하는거, 다른 브랜치를 만들 필요 없이 마스터에 커밋만 하면 끝이였으니까.

이게 생각보다 귀찮았다는건 거기 있는 개발자 모두가 알고 있었고, 문제가 많은 방식이였다는 것도 알고 있지만 왜 회사를 그만두고 다른 직장으로 가고나서야 생각이 나는걸까?

그래서 이를 해결하기 위해 배포 자동화를 구축해보고자 한다.

(겸사겸사 단위테스트도 좀 배울겸)

 

git에는 hook이라는게 있다. 프레임워크 몇 개 써보면 알겠지만, 특정 이벤트가 벌어질 때 해당 이벤트에 별도의 기능을 추가할 수 있는것을 hook이라고 부른다. (정확한건 아닌 내 뇌피셜)

깃에도 물론 이런게 있다. 커밋을 진행하기 전, 커밋 진행 후, 푸쉬 이후 등 다양한 hook이 존재하고, 이를 핸들링할 수 있는 방법이 존재한다.

 

1. 프로젝트에 husky 세팅하기

npx husky-init && npm install
// or
npx husky-init && yarn

2. husky hook 생성하기

npx husky add .husky/pre-commit "npm test"

3. commit 테스트 해보기

git add *
git commit -m "Test commit"

4. 테스트 진행 후 커밋

Jest를 통한 단위 테스트 이후 커밋 진행

당연하겠지만, 단위 테스트에서 오류가 발생하면 커밋이 진행되지 않는다.

'pre-commit'이라는 훅은 exit status가 0이 나오지 않으면 커밋을 취소하기 때문인데, 단위 테스트에서 문제가 하나라도 존재한다면 exit status가 20이 나오기 때문.

 

Exit status - Wikipedia

From Wikipedia, the free encyclopedia Jump to navigation Jump to search "Result code" redirects here. For the result code of software in general, see Return code. The exit status of a process in computer programming is a small number passed from a child pr

en.wikipedia.org

이를 이용한 자동 테스트 진행 후 배포가 가능하게 된다.

LIST

'기술 및 이슈' 카테고리의 다른 글

[Jest] 단위 테스트 맛보기  (0) 2021.08.10
[수학] Sine Graph  (0) 2020.11.12
정규표현식이란?  (0) 2020.06.13
Restful API란?  (0) 2020.05.25
웹앱의 퍼포먼스를 늘리는 법  (0) 2020.05.22