[ 엘리스 SW 엔지니어 트랙 ] 76일차 TL;DR

1. branch 전략

  - Git-Flow: 단순하다, CI/CD가 자연스럽다, master(최종), 체계적인 분류 없이 master에 의존한다.
  - GitHub-flow: 상세한 리뷰와 토의, master(최종), develop(개발), release(QA 및 베타 테스트), hotfix(master에서 버그수정)

2. 우리팀의 `branch` 전략은 `GitHubFlow`를 기반으로 하되 `GitFlow`의 방법을 조금 섞었다. commit convention을 정했고, MR올리면 해당 분야 팀원들이 코드리뷰 후 의견을 남긴다. emoji를 모두 남겼으면 팀장이 최종적으로 merge한다. merge가 완료된 branch는 삭제한다. commit의 개수를 모두 남기는것보다 squash 전략으로 여러개의 커밋을 하나로 뭉친다. (이와 비슷한 rebase 전략은 제일 마지막 commit만 사용한다. log가 깔끔해지는 장점이 있지만 반면에 기록이 남지 않으므로 git 숙련도가 낮으면 추천하지 않는다.) 급하게 수정하는 사항은 hotfix 브랜치를 사용했고, Back과 Front 연결은 release 0.0.x 버전의 브랜치를 만들어서 QA테스트를 진행한다.
3. react에서 proxy를 사용할 때 CRA 대신 webpack을 사용한다면 webpack.config.js에서 devServer안에 다음과 같은 코드를 추가한다. 이렇게 작성하면 프론트에서 백으로 API요청을 할 때 host + port를 생략해도 target으로 요청이 넘어간다.

proxy: {
      "/api": {
        target: "http://localhost:8888",
    },
}

4. 이왕 서버 배포해보는 김에 Azure, Nginx, CI/CD 도 공부해보자.
5. 서버에서 GET,, POST 와 같은 요청을 테스트하는 라이브러리는 supertest를 이용했다. 유닛 테스트는 jest
6. jest coverage 는 테스트 현황을 표로 한 눈에 볼 수 있다.