기존에는 travis ci를 사용하여 배포를 하였으나, 어느순간부터 돈을 내야 하는 상황이 왔기 때문에.. 무료중 가장 유명한 GitHub Actions를 사용하기로 했습니다.

CI / CD

Red Hat 사이트에 따르면, CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법입니다.
프로젝트를 하다보면 코드를 계속적으로 수정하고 추가하게 되는데, 빌드, 테스트 등등 개발 및 운영팀에 반복적으로 발생하는 문제를 해결하기 위해 생긴
솔루션 입니다.

CI(Continuous Integration)

CI는 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미합니다.

여러 개발자들이 하나의 프로젝트에 각자 다른 기능들을 맡았을 때 각각의 변경 사항이 병합되면, 애플리케이션이 손상되지 않도록 자동으로 애플리케이션을 구축하고, 다른 레벨의 테스트를 자동화 실행을 통해 변경 사항이 애플리케이션에 잘 적용되었는지를 확인합니다.

자동화된 테스트에서 기존의 코드와 신규 코드간의 충돌이 발견되면 CI를 통해 빠르고 자주 수정이 가능합니다.

https://tecoble.techcourse.co.kr/post/2021-08-14-ci-cd/
1. 개발자가 구현한 코드를 기존 코드와 병합한다.
2. 병합된 코드가 올바르게 동작하고 빌드되는지 검증한다.
3. 테스트 결과 문제가 있다면 수정하고 다시 1로 돌아간다. 문제가 없다면 배포를 진행한다.

CD(Continuous Delivery)

CD는 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미합니다.

지속적인 제공이란, 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리에 자동으로 업로드 되는 것을 뜻하며, 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있습니다. (수동)
최소한의 노력으로 새로운 코드를 배포하는것을 목표로 합니다.

지속적인 배포는 개발자의 변경사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스 하는것을 의미합니다.

종류

• Jenkins
• Travic CI
• Circle CI
• GitHub Actions

GitHub Actions

GitHub에서 제공하는 CI/CD 플랫폼으로, 빌드, 테스트 및 배포 파이프라인을 자동화 할 수 있습니다.

소스가 GitHub에 push되는 등, GitHub에 이벤트가 발생할 때 작동 되도록 workflow를 구성할 수 있습니다.

구성요소

• Workerflows
  하나 이상의 job들을 실행 시키는 설정 가능한 자동화된 프로세스입니다.
  깃헙에 올린 리포지토리 의 .github/workflows 안에 YAML파일로 정의되며, 이벤트에 의해 트리거 되거나 수동 또는 정의된 일정에 의해 실행됩니다.
  리포지토리에 여러 워크플로를 가질 수 있고, 각각은 서로 다른 단계의 설정을 수행할 수 있습니다.
• Events
  이벤트는 workflow의 실행을 트리거하는 리포지토리의 특정 활동을 말합니다.
  ex) 깃헙에서 다른사람이 pull요청을 만들거나, 이슈를 열거나 commit을 리포지토리에 보낼때 .
• Jobs
  Job은 여러 Step으로 구성되고, 같은 runner에서 실행됩니다.
  각 Step은 실행될 셀 스크립트 또는 실행될 action입니다.
  다른 Job에 의존 관계를 가질 수 있고, 독립적으로 병렬 실행도 가능합니다.
• Actions
  동작은 복잡하지만, 자주 반복되는 작업을 수행하는 GitHub Actions의 사용자 지정 응용 프로그램 입니다.
  workflow 파일에 쓰는 반복적인 코드의 양을 줄여주는데 사용합니다.
  직접 작성하거나 GitHub Marketplace의 workflow에서 찾을 수 있습니다.
• Runners
  workflow가 트리거 될때 workflow를 실행하는 서버입니다.
  각각은 한번에 하나의 작업을 실행할 수 있습니다.
  깃헙은 workflow를 실행할 수 있는 Ubuntu Linux, Microsoft Windows, and macOS runner들을 제공하며, 자체 runner로도 진행할 수 있습니다.

예시

기존에 사용했던 Travis CI 코드와 GitHub Actions에서 사용한 코드가 어떻게 같은지 살펴보겠습니다.

• Travis CI

# .travis.yml
language: generic

sudo: required

services: # (1)
  - docker

before_install: # (2)
  - docker build -t timssuh/sweetclub-back-test -f ./back/Dockerfile.dev ./back

script: # (3)
  - docker run -e CI=true timssuh/sweetclub-back-test npm run test

after_success: # (4)
  - docker build -t timssuh/sweetclub-front ./front
  - docker build -t timssuh/sweetclub-back ./back
  - docker build -t timssuh/sweetclub-nginx ./nginx
  # (5)
  - echo "$DOCKER_HUB_PASSWORD" | docker login -u "$DOCKER_HUB_ID" --password-stdin
  # (6)
  - docker push timssuh/sweetclub-back
  - docker push timssuh/sweetclub-nginx
  - docker push timssuh/sweetclub-front

• GitHub Actions

# .github/workflows/main.yml
name: Build and Push Docker Image

on:
  push:
    branches: 
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        
      - name: Docker Setup Buildx # (1)
        uses: docker/setup-buildx-action@v1.6.0

      - name: Build back test # (2)
        uses: docker/build-push-action@v2.10.0
        with:
          context: ./back
          file: ./back/Dockerfile.dev
          push: false
          tags: sweetclub-back-test
          load: true # 이것이 있어야 로컬 image로 읽을 수 있음
          
      - name: back test # (3)
        run: docker run sweetclub-back-test npm run test
          
      - name: Docker Login # (5)
        uses: docker/login-action@v1.14.1
        with:
         username: ${{ secrets.DOCKERHUB_USERNAME }}
         password: ${{ secrets.DOCKERHUB_TOKEN }}
         
      - name: Build and push back # (4) (6)
        uses: docker/build-push-action@v2.10.0
        with:
          context: ./back
          push: true
          tags: ${{ secrets.DOCKERHUB_USERNAME }}/sweetclub-back
          
      - name: Build and push front # (4) (6)
        uses: docker/build-push-action@v2.10.0
        with:
          context: ./front
          push: true
          tags: ${{ secrets.DOCKERHUB_USERNAME }}/sweetclub-front
          
      - name: Build and push nginx # (4) (6)
        uses: docker/build-push-action@v2.10.0
        with:
          context: ./nginx
          push: true
          tags: ${{ secrets.DOCKERHUB_USERNAME }}/sweetclub-nginx
    

1. 도커를 사용
2. 백엔드 부분을 테스트 하기 위해 Dockerfile.dev 파일을 이용해 docker를 build합니다.
3. (2)에서 빌드한 이미지를 실행하고 npm run test 명령어로 테스트를 실행한다.
4. 테스트가 완료되면 각 도커파일마다 build 해줍니다.
5. docker-hub에 로그인합니다.
6. (4)에서 빌드된 이미지를 docker-hub에 업로드 합니다.

출처

https://www.redhat.com/ko/topics/devops/what-is-ci-cd
https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
https://zzsza.github.io/development/2020/06/06/github-action/
https://meetup.toast.com/posts/286