[CI/CD] Github Actions 에 대해

안녕하세요 오늘은 Github 에서 제공하는 Github Actions CI/CD 기술에 대해 정리해보려고 합니다.
이 글을 읽기 전 CI/CD 에 대한 이해가 필요합니다.
제가 작성한 [CI/CD] CI/CD 에 대해 을 참고부탁드립니다 ❗️

---

🌱 Github Actions 란?

GitHub Actions 가 출시되기 전 대표적인 CI/CD 도구로는 Jenkins,Travis CI 등의 다양한 서비스가 있었습니다.
하지만 출시 이후, 현재Github Actions 는 개발자들에게 CI/CD 도구로 많은 사랑을 받고 있습니다 🫶
물론 아직 기존 서비스를 사용하는 개발자들도 많지만, 기존에 많은 개발자들및 개발 조직은 비교적 간편하고 어렵지 않은 Github Actions 사용하는 쪽으로 이동하고 있는 추세입니다 👨‍💻

Github Actions 는 원격 코드 저장소로 유명한 Github 에서 제공하는 CI/CD 을 위한 서비스입니다.
비교적 최근에 출시되었으며, 코딩을 해본 사람이라면 거의 다 Github 계정을 가지고 있기 때문에 다른 CI/CD 서비스 대비 진입장벽이 낮습니다.

GitHub Actions 을 사용하면 자동으로 코드 저장소에서 어떤 이벤트(Event) 가 발생했을 때 특정 작업이 일어나게 하거나 주기적으로 어떤 작업들을 반복해서 실행시킬 수도 있습니다.
예를 들어, 누군가가 깃허브 저장소에 PR 을 날리게 되면 GitHub Actions 을 통해 해당 코드 변경분에 문제가 없는지 각종 검사를 진행할수 있으며, 새로운 코드가 Main 브랜치에 push 되면 Github Actions 을 사용해서 빌드하고 배포할 수도 있습니다.
이외에도 특정 시간마다 애플리케이션에 대한 통계 데이터 및 다양한 작업을 편리하게 진행할 수 있습니다.

CI/CD 자동화 기술 자체도 이미 개발자의 수고를 덜어주는 기술이지만, GitHub Actions 는 CI/CD 기술마저 사용자들이 사용하기 쉽게 하는 서비스라고 생각하면 될 것 같습니다.
과거 CI/CD 는 DevOps 엔지니어만의 영역 즉, DevOps 엔지니어의 전유물로 여겨지곤 했지만, 이젠 이러한 편리한 서비스를 통해 일반 개발자들도 스스로 CI/CD 을 구축할 수 있습니다 ❗️
또한 혁신적인 Docker 의 가상화 기술과 GithubActions 은 마치 짜장면의 탕수육 처럼 큰 시너지를 발생시킵니다 👍

• GitHub Actions 설명서

---

🌱 Github Actions Prcess에 대한 이해

Github Actions 의 전반적인 프로세스에 대해 알아보겠습니다.
개인적으로 처음에 프로세스에 대한 이해 없이 Github Actions 에 대해 공부하는게 너무 힘들었습니다 🥲

밑에서 Github Actions 에 대한 구성 요소 및 명령어에 대해 배우기 전에 Process 을 먼저 이해하는게 필수적이라고 생각합니다 ❗️

사용자가 작성한 Jobs 은 가상 서버(runner) (=OS) 에서 구동됩니다.

저는 Github Actions 을 처음 접했을 때 내가 작성한 Workflows의 Jobs이 어디서 동작하지에 대한 궁금증을 가지고 있었습니다.
GitHub Actions Runner 어플리케이션을 제공하는데 해당 어플리케이션이 설치한 머신으로 Jobs 이 진행됩니다.
두가지 종류의 가상 서버가 존재하며, 내가 원격 레포지토리에 올린 코드와 내가 수정한 코드를 합쳐서 Jobs 을 진행합니다.

  name: CI
	
  on:
    push:
      branches: [ master ]
    pull_request:
      branches: [ master ]
	
  jobs:
    build:
      runs-on: ubuntu-latest # 해당 jobs 을 실행할 가상서버 지정
	
      steps:
      - uses: actions/checkout@v3 # Github Market Place 에서 제공하는 코드 ->  Clone & Checkout 하는 액션
	
      - 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.

해당 Workflows 는 build 작업을 수행하는 용도의 Job 으로 구성된 Workflows 입니다.
Job 에서 runs-on 속성을 통해 가상 서버를 지정할 수 있습니다.
가상 서버에 대한 자세한 내용을 밑에서 다뤄보겠습니다.

대부분의 Jobs 은 원격 레포지토리에서 코드를 가상 서버로 Clone 한 후에 시작됩니다.

Jobs 에 대한 가상 서버를 지정한 후, 작업을 할 코드가 필요하겠죠? 🤔
이를 위해 대부분의 actions/checkout@v3 을 이용해서 원격 레포지토리에서 코드를 가져오는 것 부터 시작합니다.
사람들이 많이 사용하는 Actions 은 Github Market Place 에 이미 제공되고 있으므로 원하는 Actions 을 찾아 uses 속성으로 사용하면 됩니다.

  jobs:
    build:
      runs-on: ubuntu-latest # 해당 jobs 을 실행할 가상서버 지정
	
      steps:
      - uses: actions/checkout@v3 # Github Market Place 에서 제공하는 코드 ->  Clone & Checkout 하는 액션
	
      - 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.

위에 코드에서는 actions/checkout@v3 을 이용해서 해당 작업을 수행합니다.
원격 레포지토리에서 코드를 가져온 후(Clone), 해당 가상 머신에서 특정 브랜치로 전환(Check out) 하여 작업을 수행합니다.

일반적으로 모든 Jobs 는 선택한 가상서버에서 병렬로 독리적으로 이루어집니다.

Github Actions 을 계층적 구조로 살펴보면 Event -> Workflows -> Jobs -> Steps -> Actions 입니다.
사실 정확한 구조는 아니지만, GitHub Actions 을 처음 접해본 사람은 해당 구조를 떠올리면서 공부하면 좋을 것 같습니다.
여기서 Workflows 을 구성하는것이 하나 이상의 Jobs 인데, 각 Jobs 마다 가상 서버와 수행할 작업에 관한 Steps 을 지정해서
병렬적으로 작업을 수행합니다.

밑에서 알아보겠지만, 동기적으로 수행할 수도 있습니다. 하지만, 아무런 설정을 하지 않으면 모든 Jobs 은 병렬로 처리됩니다 ❗️

---

🌱 Github Actions 구성 요소

이제 본격적으로 Github Actions 을 구성하는 요소에 대해서 알아보고자 합니다 ❗️
위에서 살펴보았던 것처럼, 구성 요소로는 Event, Workflow ,Job,Step,Action,Runner 가 있습니다.

1. Workflow

가장 상위 개념으로 간단하게 말하자면 자동화 해놓는 모든 작업 과정이라고 볼 수 있습니다.
예를 들어 CI 자동화를 원한다면 CI 에 필요한 모든 작업 과정을 하나의 Workflows 에 구현할 수 있습니다.

대신 Workflow 는 어떤 장소에 어떤 파일 형식으로 작성해야 한다는 약속이 있어야겠죠?

레포지토리에 .github/workflows 폴더 아리애 위치한 YAML 파일로 설정하면 Workflows 라고 인지합니다.
해당 이미지 패키지 구조에서는 CI.yml 과 context.yml 두개의 Workflows 파일이 존재합니다.
이처럼 하나의 레포지토리에 여러개의 Workflows 설정도 가능합니다.

name: CI

이렇게 상단에 Workflow 의 이름을 설정할 수 있습니다.
만약 name 속성이 없다면 Workflow 가 저장된 경로 이름으로 자동 지정됩니다.

• 여러 Job 으로 구성되고, Event 에 의해 트리거 될 수 있는 자동화된 프로세스
• 최상위 개념
• Workflow 파일은 YAML 파일로 작성되고, Github Repository 의 .github/workflows 폴더 아래 저장된다.

2. Event

Event 는 가장 최상위 개념인 Workflow 을 Trigger 하는 특정 활동이나 규칙을 의미합니다.
예를 들어 특정 브랜치로 push 하거나 pull request 하는 경우 혹은 특정 시간대에 반복(cron) 하는 경우가 Event 에 해당됩니다.

1. 특정 브랜치에 push 나 pull request 하는 경우

on:
  push:
    branches: [ 'main' ] # main 브랜치에 push 할때 Trigger
  pull_request:
    branches: [ 'main' ] # main 브랜치에 pull request 할때 Trigger
    
# on: push
# -> 전체 브랜치에 대해서 push 일 때 동작
# on: [push, pull_request] 
# -> 전체 브랜치에 대해서 push, pull_request 일 때 동작

2. 특정 시간대에 실행하는 경우

on:
   schedule:
      - cron: "0 0 * * *"

두 코드는 YAML 로 작성한 Workflow 가 동작하는 Event 을 나타내는 부분입니다.
첫번째 코드는 원격 main 브랜치에 push 와 pull request 되는 경우 해당 Workflow 가 동작하며, 두번째 코드는 특정 시간대에 Workflow 가 동작합니다.

• Event 는 workflow 을 트리거하는 특정 활동이나 규칙을 말한다.
• 원격 레포지토리에 있는 코드에 트리거 될때 기준이다.

3. Job

Job 은 하나의 Workflow 을 구성하는 작업 단위입니다.
Job 은 여러 Step 으로 구성되고, 앞에서 살펴보았던 것과 같이 개발자가 지정한 가상환경 즉, runner 에서 실행됩니다.
서로 의존관계를 가질 수도 있고, 독립적으로 병렬 실행도 가능합니다 ❗️

jobs:
  build: # job 문자열 아이디
    name: build # job 이름 
    runs-on: ubuntu-latest # 가상환경(runner)
    steps:
      - name: checkout java code # 첫번째 step
      	run: echo checkout starts! 
        uses: actions/checkout@v3 

      - name: Set up jdk 17 ver # 두번째 step
        uses: actions/setup-java@v3 
        with:
          java-version: '17'
          distribution: 'temurin'
          
      ....

해당 코드는 build Job 의 일부분을 보여주는 코드입니다.
여러 Steps 으로 구성되는 것을 확인할 수 있으며, Job 마다 가상환경을 설정할 수 있습니다 ❗️

4. Step

Step 은 하나의 Job 을 구성하는 Task 이며, Command 혹은 Action 을 실행할 수 있습니다.

 - name: set yaml secret
   uses: microsoft/variable-substitution@v1 # Github Market Place 에서 제공하는 Action
   with:
      files: ./src/main/resources/application.yml
      env:   
        spring.datasource.url: ${{ secrets.DATABASE_URL }}
        spring.datasource.username: ${{ secrets.DATABASE_USERNAME }}
        spring.datasource.password: ${{ secrets.DATABASE_PASSWORD }}

 - name: Grant execute Permission for gradlew
   run: chmod +x gradlew # Command 

 - name: Build with Gradle
   run: ./gradlew build -x test # Command

해당코드는 Build Job 의 일부 Step 을 보여주는 코드입니다.
name 속성으로 Step 이름을 정할 수 있으며, name 속성을 정하지 않으면 Action 이나 Command 이름 그대로 보여집니다.

위에서 살펴보았던 것과 같이 uses 속성은 Github Market Place 에 이미 제공되고 있으므로 적절한 것을 찾아 uses 속성을 이용해 정의하면 되며, run 은 Command 을 직접 실행될 때 사용하는 속성입니다 ❗️

5. Action

---

참고

Github Action 사용법 정리
[Github]깃허브의 CI툴인 Actions의 문법 간단 정리
[GitHub Action Learning] #3 Workflows에서 변수 사용하기
GitHub Actions의 소개와 핵심 개념
GitHub Actions 시작하기 - checkout과 context, secret