3차 스프린트 회고

1. 전반적인 사건들
   1. 중간 발표가 일주일 앞으로 다가왔다.
   2. 하지만 잦은 아키텍처 변경으로 인해… MVP를 뽑아내지 못했다.
   3. 그렇기 때문에 일단 이번 스프린트 까지만 우리의 삶을 조금 더 갈아보기로 했다.(다음엔 안 그럴 것 같진 않다.)
2. 스프린트 목표
   1. Cycle Time을 뽑아내고, 그걸 보여주자.
   2. 우리의 기술은 DataPipeline. 물론 UI도 중요하긴 한데, 가장 중요한 것은 데이터를 우리가 얼마나 납득할 수 있을만한 객관성을 가진 채로 뽑아내고 보여 주는가? 였다.
   3. 당초 계획은 지라, 젠킨스 등에서 webhook을 받고, 이걸 한꺼번에 처리하자~ 였는데, 일단 모든 곳에서 들어오는 서로 다른 방식의 데이터를 한꺼번에 처리하자! 라는 것은 개발에 소요될 우리의 삶이 너무나 불쌍해 보였고, 된다고 하더라도 그것을 연동하기 위해서 노력하는 상상 속 우리의 사용자들이 우리의 머리채를 잡아 뜯는 것 같은 기분이 들었다.
   4. 그렇기 때문에 Cycle Time에서 사용될 Deploy Event, 그리고 MTTR(Mean Time To Recover)/CFR(change failure rate)을 계산하기 위해 사용될 Event를 Github 안에서 구하기로 했다.
3. 기술적인 목표들과 시련들
   1. MTTR(Mean Time To Recover)
      1. 이것은 무엇인가.
      2. 서버가 죽었을 때. 회복까지 얼마나 걸리냐 라는 지표.
      3. 다른 서비스는 두 가지 방식 중 하나를 차용한다.
         1. Cloud Ocastration Service(살아있나 죽어있나)
         2. JIRA Issue
      4. 하지만 우리는 이를 GitHub Issue 발생, 그리고 Deploymen와 관련한 Label을 자동으로 생성하여 처리할 수 있도록 한다.
         1. 회복은 Label 된 Issue의 Close Time으로 정한다.
   2. CFR(Change Failure Rate)
      1. 코드가 변경되었을 때, 이것이 몇 번 실패했는가? 라는 지표.
      2. 어떻게 처리 해야 할까.
      3. 실패에는 여러가지가 있을 것 같은데
         1. 본 서버 갔더니 원하는 값을 내지 않는 이슈
         2. 값을 잘 내오긴 하는데 시스템//Product에 원하지 않는 영향을 미치는 이슈
         3. 이 경우 hotfix 이전에 이슈가 올라오겠지.
      4. 우리는 배포를 할 때 MTTR와 유사하게 관련한 이슈를 만들고, 이슈로 처리한다.
   3. Deduplication 문제
      1. HTTP Trigger(Listener) → Event Hubs 의 Data Movement이 일어날 때 데이터의 중복이 일어날 수 있다.(왜 재 전송 하는 거지?)
      2. Stream Analistic → Inserter//Parser 로 Data Movement가 일어날 때 데이터의 중복이 일어날 수 있다.
      3. 뭐 둘 다 지금은 SQL Database Unique Column을 통해서 해결하고는 있다만… 이것은 잘못된 것임을 알고 있다.
      4. 그렇기 때문에 중간에 Deduplication을 해줄 구조가 필요했다.
      5. Redis를 Queue로 두고 처리해라 라는 한 멘토님의 의견이 있었으나, 지금 당장은 Stream Analystics에서 처리하고 Unique 키로 버티기로 했다. 
   4. Github action을 통한 배포 파이프라인 구축
      1. 내가 그냥 전적으로 맡은 부분이었다.
      2. 우리가 사용하고 있는 언어 스택은 Js(Node.js, Vue.js)//java(MVN, Gradle Spring boot) 이다.
      3. 그리고 배포 목적지는 Function//WebApp이다. 쉽지가 않다.
      4. 일단 Github Action에 대한 개념을 조금 정리할 필요가 있었다. Jenkins처럼 확장팩을 사용하는 방식이긴 한데 조금은 달라서 말이다.
      5. 결국은 다 해냈다. main에 push할 때 자동으로 배포되는 것으로 정했다.
         1. 어느정도는 불만이 있는게, 이것을 고도화 하는 것이 나에게는 중요한 일이지만 우리 팀원들의 경우엔 아닌가 보다. 그렇지 뭐… 당장 개발이 힘든데 배포 파이프라인이 뭐가 중요하겠냐 싶긴 하다.
         2. 개발이 좀 안정될 때 다시 시도해봐야겠다.

 

1. 리뷰
   1. 전반적으로 팀원들의 요구 사항과 내 요구 사항을 맞추기가 힘들다고 생각한 스프린트였다.
      1. 팀원들은 어찌 되었든 자신들이 납득할만한 Product를 만드는 것에 집중하고 있었고, 나는 다양한 경험을 해보면서 내가 집중하는 reliable architecture를 구현하고, 내 삶을 조금 더 즐기고 싶다는 욕구가 있었다.
      2. 아무래도… 다수의 의견을 따라갈 수 밖에 없게 되었다. reliable architecture, 그리고 내 삶 모두 어느 정도는 반납하게 되었다. 피곤해 죽겠다. 다음 학기에 천천히 업그레이드 할 것이다.
   2. 대충 많이 진행되고 있다는 것을 보여 줄만한 결과물을 뽑기는 했으나, 문제가 여러가지 있었고 이것은 다음 스프린트에서 처리하기로 했다.
   3. 다음 스프린트에서는 내가 중간 발표를 진행하기로 했다. 야호…! 대신 개발은 잠깐 손 놓는 것으로 진행할 예정이다.

마지막 목표인 Pipeline