Judaeng
GitHub Actions 알아보기 본문
이번 글은 CI/CD 중 CI가 무엇인지 알아보고 CI를 GitHub Actions를 통해 실습해보는 시간을 가질 예정이다.
실습 내용들은 드림 코딩 엘리의 CI/CD를 위한 깃허브 액션 10분 정리를 보고 실습했습니다🤪
CI(Continuous Integration)란?
(1): CI(Continuous Integration)는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다.
(2): 지속적인 통합이고 정기적으로 코드를 개발하고 그 코드를 테스트하고 통합하는 것을 의미한다.
GitHub Actions란?
GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD(지속적 통합 및 지속적 전달) 플랫폼이다.
리포지토리에 대한 모든 pull 요청을 빌드하고 테스트하는 워크플로를 만들거나 병합된 pull 요청을 프로덕션에 배포할 수 있다.
GitHub Actions는 DevOps를 넘어 리포지토리에서 다른 이벤트가 발생할 때 워크플로를 실행할 수 있다.
예를 들어, 누군가가 저장소에 새 문제를 생성할 때마다 적절한 레이블을 자동으로 추가하는 워크플로를 실행할 수 있다.
GitHub Actions의 작업 구성 요소
GitHub Actions는 크게 5가지 개념만 알고 있으면 된다고 한다.
Events, Workflows, Jobs, Actions, Runners 등이 있다.
GitHub Actions는 특정한 이벤트가 발생했을 때 내가 원하는 일을 자동으로 수행할 수 있도록 만들어주는 툴이라고 한다.
Events
어떤 일이 발생했는지를 지정할 수 있는 Event를 이해해야 한다.
Event는 GitHub에서 발생할 수 있는 대부분의 이벤트를 지정할 수 있다.
이벤트는 워크플로 실행을 트리거하는 리포지토리의 특정 활동이다.
예를 들어, 누군가가 pull 요청을 생성하거나, 문제를 열거나, 커밋을 리포지토리에 푸시할 때 GitHub에서 활동이 시작될 수 있다.
Main 브랜치로 머지할 때 어떤 테스트를 수행해야 한다면 그 이벤트를 지정해 줄 수도 있다.
Workflows
특정한 이벤트가 발생했을 때 내가 어떠한 일을 수행하고 싶은지를 명시할 수 있는 것이 Workflows이다.
Jobs
하나 또는 다수의 Job이 있을 수 있다.
병렬적, 동시 다발적으로 진행될 수 있다.
어떤 식으로 실행해야 되는지 명시해줄 수 있다. 예를 들어 쉘 스크립트로 진행 프로세스를 명시해줄 수도 있다고 한다.
예를 들어 npm test, npm install, npm run e2e-test 등이 있다.
Actions
작업은 복잡하지만 자주 반복되는 작업을 수행하는 GitHub Actions 플랫폼용 사용자 지정 응용 프로그램이다.
Runners
Job을 실행하는 것이 Runners라고 할 수 있다.
예를 들어, VM 머신이라고 볼 수 있고, Docker Container라고도 볼 수 있다고 한다.
각각의 잡들은 개별적인 독립적인 '러너'라는 컨테이너에서 실행된다고 보면 된다고 한다.
보통 러너에서 실행된다고 한다.
드림 코딩 엘리 과정 따라 하기 정리
1. 엘리의 영상을 보면서 CI/CD, GitHub Actions 개념 정리(위에처럼)
2. 개념이 어느 정도 정리되었으면 엘리 node 코드 손 코딩
3. 손 코딩이 다 진행되었으면 npm test 명령어를 확인하고 잘 나온다면 계속 진행한다.
4. 내 GitHub에 actions-example Repo 생성
5. Actions 생성 -> Node.js를 베이스 해서 빌드하고 테스트
6. Actions에서 yaml(yml) 파일을 수정한다. (수정 사항은 아래 따로 설명)
GitHub Actions을 사용하기 위해서 우리 프로젝트 경로 안에. github/workflows/workflow.yml 경로에 야믈파일을 만들어주면 된다고 한다.
무작정 따라해보기 START🎬
1번은 넘어가도록 하고 2번 엘리 node 코드 손 코딩부터 차근차근 정리해보자.😄
'action-example'이라는 폴더를 만들어주자. (원하는 곳에 만들어주면 된다.)
VSC(Visual Studio Code)를 사용해서 폴더를 열어주고 아래 사진처럼 src, test 폴더를 만들어준다.
그리고 src 안에는 index.js를 만들어주고 test 폴더 안에는 index.test.js를 아래 코드처럼 만들어주자.
src/index.js
이 코드는 팩토리얼 알고리즘을 구현하는 소스코드를 가진 심플한 프로젝트라고 한다.
// Computes a factorial of a given positive integer
function factorial(n) {
if (n < 0) {
throw new Error('Factorial is only defined for non-negative integers!');
}
if (n == 0){
return 1
}
return n * factorial(n - 1);
}
module.exports = factorial;test/index.test.js
아래 코드는 위에 팩토리얼 알고리즘이 정상적으로 동작하는지 검증하기 위한 테스트 코드라고 한다.
const factorial = require('../src');
describe('Factorial function', () => {
it('correctly computes factorial of a positive integer number', () => {
expect(factorial(3)).toEqual(6);
});
it('throws an error if a negative input is provided', () => {
expect(() => {
factorial(-1);
}).toThrow('Factorial is only defined for non-negative integers!');
});
})
위에 디렉터리처럼 만들고 코드도 따라 했다면 이제는 npm을 설치해주어야 한다.
그리고 안에서 테스트 코드를 실행하고 확인하려면 'jest'라는 라이브러리를 설치해주어야 한다.
아래 명령어를 입력해주자.
npm install jest입력했다면 package.json에 script를 test로 지정해주어야 npm test 명령어를 입력해 테스트를 확인할 수 있다.
아래처럼 입력해주자.
package.json
{
"main": "src/index.js",
"author": "Dream Kangcoding <Kang@dream-coding.com>",
"license": "MIT",
"devDependencies": {
"jest": "버전 정보"
},
"scripts": {
"test": "jest"
},
"jest": {
"testEnvironment": "jest-environment-node"
}
}다 완성되었다면 npm test 명령어 입력을 통해 테스트 코드가 정상적으로 다 작동하는 것을 확인해보자.
만약 안된다면 구글링이나 엘리의 영상을 찾아보면서 해결해보자.
이제는 깃허브에 있는 액션 기능을 통해 개념을 알아보고 어떻게 돌아가는지 확인해보자.
깃허브 액션 개념 - 예제 코드
아래처럼 Actions 메뉴에 오게 되면 우리 프로젝트 특성에 따라서 어떤 것이 적절한지 자동적으로 템플릿을 추천해준다고 한다.
우리는 Node.js를 이용해서 테스트하고 빌드하는 것을 하려고 하기 때문에 아래 사진에 Node.js를 configure 해주자.
Configure 버튼을 누르고 진행하면 아래처럼 yml 파일이 자동적으로 만들어진 것을 확인할 수 있다.
기본적인 템플릿이 만들어졌다고 생각하면 된다.
오른쪽 Marketplace 탭에서는 다양한 액션들을 검색해볼 수 있다고 한다.
그리고 Documentation 탭을 보게 되면 기본적인 문서도 확인할 수 있다고 하니 기억하고 있자.
강의대로 파일 이름을 변경해보자. node.yml -> ci.yml
아래 yml 파일 안에 name도 Example CI로 변경!
그 아래 on 옵션은 이 workflows가 실행될 수 있는 이벤트를 등록할 수 있다.
이 템플릿에 기본은 메인 브랜치에 커밋이 푸시될 때마다 또는 메인 브랜치에 풀 리퀘스트(PR)가 발생할 때마다 이 Workflows가 실행될 수 있도록 등록해주는 것이다.
이런 이벤트가 발생할 때 어떤 일을 할 건지 명시할 수 있는 Jobs 옵션에 오면 jobs의 이름을 build 대신 test로 지정을 해준다.
위에 명시된 이벤트가 발생할 때마다 테스트를 수행하는 잡을 만들어본다.
어디서 실행할 건지는 우분투 최신 버전으로 지정이 되어 있다.
GitHub Docs -> Using workflows -> Workflow syntax 경로 문서에 들어가서 확인해보면 어떤 머신이 사용 가능한지 여부를 확인할 수 있다. ex) Window, macOS, ubuntu 등등
아래 strategy를 보면 우리는 사용하지 않을 거지만 간단히 설명한 것을 정리하려고 한다.
각각 다른 환경에서 여러 번 동작해야 하는 경우 사용할 수 있다고 한다.
지금 아래 사진 같은 경우에는 동일한 잡을 각각 다른 노드 버전에서 실행해서 각각의 다른 노드 버전에서도 잘 동작하는지 검증하고 싶은 것이다.
하지만 우리는 간단하게 만들 것이기 때문에 생략해준다.
steps 옵션에 여러 가지 옵션이 있는데 actions/checkout@v3 이렇게 앞에 actions가 붙으면 Marketplace에서 이게 어떤 일을 하는 친구인지 확인할 수 있다고 한다. Marketplace를 잘 활용해보자.
중간에 빠진 설명들은 아래 yml 파일 수정 사항 설명을 또 따로 정리해두었으니 이쯤에서 마무리하고 넘어가자.
다 완성되었다면 오른쪽 위에 start commit 버튼을 누르고 initial ci.yml 파일을 커밋해준다.
그럼 아래처럼 workflows 디렉터리 안에 우리가 방금 작성한 yml 파일이 만들어진 것을 확인할 수 있다.
위에 사진처럼 만들어졌다면
Actions 메뉴에 들어가서 확인해보면 아래 사진과 같이 하나의 workflows가 동작하고 있는 것을 확인할 수 있다.
토글들을 하나씩 클릭해서 확인하면 우리가 명시한 잡들이 하나하나씩 단계별로 실행되는 것을 확인해볼 수 있다.
단계별로 다 통과한다면 옆에 체크박스가 초록색 불이 뜬 것을 확인할 수가 있다.
그렇다면 방금 푸시한 커밋에 아무런 문제가 없다는 것을 확인해볼 수가 있다.
이렇게 각각의 단계를 확인해볼 수가 있고 얼마나 시간이 걸렸는 지도 확인해 볼 수 있다고 한다.
npm test에 들어오면 성공한 테스트들도 확인해볼 수가 있다.
다시 프로젝트로 돌아와서 이번엔 고의적으로 문제를 일으켜 보도록 하자.
index.js 파일에 주어진 인자가 음수인지 아닌지 확인하는 코드를 주석 처리해보자.
npm test를 실행했을 때, 테스트 하나가 실패하는 것을 확인한 후에 다시 내 Git Repo에 푸시해보자.
이렇게 잘못된 코드가 있는데 바로 커밋하고 메인 브랜치에 푸시했을 때 어떤 반응이 나타날지 확인해보자.
다시 actions로 돌아와서 확인해보면 우리의 workflows가 잘 실행되고 있는지 확인하고 잘 실패했는지, 어디가 실패했는지 확인해보자.
확인해보고 고의적으로 실패한 코드를 바로 잡아서 처음 그대로 만들어보고 PR 테스트를 진행해보자.
이번에는 풀 리퀘스트를 실습해보자.
앞에서 고의적으로 실패한 코드를 바로 잡아서 내 모든 테스트가 성공할 수 있도록 만들고 푸시해보도록 하자.
다시 프로젝트로 돌아와서 브랜치를 새로 하나 만들어야 한다.
git checkout -b break-tests위에 git 명령어로 브랜치를 새로 하나 만들어준다.
이 브랜치에서는 또 고의적으로 실패하는 코드로 커밋을 만들어보도록 하자.
add, commit, push 과정을 해주고 main 브랜치에 풀 리퀘스트(PR)를 보내주도록 하자.
'break-tests'라는 브랜치에서 main 브랜치에 권유하는 것이다.
'내 브랜치를 main 브랜치에 merge 하고 싶다. 내 것을 승인해줘'라고 하는 것이다.
다시, 잘못된 코드를 메인 브랜치에 푸시하게 되면 PR단계에서 workflows가 실행되는 것을 확인할 수 있다.
아래 사진은 '네가 풀 리퀘스트를 준 것 중에 실패가 있어!!!'라는 것을 PR 단계에서 알려준다.
위에처럼 문제가 있는 것을 확인하고 문제를 다시 재검토하고 수정하여 다시 풀 리퀘스트(PR)를 하게 되어 성공하게 되면 아래처럼 초록색 불이 뜨게 된다.
위에 사진을 마지막으로 정리를 마치겠다ㅠㅠ😭
"생각보다 번거로운데?"라고 생각할 수 있지만 막상 실습해보면 재밌고 시간도 금방 간다는 것을 확인할 수 있다.
한 번씩은 경험해보는 것이 좋은 것 같다ㅎㅎ;
yaml 파일 수정 사항 설명
strategy는 다른 노드 버전에서도 잘 돌아가는지 확인하고 테스트하는 옵션이라고 한다. 하지만 엘리 강의에선 포함하지 않는다는 것! 이 옵션을 빼고 진행합니다.
-name 옵션에 Use Node.js ${{ matrix.node-version }} 이것을 Setup node.js 14.x로 수정 왜냐하면 14.x 버전으로 테스트하겠다고 명확하게 이야기해주는 것 with: node-version: 이곳도 ${{ matrix.node-version }} 이것을 14.x로 수정 이유는 위와 같음
-run: 기본적으로 빌드해주는 옵션 npm run build —if-present 이 줄은 삭제, 이유는 별도의 유닛 테스트를 위해서 별도로 빌드할 필요가 없어서 생략할 수 있다.
🤔 블로그 정리 후, 느낀 점
GitHub Actions을 잘 정리해놓은 지인이 있었는데 그것을 보고 실습한 내용을 내 블로그에도 정리할 예정이었다.
근데 계속 미루다가 정리 못했는데 유튜브 알고리즘에 "드림 코딩 엘리 깃허브 액션!!!" 이렇게 뜬 것을 보고 뭐에 홀린 듯이 따라 하고 정리해버렸다ㅋㅋ
지인 블로그도 물론 따라 해 보았다. 다른 Repo에 연습용으로 따라 해보기도 했다.
생각보다 따라 하기 너무 쉬웠고 중간에 테스트를 통해 코드가 잘 작동 안 되는 것을 눈으로 확인하는 것도 즐거웠다😏
GitHub Actions 5가지 개념은 내 블로그에 정리가 잘 안 된 것 같은데 공식문서를 통해 더 알아봤으면 좋겠다ㅠㅠ
설명하기가 쉽지 않더라... 맞니?
어쨌든 생각보다 재밌었고 무작정 따라 하고 정리하는 글이지만 그래도 어려울 수 있는 사람들이 있기 때문에 자세하게 내 경험을 녹여내어 글을 써본다(피드백은 언제나 환영입니다😎)
📝 이번 게시물을 만들기 위해 참고한 사이트
1. 드림 코딩 엘리 Youtube - 제발 깃허브 액션🔥모르는 개발자 없게 해 주세요🙏🏻