Techtalk at Vingle 1

CI / CD, Microservice As A Tool

• CI / CD , 마이크로서비스아키텍쳐 모두 도구일뿐 목적이 되면 안된다.

1. 문제점

• 배포

  • 이전까진 모놀리틱 앱 - 모든 코드가 레일즈 프로젝트 하나에 들어있었다.

  • 때문에 배포도 전체 코드 - 프로젝트가 커지면서 시간등이 많이 걸림.

  • 테스트를 통과한 master도 production에 올려도 문제가 없는지 아무도 모른다.

  • 배포단위가 커지다 보니 QA시간도 오래걸리고 이전 QA가 끝나지 않아서 배포할 수 없는 경우도 생긴다.

    코드는 사용자에게 배포되기 전까진 아직 아무런가치도 만들어 내지 않은 것 이다. -Vingle

• 혁신

  • 레일즈 기반의 모놀리틱 앱이기 때문에 새로운 기술 도입에 제약이 많다.

  • 같은 이유로 기술 도입을위한 프론트엔드 라이브러리 추가시 서버까지 죽는 등의 리스크가 너무 크다.

  • 각자의 핵심 역량과 상관 없는 것들을 알아야한다. - 프론트엔드 개발자도 루비를 할 줄 알아야 함.

  • 결국 생산성이 떨어짐.

    기술 혁신이 없으면 그게 왜 IT 회사냐 - Vingle

1. 목표

   1. 멋있지만 추상적인

      • 빠른 배포

        • 안전하고
        • 빠르고
        • 코드 퀄리티 있고
        • 작게

      • 빠른 혁신

        • 새로운 기술에 높은 접근성
        • 최소의 리스크

   2. 길지만 구체적인

      • 혁신

        • 러닝커브를 낮추자.
        • 기술 도입에 대한 유연성을 높이자 - 리스크를 낮추고 다른 서비스에 영향을 끼치지 않도록.
        • 프로젝트를 쪼개자 - 종속성, 배포, 스케일링, 모니터링, 기술 스택, 코드 베이스

      배포는 CI / CD로 혁신은 Microservice로

CI / CD

1. 진행하는 모든 프로젝트들에 CI / CD Pipeline 정의

   • Checkout - git checkout ${branch}
   • Dependecy - npm install
   • Test - npm run test
   • Lint - npm run lint
   • Build - npm run build
   • Deploy:staging - npm run deploy:stage
   • Deploy:production - npm run deploy:prod

   젠킨스를 사용해 CI를 한다.

Microservice Architecture

• 레일즈에 API 로직만 남기고 모든 피쳐 분리.

• 마이크로서비스의 조건 - 자생, 협업 가능, 비즈니스 도메인을 기반한 모델

• 다음의 조건을 만족하는 템필릿이 필요

  • 쉬운 확장
  • 배포
  • 모니터링
  • 적당한 사이즈로 쪼개진 서비스
  • 쉬운 서비스간 통신

결국 AWS Lambda + APIGateway를 ServerLess 프레임워크로 묶어서 관리. 타입 스크립트도 사용하자.

• 직면하게 된 문제들은 젠킨스를 이용해 해결했다.

팀의 수준에 맞는 결과가 나온다.

• 필요없다면 굳이 쓸 필요가 없다.

  • B2B 서비스라 자주 배포할 필요가 없다면?
  • 안전하게 배포할 수 있는 시간이 정해져 있다면?
  • 팀원들이 모두 전문분야가 비슷하다면?
  • 팀원들이 코드리뷰하는걸 부담스러워 한다면?
  • 모든 QA가 개발 환경에서 가능하다면?

---

2023년 새해에는 성장하고 함께하고 싶다면?

Pre A 단계 이상의 스타트업 C 레벨들이 모여서 커뮤니티를 만들었습니다. 같이 스터디하고 친해질 일잘러를 찾습니다.