[우아한 테크코스 3기] LEVEL 3 회고 (193일차)

안녕하세요? 제이온입니다.

 

레벨 3도 이제 하루 밖에 남지 않았습니다. 우리 팀은 최종 스프린트 동안 계획한 기능들을 대부분 구현해서 이번 주는 상대적으로 여유로웠습니다. 저만 그런 건지는 모르겠는데, 덕분에 잘 쉬면서 기존 코드를 유지보수하였습니다. 몇 가지 이슈를 해결한 이야기와 main 브랜치로 develop 브랜치를 통합한 이야기 정도만 작성하려고 합니다.

 

 

댓글 통계 기능 이슈

문제 없이 잘 돌아간다고 생각했으나, 한 가지 버그가 생겼습니다. 바로, 사용자가 마지막 일 또는 마지막 달로 날짜를 조회했을 때 해당 마지막 일 또는 마지막 달에 댓글이 없다면 날짜 자체가 표시가 안 되는 것이죠. 정상 결과라면 "2021-08-01: 0개" 이런 식으로 나와야 합니다. 이것은 제가 반복문에서 실수가 있었습니다.

 

 

    while (!localDate.equals(end)) {
            if (isExistDailyStat(commentStats, localDate)) {
                continue;
            }
            noneMonthCommentStats.add(new CommentStat(localDate.toString(), DEFAULT_COMMENT_COUNT));
            localDate = localDate.plusDays(1L);

            if (localDate.equals(end) && !isExistDailyStat(commentStats, localDate)) {
                noneMonthCommentStats.add(new CommentStat(localDate.toString(), DEFAULT_COMMENT_COUNT));
            }
        }

 

 

이런 식으로 사용자가 시작 날짜로 입력한 localDate와 종료 날짜로 입력한 end를 비교하여 같지 않들 때까지 localDate를 다음 날로 올리는 방식으로 로직을 구현했습니다. 다만, 처음부터 localDate와 end의 값이 같을 수 있으므로 마지막 조건문을 아래로 내려 주었습니다.

 

 

    while (!localDate.equals(end)) {
            if (isExistDailyStat(commentStats, localDate)) {
                continue;
            }
            noneMonthCommentStats.add(new CommentStat(localDate.toString(), DEFAULT_COMMENT_COUNT));
            localDate = localDate.plusDays(1L);
        }
        if (!isExistDailyStat(commentStats, localDate)) {
            noneMonthCommentStats.add(new CommentStat(localDate.toString(), DEFAULT_COMMENT_COUNT));
        }

 

 

이런 식으로 마지막 날에는 댓글 데이터가 있는지 없는지 체크하여, 댓글 데이터가 없다면 해당 날짜에는 댓글이 0개있다고 표시하여 리스트에 담는 것입니다. 추가로, 굳이 저렇게 조건문을 뺄 수 밖에 없던 이유는 12월 다음에는 13월이 아니고 1월이 돌아가거나 31일 다음에는 1일로 돌아가는 현상이 있어서 그렇습니다.

 

 

운영 브랜치 통합

현재 우리는 develop/be와 develop/fe로 나누어서 개발을 진행하고 있고, 개발용 인프라가 따로 구축이 되어 있는 상태입니다. 그리고 QA도 어느 정도 진행돼서 이제는 운영 브랜치인 main으로 통합할 때가 왔습니다. 참고로 main에는 BE와 FE용 workflows를 따로 정의하고 pr이 날아오면 CI, push할 때는 CD가 작동하도록 만들어 두었습니다. 

 

이때 두 develop 브랜치를 합쳐서 main 브랜치로 pr을 날리기 위하여 release 브랜치를 임시로 생성했습니다. 그리고 release 브랜치는 develop/be로 부터 checkout을 하고 develop/fe를 pull 땡겼습니다. 다만, 여기서 문제가 발생했습니다.

 

develop/be와 develop/fe의 workflows 파일 내용이 달라서 컴플릭트가 생긴 것이죠. 그래서 저는 처음에 어차피 main 브랜치에서 안 쓰는 workflows들이니까 그냥 날려버리고 통합한 뒤 main 브랜치로 pr 날리는 방법을 택했습니다. 하지만, 제리는 나중에 통합할 때마다 컴플릭트가 발생하면 잘못 해결할 수도 있고 번거로우므로, main 브랜치에서 안 쓰는 파일이더라도 develop/be와 develop/fe의 충돌되는 파일 내용을 같게 해주자고 말했습니다. 저는 처음에 필요 없는 파일을 굳이 가질 필요가 있나 생각이 들었지만, 제 의견을 따르게 되었을 때 사이드 이펙트가 꽤 커서 제리의 의견을 따라갔습니다.

 

develop/be의 CI/CD는 젠킨스에서 동작하므로 pr이 merge되었을 때 자동으로 브랜치를 삭제하는 workflow만 develop/fe와 맞춰 주면 되었습니다.

 

 

name: Delete branch on close pr
on: 
  pull_request:
    types: [ closed ]
    branches: [ develop/be, develop/fe ]
  
jobs:
  delete-branch:
  
    runs-on: ubuntu-latest
    
    steps:
      - name: delete branch
        uses: SvanBoxel/delete-merged-branch@main
        env:
          GITHUB_TOKEN: ${{ secrets.MY_REPO_PAT }}

 

 

꽤나 간단합니다. branches를 develop/be, develop/fe로 맞춰 주는 것이죠.

 

다음으로, develop/fe의 CI / CD는 깃허브 액션이 작동합니다. 그래서 관련 workflows들이 존재합니다. 이것들도 main 브랜치에는 피해가 가지 않도록 적절히 수정했습니다. 원래는 크루들이 develop/fe가 아니라 실수로 main으로 보내게 되면 CI가 작동하지 않고, develop/fe로 경로를 바꿔도 CI가 작동하지 않는 불편함이 있었는데 이를 'edited' 키워드를 통해 해결했습니다.

 

 

name: Darass PR Checker [FE]

on:
  pull_request:
    types: [ opened, edited ]
    branches: [ develop/fe ]

 

 

이러한 pull_request 타입과 관련된 내용은 이곳에서 확인하실 수 있습니다.

 

 

이제 컴플릭트는 발생하지 않습니다. 그래서 마음 놓고 release 브랜치를 develop/be로부터 생성하고, develo/fe로부터 pull 땡기면 됩니다. 마지막으로 release 브랜치를 main 브랜치로 pr을 날리면 정상적으로 BE와 FE에 대해 CI가 작동하고, merge되면 둘다 배포가 됩니다.

 

 

정리

이제 정말 운영 서버에도 우리 프로젝트가 배포되었습니다. 아마 조만간 우리 다라쓰 팀에서 만든 댓글 모듈은 제 블로그에도 달아 볼 생각입니다.