CI/CD
매번 개발자가 코드를 수정하고 빌드, 테스트, 배포까지 한다면 상당히 많은 시간이 소요가 된다.
어플케이션 개발 단계부터 배포때까지 자동화를 통해서 좀 더 효율적이고 빠르게 사용자에게 빈번이 배포할 수 있도록 만드는 것을 말한다.
CI
Continuous Integration 지속적인 통합을 의미한다.
- Code: 개발자가 원격 저장소에 코드를 push
- Build: 원격 저장소에서의 코드를 가져와 유닛 테스트 후 빌드하는 단계
- Test(Merge): 코드의 결과물이 다른 컴포넌트와 잘 통합하는지 확인하는 과정
| build, test 전 - 주황색 점 | 완료 - 성공 - 초록색 점 | 시래 - 빨간색 점 |
|---|---|---|
 |  |  |
- 코드 변경사항을 주기적으로 빈번하게 머지해야 한다. -> 머지의 충돌을 피할 수 있어서 개발 생산성 향상
- 머지되는 코드들은 자동으로 빌드, 테스트, 머지 단계를 거치기 때문에 코드의 결함이나 문제점을 빠르게 발견할 수 있다. 이렇게 발견되는 버그들은 빠르게 수정이 되어 용이하다.
- 자동화 단계를 거치면서 코드의 퀄리티가 향상된다.
CD
Continuous Delivery / Deployment : 지속적인 제공 / 배포 를 뜻한다.
build, test 된 코드들은 배포가능하게 Release, Deploy, Operate 과정을 거친다.
- Release: 배포가능한 소프트웨어 패키지를 작성한다.
- Deploy: 프로비저닝을 실행하고 서비스를 사용자에게 노출한다.(실질적인 배포 부분)
- Operate: 서비스 현황을 파악하고 생길 수 있는 문제를 감지
GitHub Actions
github 에서 공식적으로 제공하는 CI/CD 툴로, 개발의 work flow를 자동화할 수 있게 도와주는 툴이다.
Workflow
- 자동화된 전체 프로세스로 하나 이상의 Job 으로 구성되고, Event 에 의해 예약되거나 트리거될 수 있는 자동화된 절차를 말한다.
- YAML 파일로 작성되고 레포지토리의
.github/workflow폴더 아래에 저장되고 자동화 동작을 전달하면, Github Actions 는 해당 파일을 기반으로 그대로 실행시킨다.
Event
- Workflow 를 실행하는 특정 활동이나 규칙.(push, pr 등등)
Job
- 여러 step 으로 구성되고 단일 가상 환경에서 실행된다. 의존관계를 갖거나 독립적으로 실행될 수도 있다.
Step
- Job 안에서 순차적으로 실행되는 프로세스 단위. 명령을 내리거나 action 을 실행할 수 있다.
Action
- Job 을 구성하기 위한 step 들의 조합으로 구성된 독립적인 명령으로 workflow 의 가장 작은 빌드 단위이다. action 을 사용하기 위해서는 step 을 조합해야한다.
Runner
- Github Action Runner 어플리케이션이 설치된 머신으로 workflow가 실행될 인스턴스
생성하여 배포하기
레포지토리의 .github/workflows 파일 안에 client.yaml 를 생성하여 YAML 파일형태로 event, job, step 을 정의한다.
YAML 파일에도 작성형식이나 규칙이 존재하는데, key-value 와 같이 객체 형태처럼 작성해야하고 : 뒤에 공백이 꼭 필요하다. 들여쓰기는 탭 대신 스페이스바를 사용한다.
# .github/workflows/client.yml
name: client
on:
push:
branches:
- reference
jobs:
build:
runs-on: ubuntu-20.04
steps:
- name: Checkout source code.
uses: actions/checkout@v2
- name: Install dependencies
run: npm install
working-directory: ./my-agora-states-client-react
- name: Build
run: npm run build
working-directory: ./my-agora-states-client-react
- name: SHOW AWS CLI VERSION
run: |
aws --version
- name: Sync Bucket
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_EC2_METADATA_DISABLED: true
run: |
aws s3 sync \
--region ap-northeast-2 \
build s3://fe-106-jeongjwon-s3 \
--delete
working-directory: ./my-agora-states-client-react한 부분씩 살펴보면
name: client 액션 탭에 노출되는 workflow 이름으로 옵셔널한 값이다.
on:
push:
branches:
- referenceworkflow 파일을 자동으로 실행(트리거)하는 이벤트를 병시한다.
push 이벤트를 명시하면 누군가가 레포지토리에 변경사항을 push 하는 시점마다 job이 실행된다.
jobs:
build:
runs-on: ubuntu-20.04
steps:
- name: Checkout source code.
uses: actions/checkout@v2
- name: Install dependencies
run: npm install
working-directory: ./my-agora-states-client-react
- name: Build
run: npm run build
working-directory: ./my-agora-states-client-react
- name: SHOW AWS CLI VERSION
run: |
aws --version
- name: Sync Bucket
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_EC2_METADATA_DISABLED: true
run: |
aws s3 sync \
--region ap-northeast-2 \
build s3://fe-106-jeongjwon-s3 \
--delete
working-directory: ./my-agora-states-client-reactjob 에 대한 설정이다.
-
runs-on: 해당 job을 어떤 운영체제에서 실행할 것인지 명시한다. -
steps: job이 가질 수 있는 동작의 나열로, 각가의 step은 독립적인 프로세스를 가진다.name: 각 step의 이름uses: 해당 step 에서 사용할 액션run: 커맨드라인env: 해당 job에서 사용할 환경변수를 Key-value 형태로 설정한다.
실습을 진행하면서 겪었던 어려움
보는 것과 같이 push 를 하고 actions 에는 실패한 흔적이 가득했다.
겨우 yaml 파일만 추가시키면 되는 것인데 말이다.
그 중에서도 환경변수를 설정하는 env 옵션에서 애를 먹었다.
AWS 의 액세스 키는 아주 중요한 정보이기 때문에 꼭 상수화를 통해 전달되어야 한다.
이 값은 깃허브의 Settings - Security - secrets and variables - Actions 에서 추가시키면 된다.
중요한 점은 깃허브에서 설정할 name과 env 옵션에서 적어주는 네이밍을 동일시 적용시켜야 한다.
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}그렇지 않으면 제대로 인식되지 않아 다른 에러로 착각하여 다른 곳에서 에러를 찾기 바빴다.
