(CICD) CICD 개선 일대기 - 1. 깃허브 액션과 슬랙을 연동시켜보자

CICD 개선 일대기

2022.12.11 - [프로젝트/웹] - (CICD) CICD 개선 일대기 - 1. 깃허브 액션과 슬랙을 연동시켜보자

2022.12.11 - [프로젝트/웹] - (CICD) CICD 개선 일대기 - 2. 깃허브 액션의 중복 코드를 없애보자

2022.12.12 - [프로젝트/웹] - (CICD) CICD 개선 일대기 - 3. 깃허브 액션 캐시로 node 빌드 속도를 높여보자

---

들어가기 전에

프로젝트가 궁금하신 분은 https://github.com/boostcampwm-2022/web06-weview를 방문해주세요~

GitHub - boostcampwm-2022/web06-weview: 함께하는 코드리뷰 커뮤니티 WeView 👨‍👨‍👦‍👦

---

제가 이번 프로젝트에서 처음 CI/CD를 도입할 때 가장 중요하게 생각한 점은 기본에 충실한 CI/CD를 구현하자였습니다.

 

일단 속도는 신경쓰지 않고 기본 기능인 빌드 및 테스트, 배포를 최소한으로 구현한 뒤 어떤 문제가 있는지 직접 경험해봐야 불편함을 알고 개선할 의지가 생긴다는 의도였습니다.

 

처음에는 편리함이 컸습니다. 프로젝트 시작이 11월 7일인 것을 감안하면 저희는 거의 시작과 동시에 CI/CD를 구현했기 때문입니다.

 

Pull Request를 작성하면 자동으로 빌드와 테스트가 동작하고, 브랜치에 합쳐지면 자동으로 배포가 되니 불편함을 느낄 수가 없었습니다.

 

그렇게 편리함에 익숙해진 채로 몇 주 동안 개발을 하다보니, 이전에는 느끼지 못했던 불편한 사항들이 하나둘씩 생기기 시작했습니다. 그 문제점들은 다음과 같습니다.

 

1. 좀 더 편리했으면 좋겠다.

2. 관리할 CI/CD 파일이 너무 많다.

3. 느리다.

 

기능 개발도 얼추 마무리가 됐고 문제점을 충분히 찾았으니 개선할 때가 됐다고 느낀 저는 개선 작업을 시작했습니다. 이번 글은 1. 좀 더 편리했으면 좋겠다. 에 관한 글입니다.

 

좀 더 편리했으면 좋겠다

앞서 말씀드렸다시피 저희의 처음 의도는 기본에 충실하자였습니다.

그래서 CI/CD를 빌드와 테스트, 배포 기능에 집중하여 구현했습니다. 문제는 정말 정직하게 빌드와 테스트, 배포만 한다는 것입니다.

 

빌드와 테스트, 배포는 자동으로 수행되니 그만큼 편리해진 건 맞지만, 한 번 편리함을 맛 본 저희는 다른 데에서도 편리해지기를 원했습니다. 예를 들면 Pull Request를 요청할 때나 리뷰가 달릴 때 알려주는 기능을요.

 

인간 깃허브 4명

저희는 여태까지 슬랙에 PR을 직접 링크하여 서로에게 리뷰를 요청했습니다. 아래처럼요.

 

만약 리뷰에 질문이라도 남긴다면 상대방이 이메일을 확인하고 답변을 달아줄 때까지 기약 없이 무작정 기다려야 했습니다. 만약 거기에 또 궁금한 점이 생긴다면?...

물론 슬랙에 링크 하나 올리는 건 어렵지 않습니다. 또한 잠자는 시간 빼고는 슬랙에 접속 중이기 때문에 리뷰를 오래 기다리지 않아도 됩니다.

 

하지만 저희가 직접 인간 깃허브가 되어 링크를 복붙하는 작업은 너무나도 단순하기 때문에 자동화하면 굉장히 맛있을 것이 분명했습니다.

 

오이시꾸나레 오이시꾸나레

알아보니 슬랙에서 공식적으로 깃허브 연동을 지원하고 있었습니다.

저희는 여태까지 슬랙 DM으로 소통했는데, 슬랙과 깃허브를 연동하기 위해서는 채널이 필요하기에 우선 슬랙에 채널을 만들었습니다.

공식적으로 지원하는 기능이기 때문에 적용하는 방법은 너무나 단순해서 굳이 적지 않겠습니다. 만약 궁금하시다면 아래 링크에서 앱 설치에 있는 3줄만 따라하면 됩니다.

https://slack.com/intl/ko-kr/help/articles/232289568-Slack%EC%9A%A9-GitHub

Slack용 GitHub

 

채널에 GitHub 앱을 추가하고 권한에 대한 동의를 한 뒤, 위 명령어를 입력하기만 하면 기본적으로 5개 기능에 대한 알림을 받을 수 있게 됩니다. 알림은 아래처럼 날라옵니다.

리뷰가 달리면 스레드로 추가되며, 추가적인 명령어를 통해 아래처럼 채널로 알리게 할 수도 있습니다.

 

지금도 충분히 맛있어졌지만, 저희는 더욱 맛있기를 원했습니다. workflow가 수행될 때도 알리도록 말입니다.

 

해당 기능은 기본 설정에 포함되어 있지 않기 때문에 명령어 한 줄을 추가적으로 입력하면 적용됩니다. 대신 슬랙에게 workflow에 대한 접근 권한을 허용해야 합니다.

또한 리뷰를 채널로 알리게 하는 기능도 권한 허용이 필요합니다. 그래서 권한을 변경하려고 보니…

 

갑자기 마주친 이슈

깃허브 저장소가 저희 소유가 아니기 때문에 권한을 변경하려면 관리자의 승인이 필요했습니다.

슬랙 DM인데 교수님께 이메일 보내듯 보낸 점은 양해 부탁드립니다. 누군가에게 부탁하는 건 아무리 해도 익숙해지지 않는 것 같습니다.

 

날짜를 보면 아시겠지만 새벽 1시였습니다. 그리고 이 날은 금요일. 따라서 저는 불금 새벽에 업무 관련 DM을 보낸 파렴치한이 되었습니다.

 

금방 처리되지는 않을 것이라고 판단한 저는 일단 workflow에 직접 구현하기로 했습니다.

 

깃허브 액션 쇼핑

깃허브 액션은 마켓플레이스를 지원해서 다른 사람들이 만든 액션을 라이브러리처럼 가져다 사용할 수 있습니다.

slack만 쳐도 225개의 검색 결과가 나옵니다. 그 중 슬랙에서 지원하는 slack-send를 사용하기로 했습니다.

 

권장되는 방법이라 바로 적용하려 했는데 유료 요금제에 멈칫했습니다. 확인 결과 부스트캠프 워크스페이스는 Pro 플랜이므로 적용이 가능했습니다.

 

위 기능은 슬랙의 workflow를 사용하는 것인데 방식은 간단합니다. workflow를 게시하면 생성되는 URL에 POST 요청을 보냈을 때 수행될 일련의 작업들을 정의하는 겁니다.

 

변수 텍스트는 요청의 Body로 전송되는 JSON의 key를 의미합니다. 아래처럼 생겼습니다.

저는 단순하게 URL로 요청이 오면 key 2개를 채널에 보내도록 했습니다.

target으로 깃허브 액션의 workflow 이름을 보내고, result로 해당 workflow가 성공했는지 실패했는지 보내도록요.

 

적용 방식

이제 깃허브 액션에 적용하는 일만 남았습니다. 그 전에 깃허브 액션의 secrets을 등록해줘야 합니다. 이 작업은 굉장히 단순합니다.

 

위에서 New repository secret을 누르고 SLACK_WEBHOOK_URL이라는 이름으로 슬랙 workflow URL을 등록하면 끝입니다.

 

이제 진짜 깃허브 액션에 적용하는 일만 남았습니다. 위에서 말했던 액션을 가져다 사용하기만 하면 됩니다. 저희 코드는 아래와 같습니다.

name: "개발 서버 자동 배포"
...
jobs:
  build-and-push:
    ...

  pull-and-run:
    ...

  notify-success:
    ...

  notify-failure:
    ...

저는 job을 분리하여 workflow를 구현했습니다. 이 부분도 편리함 개선에 해당하는데, 잠깐 설명드리고 슬랙 알림 부분을 마저 마무리하겠습니다.

 

시각화

저희가 job을 분리한 건 시각적인 측면에서였습니다. 무슨 의미냐면 깃허브 액션에서는 summary를 제공하고 있습니다.

위처럼 각 job을 그래프처럼 볼 수 있는데, 위 기능을 활용하고 싶었습니다. 하지만 약간의 단점이 있었습니다.

 

깃허브 액션의 job은 각각 별도의 환경에서 수행되어 여러 작업들을 병렬적으로 처리할 때 job을 분리하면 굉장히 유용합니다.

하지만 저희의 배포 workflow는 push → pull의 과정이기 때문에 순차적으로 수행되어야 합니다. 따라서 job을 분리할 경우 각 job이 수행될 때마다 환경을 세팅하는 시간이 추가적으로 소요됩니다.

 

저희는 위처럼 환경 세팅에 소요되는 시간이 1~2초에 불과한 것을 보고 충분히 감안할 수 있다고 판단하여 summary를 활용하기 위해 job을 분리했습니다. 분리하면 다음처럼 예쁜 그래프가 생깁니다.

 

따라서 어떤 단계에서 실패했는지 빌드 화면을 직접 보지 않아도 판단할 수 있게 되어 조금 더 편리해졌습니다.

 

다시 슬랙으로 돌아가서

저희의 workflow 파일에서 슬랙 액션에 관한 코드는 아래와 같습니다.

name: "개발 서버 자동 배포"
...

jobs:
  ...
  notify-success:
    runs-on: ubuntu-20.04
    needs: [build-and-push, pull-and-run]
    steps:
      - name: notify if Action succeeds
        uses: slackapi/slack-github-action@v1.23.0
        with:
          payload: |
            {
              "target": "${{ github.workflow }}",
              "result": "성공"
            }
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

  notify-failure:
    runs-on: ubuntu-20.04
    needs: [build-and-push, pull-and-run]
    if: ${{ failure() }}
    steps:
      - name: Notify if Action fails
        uses: slackapi/slack-github-action@v1.23.0
        with:
          payload: |
            {
              "target": "${{ github.workflow }}",
              "result": "실패"
            }
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

JSON으로 target과 result에 대한 값을 전달하고, 성공과 실패를 나눠서 구현했습니다. ${{ github.workflow }}는 workflow의 이름인 개발 서버 자동 배포를 의미합니다.

 

그래프는 아래처럼 그려집니다.

이제 슬랙에 메시지가 정상적으로 오는 걸 확인할 수 있습니다.

 

작은 문제

하지만 이 방식은 문제가 하나 있습니다.

job이 아니라 스크립트 자체가 수행되지 않으면 알림이 오지 않습니다. 예를 들면 다음과 같은 상황입니다.

물론 스크립트를 제대로 짜면 발생하지 않을 일이지만 완전하지 못하다고 느껴졌습니다. 그렇게 하루정도 도입을 고민하고 있을 무렵…

 

신탁

관리자님께서 권한 승인을 해주셨습니다. 따라서 온전히 슬랙만으로 깃허브 알림을 받을 수 있게 된 것입니다.

 

인간 시대의 끝이 도래했다

허가가 나자마자 바로 workflow에 대한 알림과 리뷰, 코멘트에 대한 채널 알림 기능을 켰습니다.

 

 

이제 아래처럼 리뷰나 코멘트가 달리거나 workflow가 실행되면 채널에 알림이 옵니다.

다른 기능에 대한 알림은 필요성이 느껴지면 추가하려고 합니다.

 

버려진 액션 슬랙

열심히 설명드린 위 기능은 쓸모가 없어졌지만 언젠간 사용할 일이 생길 것이라 생각하고 제 가슴 속에 묻어두기로 했습니다.

 

만약 이 글을 보고 도입을 고려하고 계신 분이라면 슬랙 내의 깃허브 앱으로 간편하게 도입하는 방식을 사용하시길 바랍니다.

 

결론

슬랙과 깃허브를 연동해서 편해질 수 있다.

 

 

질문) 원래 티스토리 마크다운 기능이 불편한가요? 노션으로 작성한 글을 복붙하려니 잘 안돼서 기본모드로 하나하나 복붙해왔습니다.