Mock API VS 배포
Mock API를 클라이언트에서 실험으로 사용할 수 있는 API를 제공하는 것으로만 이해했다.
그런 의미에서 aws ec2에 구체적인 로직은 들어가지 않았지만 어쨋든 data를 반환하는 서버를 배포하는 것이 mock api를 클라이언트에게 준다는 개념으로 생각했다.
그런데 잘못 생각하고 있던 개념이었다.
이런 메시지들이 와있었다.
mock api와 배포에 대한 개념을 혼동하고 있었던 것이다.
서버에 의존하지 않고 목데이터를 직접 생성해서 테스트하는 방법은 어떻게 하는걸까?
Postman
실제 서버 배포를 하는게 아니라 Postman으로 mock서버를 구축할 수 있다.
브랜치/PR 관리
짝이랑 브랜치/PR 관리하는 것에 대한 이해가 다른거 같아서 메인브랜치를 기준으로 PR관리하는 방법에 대한 장점을 생각해봤다.
내가 생각하는 깃헙을 사용한 코드 관리는 이렇다:
-
레포에서 기준이되는 메인브랜치를 결정한다.
-
각 개발자들은 담당하는 부분들을 추가/개선/수정해서 팀에서 정한 브랜치 명명 규칙으로 push한다.
-
push한 것을 PR을 보낸다.
-
PR 보낸 것에대한 리뷰를 받는다. 소통한다. 수정한다.
-
최종적인 결과물이라고 합의가 되면 merge한다. 이것은 깃헙에서 Approve라는 기능을 제공함.
-
merge되는 branch는 merge하면서 브랜치를 삭제한다. 필요한, discuss되고 있는 PR 브랜치만 남기도록 하기 위해서.
이렇게해서 장점은 무엇인가?
-
깃헙에서 그렇게 사용하라고 기능을 이미 다 만들어놓았기 때문에, 확인된 안전한(?) 방법이다.
-
서로 리뷰하면서 코드에 의견이 남게되고 휘발되지 않는다, 코드가 서로 같은 이해선상에 올리는데 도움이 된다.
-
리뷰하면서 추가/수정이 필요한 코드 작업이 생긴다. 간단히 해당 PR에서 해결하면 된다. 이렇게 관리안하면 수정해서 푸쉬하고 또 다시 보니 틀린거같아서 다시 수정하고 푸쉬하고,,이런 사이클은 좋지 않다고 생각한다. 예를 들어서, 팀원이 PR날린거 테스트한다고 풀해서 테스트해봤는데 에러가 나서, 코드수정 후 해결을했다. 이걸 진행중인 PR에다가 리뷰를 해줘야한다. PR이 없으면 그냥 push해야하는데 아까말한 좋지않은 사이클이 발생.
-
PR은 오픈되거나 클로즈되거나 머지되어도 이슈를 링크할수있다. 추가적으로 관련된 정보들을 연결지어줄수있다는 말.
-
특정 브랜치로 revert하고 싶으면 어떡하냐? PR페이지에서 브랜치를 삭제했더라도 Restore하는 버튼이있다.
