Tool

Github Action

HOONY_612 2021. 8. 22. 21:01
반응형

 

 

이번 "리팩터링" 스터디에서 Branch에 관한 이야기 중 CI/CD에 대한 내용이 나왔습니다.

협업 경험이 거의 없는 저로써는 이 내용이 도통 이해가 가지 않았습니다.

일단 Branch란 흔히 팀원들이 하나의 작업을 맡아서 작업하다가

어느 정도가 되면 Master에 Merge하여 각자 개발한 것을 합치는 방식입니다.

그러나 이것은 오픈 소스프로젝트정도에서만 유용한 방법이라고합니다.

하지만 어느 정도 규모가 있는 개발팀에서 개발할 경우에는 수시로 CI를 해줘야 된다고 하였습니다.

왜 그럴까요? 일단 현업에서는 기능을 개발 할 경우 1000줄 가량 늘어납니다.

이것을 한 번에 리뷰하고 이해한다는 건 어려운 일입니다.

그래서 지속적으로 Merge를 해줘야합니다. 즉 CI주기를 짧게 하는것이죠.

그럴 때 사용하는 Tool들이 있습니다. 예를 들어 Github Action, Jenkins, Travis등이 있습니다.

저는 그 중에서도 Github Action에 대해서 공부해봤습니다.

Github Action을 사용하기 전 중요한 개념 4가지 정도만 학습하고 사용해보겠습니다.

 

 

❗ Github Action의 중요개념

 

Workflow

YAML파일로 작성되고 Github Repository의 .github/workflow폴더에 저장됩니다.

여러개의 Job으로 구성되어있고 Event에 의해 자동으로 트리거 될 수 있는 자동화된 프로세스

 

Event

Workflow를 작동시키는 트리거 역할. 다양한 상황에 적용가능 함.

참고 : Events that trigger workflows

 

Events that trigger workflows - GitHub Docs

You can configure workflows to run for one or more events using the on workflow syntax. For more information, see "Workflow syntax for GitHub Actions." on: push on: [push, pull_request] If you need to specify activity types or configuration for an event, y

docs.github.com

Job

Job은 여러 Step으로 구성되어지며 가상 환경 인스턴스에서 진행됩니다.

event에 의해서 실행되는 코드입니다.

 

Step

Step은 Job을 구성하는 세분화 된 과정입니다. 크게 Uses와 Run으로 작업단위가 나뉘어집니다.

Users는 이미 정의된 명령어를 가져와 실행하는 것입니다.

Run은 가상 환경내에서 실행할 수 있는 명령어를 말합니다.(npm install, mkdir)

 

 

💢 GitHub Action생성

 

set up workflow yourself를 클릭해줍니다.

그럼 다음과 같이 Template이 주어집니다. Template내용에 대해서 알아볼까요?

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Run a one-line script
        run: echo Hello, world!

      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

name

workflow의 이름을 지정해줍니다.

 

on

Event가 언제 일어날 것인지 지정해줍니다. workflow trigger를 시켜줄 때 사용됩니다.

ex > push, pull_request

 

Jobs

하나의 가상 환경에서 여러 Step을 그룹시켜 실행하는 역할을합니다.

 

Step

Step은 Uses와 Run으로 작업 단위가 나뉩니다. 그리고 위에서부터 순차적으로 실행됩니다.

Uses는 다른 사람들이 정의한 명령어를 실행, Run은 가상 환경에서 사용가능한 명령어 실행입니다.

//Uses예시
- name: checkout source code
uses: actions/checkout@master
//Run예시
- name: echo Hello
run: echo "Hello"

 

 

🕹️ Github Action Tutorial

Github Quickstart Tutorial을 참고하였습니다.

 

1. .github/workflows/github-actions-demo.yml 파일을 추가합니다.

name: GitHub Actions Demo
on: [push]
jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
      - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
      - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
      - name: Check out repository code
        uses: actions/checkout@v2
      - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
      - run: echo "🖥️ The workflow is now ready to test your code on the runner."
      - name: List files in the repository
        run: |
          ls ${{ github.workspace }}
      - run: echo "🍏 This job's status is ${{ job.status }}."

name은 Github Actions Demo로 지정하였습니다.

on옵션은 Repository에 push event가 일어날 경우 jobs를 실행하도록 하였습니다.

 

2. Repository내에서 addFile을 선택한 후 다음과 같이 선택한 후 Propose new file을 클릭합니다.

이렇게 하고 Pull-Request요청을 해주면 Branch에서 Push하고 PR을 한 것과 똑같습니다.

그래서 위에 설정한 step들이 차례로 Linux에서 실행될 것입니다. 그럼 결과를 한 번 볼까요?

Shell을 진행하면서 오류가 없었다는 메세지입니다. 즉 테스트가 다 통과되었다는 뜻입니다.

Detail을 눌러보겠습니다. 다음과 같이 설정해놓은 Actions가 실행된 결과를 볼 수 있습니다.

 

실행 결과를 펼쳐보겠습니다. 이와 같이 Step에서 run과 uses가 다르게 동작한 것을 볼 수 있습니다.

상황에 따라서 run과 uses를 사용하면 됩니다.

 

 

➕ 추가 기능 : Slack과 연동하여 결과 보내기

- name: Slack-alarm
  uses: 8398a7/action-slack@v3.9.2
	with:
      status: ${{job.status}}
      fields: repo,message,commit,author,action,eventName,ref,workflow,job,took
      author_name: jihuhwan
	        
	    env:
	      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
	      SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

위의 코드를 추가해줍니다. 일단 name을 지정하고 action-slack이라는 라이브러리를 사용합니다.

with는 우리가 결과를 받았을 때 나타 낼 필드와 값들을 지정해줍니다.

마지막으로 env는 action-slack을 사용하기위해서는 꼭 필수요건으로 지정해줘야합니다.

더 알고 싶으시다면 참고를 클릭해주시면 되겠습니다.

 

그럼 여기서 Slack채널로 Test가 완료되었을 때 메세지를 받을 수 있게 적용해보겠습니다.

아래 GithubMarket에서 Action-slack을 사용합니다. 그럼 특정 name과 uses를 받을 수 있습니다.

그리고 아래 코드를 yml파일에 추가해줍니다. 그리고 해야 할 일은 환경변수들을 설정해줘야합니다.

Slack 메신저에서 SLACK_WEBHOOK_URL을 얻어야합니다.

다음으로 Git Repository에 Secret을 등록해줘야합니다.

 

 

1. SLACK_WEBHOOK_URL얻기

APP을 생성 한 후 Webhooks를 ON으로 설정하게되면 해당 슬랙 채널에 결과를 던질 수 있는 API URL이 생성됩니다.

이것은 내가 지정한 채널에 Github Action의 결과 줄 수 있습니다.

허용을 누르면 아래와 같은 URL을 얻을 수 있습니다.

 

이렇게 URL을 얻었으면 이것을 해당 Repository에 등록해줘야합니다. 그래야 환경변수로 사용가능

합니다. Git Repository의 Setting → Secret에 들어가면 다음과 같은 화면이 나옵니다.

여기서 New repository secret을 클릭해줍니다.

 

그리고 다음과 같이 URL을 아까 YML에 설정한 변수이름에 맞춰 생성해줍니다.

2.GITHUB_TOKEN

 

깃허브는 자동으로 GITHUB_TOKEN 워크플로우 안에서 사용할 시크릿을 생성해줍니다.

그래서 그냥 값을 가져와 사용하면 됩니다.

 

 

결과

그럼 이제 다시 Pull_Request를 해볼까요? 그럼 결과가 Slack의 Random채널로 전달이 될 것입니다.

이렇게 성공이 되었으면 Slack에 다음과 같이 메세지가 옵니다. 아까 저희가 설정해줬던 field들이 나옵니다.

그리고 확인 후 Merge를 클릭하면 또 Slack메세지가 보내집니다.

 

느낀 점

결과적으로 브랜치에서 각 기능을 개발 한 뒤 Main브릿지로 Merge하기 전 Pull_Request요청을

했을 경우 알아서 빌드하고 Test까지 돌려주며 Slack을 이용하여 팀원들에게 그 결과를 알릴 수 있는

메세지 기능까지 구현해봤습니다.

 

이런 기능들을 구현해보면서 현재는 느끼지 못하지만 대규모 프로젝트에서는 편할 수 있겠다라는 생각이 들었습니다.

왜냐하면 Push나 Commit만 해도 알아서 Test를 실행시켜주고 결과를 바로 슬랙으로 간편하게 알려주기 때문입니다.

꼭 다음에 협업을 진행 할 경우 적용시켜 팀원들의 큰 수고를 덜어내는 방향으로 하는 것이 좋겠다는 생각이 들었습니다.

반응형