[6주차] 한상진 코치님 발제 : CI/CD 배포 파이프라인 구축

[테스트 코드는 왕이다]

내가 개발한게 잘 동작하는지 확인하기 위해서는 e2e, 통합테스트를 해야한다. 

현재 한상진 코치님 사내에서 거대한 리팩토링을 진행중. 테스트코드가 완벽하게 구현되어 있고, 심지어 if문마다 테스트코드가 있다.

그래서 리팩토링하는 개발자가 리팩토링하면서 기능의 정확성이 보장되는지 판단할 수 있다.

테스트코드를 잘 작성하고, 꼼꼼하게 작성하는것은 매우 필요하다.

 

테스트코드 작성하는게 시간이 오래 걸린다? => 장기적으로 테스트코드를 작성하는게 시간을 절약해준다. 그렇지 않다면 PostMan으로 매번 수동으로 해야한다.

 

[소프트웨어 아키텍쳐의 핵심은 책임과 의존이다]

책임 : 해당 프로그램의 기능

 

[서버구축 마무리 하면서]

 

 

맛집검색 서비스에 대한 리뷰

- API 1개에만 의존하다보면 장애가 발생하면 어떻게 해야하는가?에 대해서 집중해서 고민하는 것이 중요했다.

- SPOF 단일 장애지점(카카오API가 장애가 났을 때) - 다른 API를 호출하는 것을 고려한다. 이게 서킷 브레이커

- 트래픽을 카카오API, 네이버 API로 5:5 나눠서 보내는 방법도 있다.

- 서버가 죽었는데 사용자로부터 계속 요청이 들어오는 것은 도움이 안된다.

- 실시간 검색키워드 기능

 

콘서트 예약시스템 리뷰

- 일반적으로 수만명이 몰릴 떄 로그인에서 터져버린다.

- 그래서 로그인에 들어오기 전에 대기열에 넣어버린다.

- 낙관적락은 어플리케이션에서 구현되는 것.

낙관적락을 활용하되 re try 없이 하는게 DB에 부하를 줄인다.

 

[CI/CD 기초 학습]

- 지속적 통합

당장 사용하지 않는 변수에 대한 에러 등 여러 사람들이 직접 눈으로 확인한다면 큰 리소스와 시간이 든다.

 

[CI의 중요성]

CI가 중요한 이유는 우리가 눈으로 코드를 리뷰하는 것은 한계가 있다.

테스트 실패 또는 코드 규칙 위반 같은 것은 실수로 넘어갈 수도 있다.

 

[린트란 무엇인가?]

코드도 보풀이 있는 코드도 돌아간다. 하지만 이 코드를 우리가 깔끔하게 만드려면 코드에 있는 보풀(lint)를 제거해야한다.

우리가 스웨터의 보풀을 한땀 한땀 제거한다면, 대체 몇 시간이 걸릴까??

그렇기 떄문에 우리는 보풀 제거기라는 도구를 사용하는데 이게 Linter이다.

 

[CD를 위해서 도커를 사용하는 이유?]

도커를 사용하는 이유는 맥컴퓨터, 윈도우에 상관 없이 도커에만 있다면 어디에서 배포하든 동일하게 환경 유지.

 

운영 중인 서버에 코드를 한줄 수정하는 것이 안전할까?

이 서버가 꺼지고 켜지는 동안 유저가 있다면 우리 사이트에 접속을 하지 못한다.

우리는 배포 과정을 자동화 해야 한다.

 

[Semantic Versioning]

패치 버전 : 버그가 수정되었을 때 패치버전이 올라간다.

 

[서버 환경 분리]

- 개발과 운영서버를 분리한다.

- 

 

[과제]

PR이 올라갔을 때의 github flow, PR이 머지 되었을 때 github flow