「마이크로서비스 & 파이어베이스 CI·CD」(3) github 설정
MicroFront 워크플로를 요약하면 위와 같다.
개발 회사는 각 로컬에서 리액트, 뷰, 앵글러, 바닐라(뭐든 상관없음)로 개발하여 웹팩으로 빌드를 실행한다. 각 개발팀 위치와 인력은 프랜차이즈처럼 언제든 교체 가능하며, 위치도 상관없다. 개발1팀(배포팀)이 알려준 깃허브의 프로젝트와 파이어베이스 프로젝트 id, key만 있다면, 그것으로 각 개발팀은 1개의 프로젝트를 진행하는 회사의 팀이다.
그리고 지난 포스팅(2)에서는 webpack.dev.js까지 생성했으므로 MicroFront개발의 첫번째 단계까지 완성했다.
첫 번째 단계에서는 회사(로컬)에서 자체적으로 모듈을 테스트 할 수 있지만 타팀과 협력이 되지 않는 까막눈 상태다. 모놀리틱 서비스에서는 이 단계에서 github & AWS or Firebase(클라우드)와 연결한 후 MVP(최소기능제품)를 런칭하면 된다. 단, 모놀리틱 개발환경은 개발자 변경(팀 변화)에 취약하므로 가능하다면 프로젝트 초기부터 Micro개발환경을 구축하는 편이 좋다.
1] 지속적 배포 & 개발 (feat. gitHub Action, Firebase)
MicroFront환경에서 깃허브 액션을 이용하는 이유는 다음과 같다.
위의 'container(배포팀)', 'marketing', 'dashboard', 'auth' 4개의 팀은 모두 다른 국가에 있으며, 시간차로 웹팩 빌드를 실행한다고 가정해보자. 그리고 각 팀은 코드가 완성되면, 배포팀(container)에게 usb로 메일을 전송해야 한다. 이와 같은 상황에서 정리 능력이 상당히 뛰어난 관리자가 배포팀을 맡아할 것이다. 각 팀에서 롤벡(구버전으로 되돌림) 요청이 올 때마다 container 폴더와 다시 연결시켜야 하기 때문이다. 물론, 위와 같이 4개의 팀 정도는 usb로 파일을 전송하는 수준에서 충분히 관리할 수 있을 것이다.
하지만 배포팀이 30여 개의 개발팀을 총괄해야 한다면? 아마도 'x팀'의 버전 요청을 처리(배포)하던 중, 또 다른 팀의 요청을 빠뜨리거나 중복하는 일이 비일비재 할 것이다. 이때 필요한 서비스가 바로 'gitHub & gitHub Action'이다.
각 개발팀의 저장소를 github과 연결한 후, 빌드를 할 때마다 github에서 버전을 업데이트를 진행한다. 이때 github과 연결할 수 있는 AWS, 에저, 파이어베이스와 같은 클라우드 호스팅은 그 결과를 배포하는 역할을 담당한다. 이른바 CI, CD(지속적 배포, 통합) 워크플로다.
2] github 계정 설정
github에서 저장소를 생성한다.
로컬에서 작업중인 최상위 폴더에서 git 초기화를 진행한다.
github 업로드에서 불필요한 파일을 제외시켜 준다.
3] github 업로드
**github push과정: 참고사항(git사용에 익숙한 개발자라면 볼 필요 없음**)
git에서 github으로 파일을 업로드 하려면, 먼저 git 스테이지, 커밋 상태를 확인한 뒤에 아래 순서로 진행한다.
github Action 연동 부분은 다음 포스팅에서 진행해보자.