스프린트3 회고

스프린트 3 시작!

스프린트 3 구현 기능 정하기

스프린트 2 데모 데이 때 받았던 피드백을 반영하여, 각자 스프린트 3에서 구현하면 좋을 것 같은 내용을 회의 전에 내었다.

스프린트3 기능 · Discussion #157 · woowacourse-teams/2022-sokdak

논의해 볼 기능 사항

• 게시판 분리 - 확정
• 게시판 분리 (포수타, 감동크루, 자유게시판)
• 댓글 수정, 삭제
• 인기글 순서대로 보기
• 키워드 검색
• 해시태그 검색
• 어드민 계정 (모든 글 삭제 가능)
• 신고 기능
• 내가 쓴 글/댓글 모아보기
  • 프로필 페이지
• 자동 로그인 기능 - 미정
• 댓글 추천 기능
  • 베스트 댓글 선정 기능
• 사진 업로드 기능
• 대댓글 create, read
• 프론트 CI/CD와 dev서버와 운영서버 분리

위와 같은 의견들이 나왔고, 토론을 통해서 아래와 같이 스프린트 3 기능을 정했다.

스프린트 3 구현 사항

• 게시판 분리
  • 코치와의 수다타임 게시판
  • 감동 크루 제보 게시판
  • 인기게시판
  • 자유게시판
• 인기 게시판
• 댓글 삭제
• 신고기능(게시글, 댓글)
  • 게시물에 대한 신고를 한 후 게시물에 대한 신고가 다섯개 이상 들어온다면 일시적 블라인드 처리
  • 후에 관리자가 검토를 진행한 후 글 삭제를 결정한다.
  • 신고로 인한 글 삭제가 다섯번 이상인 회원에 관하여 영구 정지를 결정한다.
• 글 작성시 익명/기명 선택
• 해시태그 검색 + 해시태그 리팩토링
• 해시태그 인기순으로 보여주기
• 자동 로그인 기능 - 로그아웃 (이스트)
• HTTPS
• 프론트 CI/CD와 dev서버와 운영서버 분리
• Github actions 으로 github 상에서 빌드, 테스트를 하고 성공하면 젠킨스가 배포하도록 구현

다음주에 여유가 생기면 구현할 것

• 프로필 페이지

• 대댓글

  사실 조금 많아보일 수 있다. 우리 팀은 스프린트1, 2 총 4주 동안 3주 몹프로그래밍, 1주 페어프로그래밍으로 진행해왔다. 하지만, 이번에는 개인 단위로 개발을 하고 코드 리뷰를 받는 형식으로 개발을 진행하기로 했기 때문에, 충분히 구현을 할 수 있을 것이라고 판단하고 위와 같은 기능들을 구현하기로 결정했다.

디자인

디자인 작업은 이번에도 역시 프론트와 백이 함께 진행했다!

API 요청을 나눠서 보내야 할까? 한번에 보내야 할까?

메인 페이지에 대한 API를 함께 작성하는 중, 의견이 갈리는 부분이 있었다.

1. 핫 게시판, 포수타, 감동 크루, 자유게시판이 모두 같은 형식의 요청이기 때문에
   쿼리스트링을 통해서 어떤 게시판에 대한 요청인지를 명시하고 4번의 요청을 보내자.
   (핫 게시판 한번, 포수타 한번, 감동크루 한번, 자유게시판 한번)

2. 그냥 API 요청을 한번만 보내서, 4개의 게시판 정보가 모두 응답되도록 하자.

   이에 대한 열띤 토론이 있었다. 우리는 저번 주 회고에서 이슈에 대한 문서화가 부족했다는 의견이 나와서, 이번 주의 액션 플랜을 이슈에 대한 문서화 잘하기로 정했다. 따라서 위의 토론 내용을 기록했다.

메인페이지 API 로직 분리 관련 · Discussion #243 · woowacourse-teams/2022-sokdak

충분한 토론과 설득을 통해 위와 같은 의견이 나왔고, 각자 생각할 시간을 잠시 가지고 투표를 통해 정했다.

API를 한번에 요청하기로 결정했다.

해당 의견이 채택된 결정적인 이유는 아래와 같다.

• 메인페이지에서 보여줄 게시판 개수가 늘어나면, 그에 따라 요청이 늘어날 것이다.
• 보통은 메인페이지의 정보를 서버에서 응답해주고, 프론트의 다음 요청 때 서버에서 응답한 정보를 통해 요청을 보낸다. 하지만, 처음부터 서버에게 구체적인 요청을 보내려고 하면, 프론트엔드에서 ‘포수타, HOT, 자유게시판' 등의 값을 가지고 있어야 한다. 서버에서 메인페이지의 모든 정보를 응답해주면 자연스럽게 데이터가 동기화되지만, 포수타, HOT 등의 값을 프론트-백 사이의 약속으로 둔다면 동기화를 수동적으로 하는 것이라고 생각한다.

닉네임 관련 이슈

저번 데모 때, 회원 정보 입력란에 닉네임을 적으면 익명성이 보장할 수 없지 않냐는 피드백이 있었다.

우리는 우테코의 닉네임이 아닌, 본인이 속닥속닥 커뮤니티에서 활동할 닉네임을 의도한 것이다. 하지만, 충분히 크루들이 오해할 수 있겠다고 생각을 해서, 회의를 통해 회원가입의 닉네임을 적는 란에 아래와 같은 안내문을 띄워주기로 했다.

동키콩… 헤칠 수 없습니다. 오타 고쳐줘…

시멘틱 버저닝

실제 배포를 할 계획이 있어서, 시멘틱 버저닝을 어떻게 관리할 것인지에 대한 회의가 있었다.

회의 후, 아래와 같이 시멘틱 버저닝을 정의하기로 했다.

0.0.0 제일 앞자리 부터 메이저, 마이너, 패치이다.

메이저

기존의 사용자 플로우 대폭 변경 및 서비스의 성격 대폭 변화

마이너

기존의 사용자 플로우 내에서의 기능 추가 및 제거

패치

UI 스타일 변경, 사소한 버그 픽스와 같은 작은 변경

RestDocs

기존에 api를 노션으로 관리했다. 이제는, 노션에 더해 Controller의 슬라이스 테스트를 통해 RestDocs를 적용하였다.

처음 api를 정할 때부터 Controller Test를 작성하기가 버겁기 때문에 노션이 빠르게 정할 수 있다는 장점이 있다.

하지만, RestDocs는 실제 동작하는 코드를 기반으로 API 문서를 추출해주기 때문에, 휴먼 에러를 보다 잘 잡을 수 있다는 장점이 있는 것 같다. 그리고 무엇보다 보기가 깔끔하다.

Jenkins를 사용한 CI/CD

이번 스프린트에서 CI/CD를 맡았다. Jenkins에서 branch를 자동으로 분기처리해주는 multibranch pipeline를 통해 CI/CD 환경을 구축하였다.

Jenkins의 Mulitbranch Pipeline을 통한 CI/CD

CI/CD를 진행하면서 Multibranch pipeline에 대한 레퍼런스가 너무 없어서 고생도 했고, multibranch pipeline 자체를 이해하는 것도 시간이 오래 걸렸다.

Multi Branch Pipeline Job using Jenkins | Tech Primers

위의 유튜브 영상을 보고 multibranch pipeline이 뭔지에 대해서 이해했다.

그렇게 Multibranch pipeline 환경을 구축했는데

Jenkins EC2에서 실제 Spring이 구동되는 EC2에 ssh를 통해 접속해서 deploy.sh를 실행하는 것에 난항을 겪었다. 아래와 같은 이유였다.

Jenkins에서 deploy.sh가 실행이 잘 안되네..

프론트 CI/CD를 함께 진행하다.

프론트엔드 CI/CD를 무비와 함께 진행하였는데, 프론트엔트의 명령어들을 함께 치고 프론트엔트 코드들을 보면서, 프론트에 대해 많이 알 수 있는 시간이 있어서 좋았다. webpack, package.json, .env 파일 등등…

프론트에 대해서 어느 정도 알아야 협업을 하는데 수월하다는 것을 느낀다. 그래서 더더욱 프론트에 대해서 알려고 한다. 내 기능 개발을 하는 것도 바쁘지만, 프론트와의 페어프로그래밍이 필수 요구사항이라서 프론트와 함께 코드나 인프라를 구축하는 시간이 있다. 프론트에 대해 알 수 있어서 좋다~!

HTTPS

이번 스프린트에서 HTTPS도 담당하게 되었다.

HTTPS 적용기

확장성과 간편함 때문에 Nginx를 통해서 HTTPS를 적용했는데, 나중에 Nginx로 로드밸런싱하는 것도 재밌을 것 같다. 그건 레벨 4때!!!!

1.0.0 배포!!!

빨리 배포를 하고 싶은 마음이 있고, 주요 기능들이 개발되어서 main에 merge를 시키고, 팀원들과 배포를 하기로 결정했다!

실제로 우리가 만든 서비스를 크루들이 재밌게 사용하는 것을 보니, 신기하기도하고… 벅차오르기도 하고…

또, 크루들이 제보해주는 버그들을 알 수 있어서 좋았다. 빠르게 개선가즈아~!

데모데이

동키콩이랑 헌치가 데모데이 발표를 너무 잘해주었다!!!! 짱짱!!!!

회고

팀 회고

우리가 잘한 점

• 이번 스프린트도 사이좋게 잘지냈다!
• 계획한 모든 기능을 구현했다.
• 1.0.0을 배포했다
• 백엔드와 프론트엔드의 소통이 잘 이루어졌다.

아쉬운 점

• 메인 배포가 늦어져서, 저번 데모 처럼 데모데이 당일날까지 디버깅을 했다.
• 깃에 대한 지식이 부족해서, 깃 관련 문제가 발생했는데 원인을 파악하지 못했고 해결하는데도 시간이 좀 걸렸다.
• 깃 관리가 잘 안된다. 실수로 dev에 push를 하는 경우도 있다.
• 테스트 코드를 더 꼼꼼하게 짜지 못해서, QA를 할 때 버그를 알아차렸다.
• 기존의 코드에 레거시가 아직 존재한다.
• 백엔드에 한해서, 각자 기능을 구현한다고 서로의 구현 사항과 구현 방식을 공유하는 시간이 부족했다.

액션 플랜

• 스프린트 2에서 나왔던 것처럼, 중간중간에 백과 프론트의 연결을 해보자!
• 깃 스터디를 진행하자!
• 백엔드는 기존의 스터디를 하고 나서, 기술 회고 시간을 가지자.
• 테스트 코드를 더욱 깔끔하게 짜도록 노력하자.
• 유의미한 피드백을 더욱 많이 주자. 반영하지 않아도 된다. 하지만, 다른 관점을 제공할 수 있다.
• dev 브랜치에 push가 되지 않게 막자.

개인 회고

CI/CD와 HTTPS를 해내어서 다행이다. 팀원들이 고생한다고 격려도 해주고 칭찬도 해줘서, 힘내서 진행할 수 있었다. 또한, 팀원들이 Infra를 혼자하면 힘들 것이라고 말했지만, 우리 팀원들 중 누구든지 내가 맡은 임무를 잘 수행했을 것이다. 그래도 격려와 칭찬을 받으니 좋았다. 나도 팀원들을 더 칭찬하고 격려해줘야겠다.

이번에, Infra를 쭉 진행하고, 스프린트 후반에 Java 코드를 3시간 정도 쳤다. 2주동안, Java-Spring-JPA와 조금 멀어진 것 같아서 아쉽다. 스프린트 4에는 Java 코드를 많이 치고, JPA와 Spring에 대한 고민과 공부를 하고 싶다.

Multibranch pipeline으로 CI/CD를 구축했다. 그런데 관련 포스팅에서도 말했듯이, CI/CD가 구축될 수록 Multibranch pipeline에 대한 단점이 드러났다. 구축하는데 애도 먹고, 끙끙대서 그냥 pipeline으로 바꿔야한다는 생각을 조금은 부정했던 것 같다. 하지만, 변화를 두려워하면 안된다는 생각이 들었다. 더 나은 것이 있다면, 이때까지의 기회비용을 고려하지 않고 과감하게 변화해야한다. 지금은 multibranch pipeline으로 두어도 괜찮다는 생각이 들지만, pipeline으로 바꿔야하는 상황이 된다면 과감하게 바꾸자!

팀원들과 갈 수록 돈독해짐에 감사하다. 다들 너무 좋은 사람들이다. 나도 더 좋은 사람, 더 많은 것을 공유할 수 있는 사람이 되어 팀원들과 좋은 영향과 도움을 주고 싶다.