[오늘 하루 회고] 2019-11-11

🌈 오늘 한 일

• 개발환경 prototyping

• travis CI, docker 조사

 

부스트캠프 멤버쉽 그룹프로젝트 기획 주가 끝나고 본격적인 개발 주가 시작되었다.

 

아직 개발환경설정이나 feature도출이 완벽하게 끝난 상태가 아니라서 팀원과의 이야기를 통해 우리가 이번주에 무엇을 해야할지 차근차근 정리해보았다.

 

이야기해본 결과 이번주 스프린트를 1차, 2차로 나누어 진행하고 1차 스프린트에서는 개발을 본격적으로 시작하기 위한 셋팅 과 미흡한 문서작성을 진행하고 2차 스프린트에서 다시 논의 하기로 결정했다.

 

내가 분담한 역할은 팀원들의 빠른 개발을 위해 docker를 이용한 개발환경 셋팅과 CI/CD 구축을 담당했다.

 

평소에 docker가 편하다고 느끼고 있었지만 그만큼 어렵다고 생각을 했고, CI/CD라는 개념자체에 대해서 생소하기에 많은 어려움이 있을 것이라고 생각했다...

 

---

 

⚡️ CI? CD?

• CI는 Continuous Integration(지속적인 통합)을 의미하며 코드 변경사항을 지속적으로 빌드하고 테스트 한 뒤, 이를 프로젝트 저장소에 반영하여 팀원간에 충돌할 수 있는 문제를 자동화해주는 것을 의미한다.

• CD는 Continuous Delivery(지속적인 제공) 또는 Continuous Deployment(지속적인 배포)를 의미하며 말그대로 배포의 자동화를 의미한다.

• 내가 의미한 바로는 빌드/테스트/배포 과정을 자동화하여 개발자들이 자신의 개발사항을 즉각적으로 서비스화 되는 것을 돕는 과정이라고 생각한다.

참고 사이트

 

⚡️ 프로젝트 인프라 구성

• CI/CD환경 구축하기전 우리 팀의 프로젝트에서 필요로하는 인프라 구성을 다시 정리해 볼 필요가 있다고 생각했다.

• 총 6개의 물리서버를 구성할 계획

• nginx + cocode client + coconut client + api server + live server + db server

 

• 프로젝트를 진행하면서 CDN, 캐싱서버 추가에 따른 인프라 증축이 필요할 것으로 예상됨(2019-11-11 글쓰는 당일)

 

⚡️ 개발에만 집중할 수 있는 개발환경 구축

• 6개의 service로 구성된 프로젝트이므로 각각의 service마다 다른 환경설정을 하는 것도 많은 수고가 필요하다고 생각함

• 팀원들 모두 각각의 로컬환경에서 개발환경을 구축한다고 했을 때 혹시라도 설정한 버전이나 의존성이 일치하지 않을 수도 있음

• docker-compose로 개발환경을 구축하여 온전히 개발에만 집중할 수 있는 환경을 제공하고자 함

• docker-compose로 구성한 Nginx + React + Express + MongoDB 예제 project를 prototyping 해봄

• https://github.com/YukJiSoo/practice-boilerplate-monorepo

 

⚡️ Work flow

• 아직 브랜치 전략이 세워지지 않았지만 일반적인 case인 git-flow를 참고하여 임시적인 flow를 가정

• travis에 대해서 정확하게 알고 있는 상태는 아니지만 나름대로 아는 내용을 토대로 정리해보았다

feature => develop

1. 각자의 로컬에서 feature 브랜치를 생성하고 개발을 진행

2. feature 구현이 완료되면 develop branch로 PR을 보냄

3. travis 에서 pull request에 hook을 걸어 놓은 상태이므로 CI과정이 진행

4. travis에 통과 + 모든 팀원의 리뷰를 받으면 merge request

5. travis 에서 merge request에 hook을 걸어 놓은 상태이므로 자동배포가 진행됨

6. 개발서버 배포 완료

develop => release

1. 한주의 sprint 마무리 시, develop의 작업사항을 release에 merge

2. travis 에서 hook을 걸어 놓은 상태이므로 merge시에 자동배포가 진행됨

3. 운영서버 배포 완료

4. master와 develop에서 merge

 

⚡️ 고민점

1. docker-compose로 local 개발환경을 구성하려고 하는데 효율적인 방법인지? 개발과 배포단계를 어떻게 구별할 지?

2. 총 6개의 물리서버가 필요하고 더 추가될 여지가 있는데(CDN, Caching) 개발 서버, 운영 서버 총 12개의 물리 서버를 관리가 가능?

3. monorepo로 프로젝트가 관리 되는데, 하나의 project에서 변경사항이 생긴경우 해당 project만 배포를 하게 할 수 있는지?

 

⚡️ [해결] Docker-compose로 local 개발환경을 구성하려고 하는데 효율적인 방법인지? 개발과 배포단계를 어떻게 구별할 지?

• 프로젝트의 서비스 별로 docker 파일을 작성

• 이 파일들을 하나로 묶어주는 docker-compose file을 작성

• 해당 파일은 개발 단계에서 로컬에 모든 서비스 컨테이너가 생성되는 편리함을 제공해주기 위해 필요함

• 배포단계에서는 travis에서 변경사항이 생긴 서비스만 docker hub에 image를 배포하도록 함

 

⚡️ [고민중] 총 6개의 물리서버가 필요하고 더 추가될 여지가 있는데(CDN, Caching) 개발 서버, 운영 서버 총 12개의 물리 서버를 관리가 가능?

• 왜 고민하는가?

  • 너무 자원낭비가 아닌가

  • 제한된 크레딧

  • 한정된 기간과 프로젝트의 취지상 굳이 개발서버까지 운영해볼 필요가 있을 까 생각

• 팀원과 이야기를 통해서 결과를 도출해내보자

 

⚡️ [고민중] monorepo로 프로젝트가 관리 되는데, 하나의 project에서 변경사항이 생긴경우 해당 project만 배포를 하게 할 수 있는지?

• travis에서 변경사항이 존재하는 서비스 프로젝트만 감지하는 방법이 있지 않을까?

• 특정 디렉토리에 최근 변경사항이 존재하면 해당 프로젝트를 검사하고 배포하는 shell script를 짜는지?