반응형
최근에 회사에서 신규 프로젝트를 담당하게 되면서 새 프로젝트 초기 세팅을 맡게 되었다.
CICD 쪽은 처음 다뤄보는데 가장 쉽게 접할 수 있던 것이 GitHub Action
간단하게 GitHub Action이 무엇인지, 어떤 것을 했는지 정리해보려고 한다.
GitHub Action이란?
GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD(연속 통합 및 지속적인 업데이트) 플랫폼입니다.
사실 CICD를 처음 해보는지라 대충 어떤 것인지 느낌적인 느낌으로만 알고 있던 상황이라, 어떤 것인지 간단하게 알아보겠다.
CI/CD란 ?
- CI : Continuous Integration
= 지속적 통합
= 공유 Repository에 코드를 자주 Commit해야하는 소프트웨어 방식 (Github 문서)
= 코드 변경 사항을 공유 소스에 자동으로 계속 합치는 것
= 팀원의 작업을 연속적으로 자주 통합시키는 것 - CD : Continuous Delivery/Deployment
= 지속적 제공/배포
= 자동화를 사용하여 소프트웨어 업데이트를 게시하고 배포하는 방법 (Github 문서)
= 코드 변경 사항의 빌드, 테스트, 배포를 나타내는 프로세스
이것의 장점이라 함은 생산성 향상, 안정성 확보, 신속한 서비스 제공 등이 있다.
꼭 자동화 될 필요는 없으나 빠르고 안정적인 서비스 제공을 위해서는 개발부터 배포까지의 프로세스가 효율적이어야 한다는 것이다.
GitHub Action이 지원하는 것
코드 작성에 더 많은 시간을 투자하게 하고, 오류 디버깅/Merge Conflict 해결에 더 적은 시간을 사용할 수 있도록 돕도록 함
- 코드 Commit → 지속적 빌드/테스트(Lint, 보안, 코드, 기능, 기타 사용자 지정 테스트)를 통한 오류 감지
- 이런 기능을 실행할 수 있는 WorkFlow 제공
- 특정 이벤트가 발생할 때 실행되도록 WorkFlow 구성 가능
- CI 테스트를 실행하고 이에 대한 결과 확인 가능
- 소프트웨어 개발 수명 주기에 걸쳐 WorkFlow 생성 가능 (EX. 프로젝트 배포, 릴리즈)
Workflow
하나 이상의 작업을 실행할 구성 가능한 자동화된 프로세스
- YAML 파일에 정의
- Repository의 이벤트로 트리거될 때 실행되거나 사용자가 정의한 이벤트에 따라 실행됨
- .github/workflows 디렉토리에 정의
- Workflow의 기본 사항
- events(이벤트) = Workflow가 실행되도록 하는 트리거
- Runner Machine에서 실행될 하나 이상의 jobs(작업)
- Job을 구성하는 하나 이상의 steps(단계)
- 각 Step은 사용자가 정의한 스크립트 또는 action을 실행함
name: Workflow 1
# Event
on:
pull_request:
types:
- opened
- reopened
jobs:
edit-pr:
runs-on: ubuntu-latest
steps:
- name: Action1
uses: actions/checkout@v3
with:
fetch-depth: 0
ref: ${{ github.head_ref }}
- name: Action2
id: extract
run: |
branch_name="${{ github.head_ref }}"
ticket_name="${branch_name#*/}"
echo "ticket=$ticket_name" >> $GITHUB_OUTPUT
...
1. Workflow의 Event(= 트리거, 실행 시기) 설정
- Repository에 발생하는 이벤트
- GitHub 외부에서 발생하고 GitHub에서 repository_dispatch 이벤트를 트리거하는 이벤트
- 예약된 시간
- Manual
2. 변수
- Workflow가 실행되는 동안 민감하지 않은 정보를 변수로 저장해서 사용할 수 있음
- action이나 Workflow에서 변수는 생성, 읽기, 수정이 가능함 (다양한 문법에서 사용하는 변수와 동일하게 사용 가능)
3. Workflow의 내용 중복을 피하는 방법
- Resuable Workflow (재사용 가능한 Workflow)
- jobs와 steps가 모두 포함된 전체 Workflow를 재사용할 수 있음
- 여러 repository들에 적용할 완전한 CI/CD 프로세스를 적용할 때 유용함
→ 한 곳에서 관리 가능, 한 organization의 여러 repository에 적용 가능
- Compose actions (복합 action)
- 여러 steps를 하나의 action으로 결합 가능 → 여러 steps의 한 묶음을 하나의 step으로 실행할 수 있음
- 하나 이상의 workflow에서 실행할 일련의 steps가 있다면 유용함
- 긴 YAML 파일을 훨신 작은 단위의 파일로 리팩토링 가능 + 파일 간 복사/붙여넣기를 피할 수 있음
4. Custom Action
- GitHub API + 공개된 3rd-party API를 통합 등 Repository와의 상호작용하는 code를 작성해서 action을 생성할 수 있음
- 환경 변수를 저장하고 사용할 수 있음 (API URL, KEY 등을 하드 코딩하는 것은 지양해야 함)
- Action 라이브러리를 개발/사용할 수 있음
5. Context
- Context는 Workflow 실행, 변수, Runner 환경, jobs, steps에 대한 정보에 접근하는 방법
- = string이나 다른 object가 될 수 있는 속성을 포함하는 객체
- expression syntax를 사용해 context에 접근할 수 있음
- if 문에서 github.ref의 context를 확인해서 현재 Branch 이름을 확인함
name: CI
on: push
jobs:
prod-check:
if: ${{ github.ref == 'refs/heads/main' }}
runs-on: ubuntu-latest
steps:
- run: echo "Deploying to production server on branch $GITHUB_REF"
6. Expression
- Expression을 사용해서 Workflow 파일과 Access context에서 환경 변수를 프로그래밍적으로 설정 가능함
- operator를 사용한 literal 값, context의 참조, 함수의 조합으로 Expression을 만들 수 있음
7. Monitoring
8. Workflow 실행을 위한 Notification
9. Troubleshooting
GitHub Docs에 나와있는 내용을 간단히 정리해보았다.
이미 한차례 개발을 해본 입장에서는 GitHub Actions가 얼마나 쉬운지를 말하고 싶었던 것으로 생각이 된다.
실제로 처음 YAML 문법을 접했을 때 조금 헷갈리는 부분들이 있었지만 결국 다른 프로그래밍 언어와 크게 다르지 않았었다.
다음 글에는 어떻게 Workflow를 작성하는지, YAML의 문법은 어떤지 등에 대해 다뤄볼 예정이다.
Reference >
반응형
댓글