티스토리 뷰
GitHub Action이란?
github에서 공식적으로 제공하는 CI/CD툴로서 개발의 workflow를 자동화할 수 있게 도와주는 틀이다.
CI / CD란?
- 소프트웨어 개발의 전반적인 과정을 자동화 하여 빠른 소프트웨어 제공을 가능하게 하는 개념.
- 비즈니스 로직. 즉, 개발하는것에 더 집중할 수가 있다.
CI(Continuous Integration) - 지속적인 통합
• 모든 사람의 코드를 통합하고 나머지 애플리케이션과 함게 릴리스 인프라를 구축한다.
• 빌드와 테스트의 자동화 과정.
• CI를 성공적으로 구현하면 애플리케이션에 대한 새로운 코드변경 사항이 정기적으로 빌드/테스트되어
공유 리포지토리에 통합된다.
• 협업을 할 때 서로 충돌할 수 있는 문제를 해결할수 있고 변경으로 인해 문제가 생기는 부분이 없도록 보장한다.
• 네스트로 예를 들면 커밋하기 전에 비즈니스 로직을 테스트하거나 테스트 코드를 테스트 할 필요가 없어진것이다.
CI가 자동화로 해주기 때문에!
• 구성 관리, 컴파일, 소프트웨어 빌드, 프로젝트 테스트 및 배포에 유용하게 사용된다.
• CI의 목적 → 주요 목적은 개발자가 서로 코드를 겹치는 것을 방지하고 통합 문제를 제거하는 것!!
• CI의 궁극적인 목표 → 언제든지 프로젝트를 배포할수 있는 것.
CD(Continuous Delivery / Continuous Deployment) - 지속적인 제공 / 지속적인 배포
• 배포의 자동화 과정.
• 지속적인 서비스 제공 또는 지속적인 배포이 두가지 용어의 의미가 상호 교환적으로 사용된다.
• 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해
별도로 사용되기도 한다.
• 서비스 중단 시간을 최소화하여 사용자들이 서비스에 대한 연속적인 접근성을 유지하면서도
최신 버전의 소프트웨어를 이용할 수 있게 하는것을 목적으로 한다.
• 지속적 제공과 지속적 배포 중 어느 것을 선택할지는
개발 팀과 운영 팀의 위험 허용 범위와 구체적인 요구 사항에 따라 달라진다.
지속적 제공
• CI에서 빌드와 단위 및 통합 테스트를 자동화한 다음 검증된 코드를 리포지토리로 릴리스하는 것을 자동화 한다.
• 효과적인 지속적 제공 프로세스를 하려면 CI가 개발 파이프라인에 이미 구축되어 있어야 한다.
• 즉, 개발자의 애플리케이션 변경 사항이 자동으로 버그 테스트를 거치고 리포지토리로 업로드된다는 것을 의미
• 리포지토리에서 운영 팀이 변경 사항을 라이브 프로덕션 환경으로 배포할 수 있다.
• 지속적 제공의 목표
→ 언제나 프로덕션 환경으로 배포할 준비가 되어 있는 코드베이스를 갖추고
새로운 코드를 배포하는 데 필요한 노력을 최소화하는 것
지속적 배포
• CI/CD 파이프 라인의 최종 단계, 지속적 제공의 확장.
• 개발자의 변경 사항을 리포지토리에서 프로덕션으로 릴리스 하는것을 자동화하여 고객이 사용할 수 있도록 하는것.
• 수동프로세스로 인한 운영팀의 업무과다 문제를 해결.
• 파이프 라인의 다음 단계를 자동화함으로써 지속적 제공의 장점을 활용 한다.
• 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 클라우드 애플리케이션을 자동으로 실행할 수 있는 것을 의미
GitHub Action의 주요 구성 요소
1. Workflows
• 자동화 프로세스를 설정할 때 가장 먼저 빌드되거나 생성됨
• 레포지토리 안에 여러개의 Workflow를 가질수 있으며 Workflow별로 용이하게 Job과 Step을 설정할 수 있다.
• 하나이상의 Job을 포함한다.
2. Jobs
• 중요한 빌딩블록이다.
• 여러 Step으로 구성되고, 단일 가상 환경에서 실행.
• 다른 Job에 의존 관계를 가질 수도 있고, 독립적으로 병렬로 실행될 수도 있다.
3. Steps
• Job안에서 하나이상의 단계를 포함하여 지정된 순서대로 실행되는 프로세스 단위이다.
• Job이 가질 수 있는 동작의 나열
• step에서 명령을 내리거나, action을 실행할 수 있다.
GitHub Action [CI] 작동 사이클
GitHub Action은 레포지토리의 지정된 경로에 들어있는 yml을 파일을 읽고 Workflow로 코드를 읽어 종속성을 설치하고
자동테스트를 실행하는 것과 같은 작업을 한다.
즉, Workflows, Jobs, Steps를 정의 한것은 실제 작업이 될것을 정의하기 위한 것이다.
yml파일 구성
yml파일 생성
GitHub Action탭에서 workflow를 생성하게 된다면
이러한 경로에서 생기게 된다.
이 의미는 코드 작업을 할때 직접 yml을 작성하게 된다고 하면 위 경로와 같은 폴더 내부에 생성해 주어야 하는 것.
name: First Workflow
on: workflow_dispatch
jobs:
first-job:
runs-on: ubuntu-latest
steps:
- name: Print greeting
run: echo "Hello World!"
- name: Print goodbye
run: echo "Done - bye!"■ name
- 말그대로 내가 설정하는 workflow의 이름.
■ on
- 언제 workflow가 실행될지 정해준다.
- 깃허브 액션이 보게 될 키워드나 이름을 정하여 workflow를 실행시킬 이벤트를 정의한다.
- 위 yml파일에서 사용한 workflow_dispatch는 수동으로 해당 워크플로를 트리거 할수 있도록한다.
■ jobs
- CI의 파이프라인 설정
- workflow의 기본 작동 단위이며 들여쓰기로 구분한다.(파이썬과 같은 맥락인가?)
- 각 작업은 독립적으로 실행된다.
■ first-job 이지만 job의 고유 이름을 나타냄.
- 단순한 Job 이름.
- first - job이 되어도 되고 lint가 되어도 되며 빌드 작업을 정의하는 이름으로 사용되는 것이다.
- 이 부분에서 설정한 이름은 Jobs들에서 어떠한 작업이 끝나고 작동하도록 하기위해서
사용된다.
ex) needs: first-job → needs가 포함되어있는 곳은 first-job이 끝나야 실행이 가능하다라는 의미.
■ runs-on
- 해당 job을 어떤 OS에서 실행할 것인지 명시.
- 빌드 작업이며 ubuntu환경에서 작업을 하겠다는 것이다.
■ steps, name, run
- name : step의 이름.
- Print greeting이라는 이름의 단계는 echo 명령어를 사용하여 Hello World!를 콘솔창에 출력.
- Print goodbye이라는 이름의 단계는 echo 명령어를 사용하여 Done - bye!를 콘솔창에 출력.
- 여러 개의 셸 명령을 실행해야 할 경우 run뒤에 | 기호를 사용하여 나열 가능.
run: |
echo "Hello"
echo "Hi"이 모든 과정의 단계 요약
workflow의 트리거 작동 → GitHub Action실행 → jobs의 빌드환경읽음 → 해당 jobs의 steps를 읽음 → 단계별로 작동
이 과정을 GitHub Action에서도 확인해 볼수 있다.
※ 주의!!!!!!
이렇게 띄어쓰기를 하나 잘못하게 되면
workflow를 읽지 못하게 되므로 주의해서 작성해야 한다.
Multiple Trigger Event
github action trigger에는 많은 방법이 있다.
그중에서 멀티 트리거 이벤트 방식을 사용할수도 있다.
트리거는 on키워드로 시작한다.
name: test Project
on: [push, workflow_dispatch]
jobs:
test:
runs-on: ubuntu-latest위 와같이
on: [push, workflow_dispatch]로 설정을 하게되면
push될때 트리거가 작동됨과 동시에 수동으로도 트리거를 작동시킨다.
수동으로 작동시키는 방법은 아래 사진과 같다.
더 많은 방법은 GitHub Docs에서 보면 좋다.
Multiple Jobs
GitHub Action의 주요 구성 요소에서 보듯이
jobs는 말그대로 여러개의 job을 가질수 있다.
하나의 들여쓰기를 사용하여 이름을 정하면 그게 하나의 job이 되는데 그것을 여러개 가질수가 있다.
name: test Project
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Get code
uses: actions/checkout@v3
- name: Install NodeJS
uses: actions/setup-node@v3
with:
node-version: 18
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
deploy:
needs: test
runs-on: ubuntu-latest
steps:
- name: Get code
uses: actions/checkout@v3
- name: Install NodeJS
uses: actions/setup-node@v3
with:
node-version: 18
- name: Install dependencies
run: npm ci
- name: Build project
run: npm run build
- name: Deploy
run: echo "Deploying ..."위 코드에서는 jobs는 test와 deploy. 총 두개의 job을 가지고 있다.
그 안에서 각각 job의 실행환경과 스텝들을 지정해줄수가 있다.
uses: actions/checkout@v3
일단 코드를 작성을하면 코드를 받아서 읽을수 있는 환경이 있어야 한다.
GitHub Actions에서 제공되는 일종의 작업 공유 매커니즘인 액션(Action)은
이렇게 빈번하게 필요한 반복 단계를 재사용하기 용이하도록 해준다.
이 액션은 https://github.com/actions/checkout처럼 오픈소스로 되어있고 marketplace에도 들어가 있다.
또한 chechout은 우리가 브랜치를 이동하는것처럼
GitHub Actions 입장에서 바라보면 깃허브의 코드 저장소에 올려둔 코드를 CI 서버로 내려받은 후에 특정 브랜치로 전환하는 행위이다.
즉, GitHub Actions의 Checkout 액션을 사용하여 코드 저장소로부터 CI서버로 코드를 내려받도록 워크플로우를 구성할수있다.
uses: actions/setup-node@v3
마찬가지로 코드를 내려받기 위해서 node모듈도 설치를 해주어야 한다.
node를 설치를 해줄때는 사용하고자 하는 버전에 맞게 with을 사용하여 버전을 설정해 주면된다.
이제 터미널에서 하는것과 동일하게 run이라는 키에서 노드의 모듈들을 버전에 틀리지 않게 설치해주고
테스트 하고자 하는것은 테스트, 배포를 하고자 하는것에는 배포를 해주겠다고 설정해 주면 된다.
위 코드에서 주의 깊게 살펴보면 좋은것이 needs키 이다.
needs를 설정해 주지 않는다면 하나의 워크플로우에 들어있는 Jobs들은 병렬로 진행이된다.
위 사진처럼 테스트를 함과 동시에 배포까지 되는것이다.
하지만 이렇게 되면 테스트가 실패했을 경우에도 배포되는 상황이 발생할수도 있다.
그런 상황을 방지하기 위해 needs를 사용할수도 있다.
needs: JobName을 적게 된다면 해당 Job이 끝나기 전에는 다음 Job으로 넘어가지 않는다.
위 코드와 같이 needs: test를 적게 된다면
이런식으로 병렬이 아닌 직렬로 처리를 할수가 있게 된다.
시간이 느리다는 단점이 생기겠지만 test작업이 성공적으로 끝난 뒤에야 deploy작업을 실행하는 것이니 안정성면에서는 훨씬 안전하게 워크 플로우를 설정할 수 있다.
인용 자료 : Red Hat
'Git & Github&배포' 카테고리의 다른 글
| [CI / CD] Github Action - Matrix를 사용하여 버전 운영하기 (0) | 2024.03.25 |
|---|---|
| [CI/CD] Workflow Event (0) | 2024.03.21 |
| git 명령어 (0) | 2024.03.19 |
| AWS EC2 배포하기 (0) | 2024.01.23 |
| git 파일 용량 에러 (0) | 2024.01.10 |