[Github Actions] CI 맛보기!

https://mjoo1106.tistory.com/entry/CICD-%EB%8F%84%EB%8C%80%EC%B2%B4-%EB%AD%98%EA%B9%8C

CI/CD 도대체 뭘까..?

여기서 CI, CD 개념을 알아보았다. 개념을 숙지했다면 이제 실습으로 바로 넘어가자!

이번 실습에서는 CI(Continuous integration)만 진행해볼 예정이다. 하나하나 천천히 시작해보자

---

FLOW

 

Continuous integration을 해석해보면 지속적 통합이다. 그래서 이게 뭔데?! 

 

우리가 기존에 진행했던 프로젝트에서 github를 사용했던 경험을 생각해보자...

단순하게 로컬에서 진행한 작업을  github에 푸쉬하게 된다. 이게 끝이다!

그런데 이 경우에 push 과정에서 에러나 충돌은 어떻게 해결할래...? 라고 물어보면 막막하다.. 

 

규모있는 곳에서는 당연히 트러블 슈팅을 할 수 있는 팀이 있겠지만 토이프로젝트나 간단한 협업에는 트러블 슈팅까지 하기에는 벅차다!

그러므로 CI tool(젠킨스, gitlab, github action)을 사용해서 build부터 test까지 자동화 하는 것이라고 생각하면된다. 이를 ec2에 배포하게 된다면 그것이 바로 CD(Continuous delivery) 까지 진행해보는 것이다! 

 

글로 적었던 설명을 그림으로 나타내보았다. deploy는 도커로 배포한다고 가정했고 파이프라인이 실패하게 되면 github issue 처리를 하는 flow이다. 또한, 특정 상황들(push, fetch, pull 등)을 지정할 수 있는데 해당 그림은 push event가 발생할 때만 github actions에서 build->test->deploy의 자동화 된 과정을 거치게 되는 것이다.

 

⭐️ 도커를 사용하지 않아도 된다. spring의 경우 jar 파일을 서비스 서버에 배포해주기만 하면 끝이다.

---

프로젝트 setting

 

github actions을 사용하기 위해서 우리는 일단 repository와 프로젝트를 만들어야 한다.

repository를 만들었다고 가정하고 다음과 같은 프로젝트를 만들어보자

나중에 test 코드를 실행하기 위해 간단한 hellocontroller라는 클래스를 하나 생성하고 아래와 같이 코드를 작성하자.

package com.example.demo;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {
    @GetMapping("/")
    public String test(){
        return "1234";
    }
}

현재는 build 만 진행할 것이므로 테스트 코드는 다음번에 작성해보겠다!

 

---

Github Actions

 

이제 github actions을 사용해보자! github actions은 runner (server)를 지원하므로 바로 사용하다. 이것은 큰 장점이자 단점이다

CI/CD 서버를 지원해준다는 것은 당연히 내돈내산이 아니니까 비용 측면에서 효율적이라고 볼 수 있다.

그러나, CI/CD 서버를 사용하다보면 환경 설정 등의 문제로 커스텀을 해야하는 경우도 있다. 하지만, github actions의 경우 커스텀은 불가능하고 반드시 정해진 규칙에서 사용해야 한다. 이 경우가 단점이라고 볼 수 있다.

 

최상위 폴더에서 .github > workflows > gradle.yml 파일을 하나 생성해준다.

그리고 github actions에서 제공해주는 gradle build 코드를 붙여준다.

name: Java CI with Gradle

on:
  push:
    branches: [ "feature/*" ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'temurin'
      - name: Grant execute permission for gradlew
        run: chmod +x gradlew
      - name: Build with Gradle
        run: ./gradlew build --exclude-task test

하나씩 요소를 살펴보자!

on:
  push:
    branches: [ "feature/*" ]

해당 스크립트의 경우 feature/ 로 시작하는 모든 branch에 push event가 발생하면 gradle.yml 파일로 생성되는 파이프라인을 실행하는 것이다.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'temurin'
      - name: Grant execute permission for gradlew
        run: chmod +x gradlew
      - name: Build with Gradle
        run: ./gradlew build --exclude-task test

Jobs는 독립된 가상 머신 또는 컨테이너에서 돌아가는 하나의 처리 단위를 의마한다. Jobs는 적어도 하나의 작업은 있어야 한다!

 

build는 말 그대로 build 작업이라는 것을 명시해주는 역할을 수행한다.

 

runs-on은 해당 작업들을 수행할 OS 환경을 지정한다.

 

steps는 각 작업(job)이 하나 이상의 단계(step)로 모델링이 된다. 작업 단계는 커멘드, 쉘 스크립트가 될 수도 있다. 커맨드나 스크립트를 실행할 때는 run 속성을 사용하고 액션을 사용할 때는 uses 속성을 사용한다.

 

users: actions/checkout@v3

actions/checkout 의 v3 태그를 참조하여 Action을 실행하라는 것이다. 핵심은 이 한 줄로 repository를 checkout 할 수 있다는 사실만 알면 된다.

 

steps의 마지막 두 부분이 이제 build를 진행하는데, 가장 마지막에 --exclude-tast test가 보일 것이다. 이건 말 그대로 빌드 작업 시 테스트는 하지 않는다는 명령어이다. 파이프라인으로 따로 테스트를 만들기 위해 추가한 명령어라고 생각하면 된다.

 

😄 단순하게 빌드와 테스트를 동시에 한다면 ./gradlew build로 변경해서 진행하면 된다.

 

 

빌드에 성공한 것을 확인할 수 있다. 테스트의 경우 해당 코드 마지막에 ./gradlew build -> ./gradlew test 로 변경해주면 테스트 스크립트도 작성 완료이다.

 

---

깃허브 액션은 이 때까지 사용한 CI/CD 툴에 비해 사용하기 진짜 쉽다. gitlab과 젠킨스를 써본 경험이 있는데... 사용성이 넘사다...

갓허브....👍

 

다음에는 더 쉬운 배포를 해보고자한다. 다음 포스팅도 많관부 ^_^