CI/CD with GitHub Actions

1. CI/CD

CI/CD는 Continuous Integration(CI)와 Continuous Delivery/Deployment(CD)를 통합해서 부르는 용어

• CI/CD는 개발 과정에서 필요한 빌드, 테스트, 배포등의 과정을 자동화
• CI/CD 자동화를 통해서 개발자들은 코드를 자동으로 테스트하고 배포
• 효율적인 작업과, 더 빠르고 더 자주 배포를 진행할 수 있다.

1-1. CI (Continous Integration)

 Continous Integration은 코드를 지속적으로 통합해나가는 것을 의미한다. 일반적으로 코드의 통합은 GItHub의 PR을 통해서 진행할 수 있기에 CI 과정에서 도대체 무엇을 하는지 호기심이 생긴다. 

 

 CI 에서 코드의 통합은 단순히 코드와 코드를 합치는 것뿐만이 아니라 코드를 테스트하고 유효한지 검사하는 확인을 포함한다. 코드를 통합할 때 가장 걱정되고 중요한 부분은 머지 후 이상없게 동작하는지 여부인 것 같다.

 이런 걱정과 의문을 매번 사람이 다 확인하는 것이 아니라 CI 과정에서 테스트를 실행하고 코드가 유효한지 검사하고 만약 문제가 발생했을 경우 즉각적으로 피드백을 통해서 개발자가 문제를 확인하고 수정할 수 있게 만들어준다.

1-2. CD (Continuous Deployment)

 Continuous Deployment는 CI 과정을 통해서 성공적으로 통합된 코드들을 실제 사용자가 사용하고 있는 Production 환경에 배포하는 것을 의미한다.

 

 CD는 Continous Deployment와 Delivery 두 의미로 모두 사용

• Continuous Delivery - 개발환경의 배포까지 자동화 된 것을 의미
• Continous Deployment - 실제 사용자에게 제공되는 Production 환경까지의 배포를 자동화 한 것을 의미

1-3. CI/CD 플랫폼의 종류

 CI/CD는 일련의 과정을 처리하는 CI/CD 파이프라인을 구축함으로서 자동화한다. 개발자들은 이러한 파이프라인을 구축하고 모니터링 하기 위해서 이를 위한 CI/CD 플랫폼을 사용하는데 CI/CD 플랫폼의 종류를 구분하자면 크게 설치형과 클라우드형으로 나눌 수 있습니다.

CI/CD 파이프라인 또한 하나의 프로그램이므로 프로그램을 설계해두면 이를 실행할 컴퓨터가 필요하다.

• 설치형
  - 설치형 파이프라인을 구축하는 개발자가 직접 특정 컴퓨터에 CI/CD 플랫폼을 설치해서 활용하는 방법
  - 대표적인 설치형 CI/CD 플랫폼으로는 Jenkins
• 클라우드형
  - CI/CD 플랫폼을 운영할 컴퓨터를 개발자가 직접 관리할 필요 없이 서비스 제공자가 클라우드에서 모두 운영해주는 형태
  - 별도의 컴퓨팅 자원에 대한 관리 없이 CI/CD 파이프라인의 구축에만 신경 쓸 수 있다.
  - 단점은 컴퓨터에 직접 접근할 수 없고 플랫폼에서 제공해주는 수준까지만 할 수 있기에 세부적인 조정이 불가능
  - 대표적인 클라우드형 CI/CD 플랫폼은 Travis CI, GitHub Actions 등

1-4. CI/CD 가 각광받는 이유

 현재는 어느정도 규모가 있는 개발팀의 경우에는 CI/CD를 구축하는 것이 보편적이라고 한다. 사실 CI/CD는 장점만 있는 것은 아니다. CI/CD를 구축하고 운영하기 위해서는 이를 구축하고 관리하기 위한 노력도 필요하며, CI/CD 플랫폼, 서버를 사용해야하기에 개발자가 직접 배포 과정을 진행하는 것 보다 비용도 많이 든다는 단점이 있다.

 이런 점에도 불구하고 어느정도 규모가 있는 개발팀은 CI/CD를 구축하려는 이유는 바로 효율이다.

 

 소프트웨어는 하드웨어에 비해 상대적으로 변경하기가 쉽고, 기업에서는 항상 유저의 피드백을 통해서 프로덕트를 더 좋은 방향으로, 더 빨리, 자주 개선하고자 한다. 이런 상황에서 개발자가 직접 수동으로 배포를 하는 과정에 리소스를 쏟기보다 프로덕트의 개발 및 개선 과정에 더 많은 리소스를 투입하는 것이 효율적이라고 판단한 것이다.

 현재 IT업계에서 개발자의 몸값은 계속 증가하며 비싸지는 추세이다. 과거에는 하드웨어가 개발자의 몸값에 비해서 상대적으로 비쌌기에 하드웨어를 효율화하기 위해서 개발자들이 노력했다면 현대에는 기술의 발전으로 인해 하드웨어가 상대적으로 싸졌기에 비싼 인력인 개발자의 공수를 더 투입하는 것 보다 하드웨어의 사양을 증대시키거나, 필요한 PaaS 서비스들을 활용해서 개발자들이 핵심 가치를 창출하는 데 집중시키는 방향으로 산업이 발전하고 있다.

 결국 CI/CD는 이러한 상황에 맞춰서 그 효율이 입증되었기 때문에 각광받고 있다.

 

2. GitHub Actions

 GitHub Actions는 GitHub에서 제공하는 클라우드형 CI/CD 툴이다. GitHub에서 비교적 최근에 추가된 서비스이지만 자체적으로 제공하기에 GitHub 레파지토리와의 연동이 쉽고, 레파지토리 안에서 CI/CD까지 함께 구축하고 관리할 수 있다는 이점으로 인해 현재 많은 인기를 얻고 있습니다.

2-1. GitHub Actions 구성요소들

1. Event
   • 레파지토리에서 발생하는 특정한 활동을 의미
   • GitHub Actions에서는 특정한 Event가 발생했을 시 그에 맞는 CI/CD 파이프라인을 구동하도록 설정할 수 있다.
2. Jobs
   • 하나의 runner에서 실행될 여러 step의 모음을 의미
   • step은 실행가능한 하나의 shell script 또는 actions을 의미
3. Actions
   • GitHub Workflow에서 자주 사용되는 기능들을 모아둔 일종의 커스텀 애플리케이션
   • 설정파일에서 use 키워드와 함께 사용할 수 있으며 브랜치로 체크아웃하고, 환경을 설정하는 등 복잡하지만 자주 사용되는 과정들을 미리 정의해두고 편리하게 활용할 수 있다.
   • GitHub Marketplace에서 Action들을 검색하고 활용할 수 있다.
4. Runner
   • workflow를 실행할 서버를 의미
   • 클라우드형 CI/CD 플랫폼인 GitHub Actions는 직접 컴퓨터를 관리할 필요 없이 가상의 Runner를 통해서 Workflow를 실행
   • GitHub Actions의 Runner는 기본적으로 Node 16 version을 탑재

2-2. CI/CD로 구축할 목표

 정적 웹사이트들은 S3를 통해서 호스팅 할 수 있다. 하지만 매번 CRA의 dependencies를 설치하고, build script를 실행하고, AWS에 로그인해서 S3 버킷에 들어간뒤에, 기존의 자료들을 삭제하고 새로운 파일들을 업로드하는 것은 꽤나 번거로운 일이다. GitHub Actions를 통해서 아래의 과정을 자동화 시켜보자

1. 마스터 브랜치에 push or Pull Request Merge가 발생하면 workflow를 실행
2. 필요한 dependencies들을 설치
3. build script를 실행
4. aws에 접속한 후 s3 bucket에 build한 결과물을 업로드

- 예시파일

name: deploy

on:
  push:
    branches:
    - master

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - run: npm ci
    - run: npm run build
    - name: deploy to s3 bucket
      uses: jakejarvis/s3-sync-action@master
      with:
        args: --delete
      env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'ap-northeast-2'
        SOURCE_DIR: 'build'

 

- 참고자료

GitHub Actions Documentation - GitHub Docs

GitHub Actions의 소개와 핵심 개념

 

3. 프론트엔드 개발자가 배포까지 알아야 할까?

  나처럼 개발을 처음 하는 입장에서는 “개발"이라고 하면, 그리고 “프론트엔드 개발"이라고 하면 UI와 기능들을 코드로 개발하는 것이 업무의 전체라고 생각하기 쉬운 것 같다. 하지만 개발자가 하는 개발 중에서 기능 개발은 전체 프로세스의 일부분일 뿐이라고 한다.

 요즘의 IT팀에서 개발자는 기본적으로 제품의 기획 분석, 기능 개발, 배포 및 운영을 책임져야 하며, 나아가서 제품의 기획단에도 참여해서 개발적으로 어떻게 요구사항들을 풀어나갈 수 있는지, 유저의 피드백을 어떤 방식으로 수용하면 좋을지에 대한 의견도 낼 수 있다. 이러한 상황에서 기능 개발만이 개발자의 책임이라고 착각하면 안된다고 한다.

 

 배포 및 운영까지 나의 책임이란 생각을 가져야지만 전체 개발 과정을 보는 시야가 길러지고 그에 맞춰서 개발 일정을 조율하고, 어떤 식으로 하면 배포와 운영을 안정적으로 할 수 있을까? 란 고민을 할 수 있는 성장을 할 수 있다고 한다.

 물론, 프론트엔드 개발자는 상대적으로 백엔드, DevOps 개발자에 비해서 배포와 운영에 대한 부분보다는 FE단의 개발에 업무의 비중이 집중되어 있을 것이다. 하지만 프론트엔드 개발자에게도 기본적으로 배포를 하고 운영할 수 있는 능력은 요구되며, 나아가 추후 내가 개발한 프로덕트에서 특정한 문제가 생겼을 때 배포가 어떤 개념인지, 어떤 식으로 이루어져있는지를 전혀 모른다면 원활하게 트러블 슈팅을 할 수 없게 됨을 알게 되었다.

 

  이러한 이유로 프론트엔드 개발자도 배포에 대한 기본적인 지식은 반드시 가지고 있어야 한다고 배우게 되었다. 나아가 지식 비중의 차이는 있겠지만 프론트엔드 개발자가 백엔드, 서버에 관해 몰라도 된다는 절대 아님을 덧붙여 깨닫게 되었다.

• 소프트웨어 개발 프로세스의 A-Z까지를 이해하기 위해서 배포에 대한 지식은 필수적이다.
• 프론트엔드 개발자도 개발한 프로덕트가 배포 과정에서 문제가 생겼을 때 어느 부분에서 문제가 발생했는지 확인하고 대응할 수 있어야 한다.