Github Action
Github Action은 CI/CD를 위한 툴! 그렇다면 CI/CD가 뭔지 알아야 한다.
1. CI/CD
요즘같이 빠르게 변화하는 시대는 “어떻게 하면 시장과 고객의 요구에 빠르게 반응해서 제품 출시, 업데이트를 할 것인가!!”가 포인트.
CI/CD는 어플리케이션 개발 단계부터 배포 때까지 이 모든 단계들을 자동화를 통해서 조금 더 효율적으로 빠르게 사용자에게 빈번이 배포할 수 있도록 만드는 것을 말한다!
1) CI(Continuous Integration) : 지속적인 통합
버그 수정이나 새로 만드는 기능들이 매일 Repository에 주기적으로 Build되고 Test가 되어서 머지되는 것!
포인트는 두 가지이다.
1. 코드 변경사항을 주기적으로 빈번하게 머지해야 한다.
두 명의 개발자가 서로 다른 코드를 작성하는데 한참 작성하다가 머지하려고 하면 충돌을 해결하는데 시간을 더 많이 쓸 수도 있다. 그래서 최대한 작은 단위로 나누어서 개발하고 통합해 나가는 것이 중요함!
2. 통합을 위한 단계(빌드, 테스트, 머지)의 자동화
Repository에 코드들이 Merge가 되었다면 코드 변경 사항 이후에도 어플리케이션이 돌아가는지 확인을 해봐야 한다!
보통 이런 식으로 셋업이 된다.
- PR이 올라가는 즉시, 팀에서 쓰여진 CI스크립트를 통해 변경된 코드가 잘 Build되는지, 작성한 Unit Test는 잘 통과 되는지 확인한다.
- Green 사인이 나오면 팀에게 코드 리뷰를 받고, 코드가 적절한지 확인을 받은 후 적절하지 않다면 다시 PR을 올려 1번부터 반복!
- PR 통과!
CI 원칙을 따랐을 때의 장점은 어떤 것이 있는가?
첫 번째 포인트에서 얘기를 하면 주기적으로 머지를 하기 때문에 머지 충돌을 피할 수 있고, 생겨도 금방 수정이 가능하다. —> 개발의 생산성을 더 높일 수 있다. 주기적으로 머지를 하면 코드의 변경 사항이 적기 때문에 빠른 문제 해결이 가능하다!
머지되는 모든 코드들은 자동으로 Build되고 Test되기 때문에 코드의 결함이나 문제점이 빠르게 발견될 수 있다! —> 팀원들도 아 적어도 이 사람거 머지한다고 어플리케이션이 안 돌아가던지 하는 탈은 안나겠구나 알 수 있는 1차 거름막같은 느낌..
그리고 더 나은 퀄리티의 코드를 가질 수 있다. —> CI를 잘 운영하기 위해서는 모든 개발자들이 자신이 새로 작성하는 코드에 한해서 무조건 Unit Test를 포함시켜야 한다.
2) CD(Continuous Delivery / Deployment) : 지속적인 제공 / 배포
- CI 서버를 통해서 주기적으로 머지된 코드의 변경사항들이 자동으로 Build가 되고
- Test가 되었다면 배포할 준비를 거치고(Prepare Release)
- 준비된 Release가 괜찮은지, 정상적인지, 아무런 문제가 없는지 직접 개발자나 검증 팀이 검증을 한 다음에 아 이제 사용자에게 최종적으로 배포해도 되겠다!라고 결정이 되면 수동적으로 사용자에게 배포하는 단계 → Continuous Delivery
Release가 준비가 되자마자 자동으로 사용자에게 배포할 수 있도록 만들 수도 있는데, 이렇게 모든 과정을 자동화 해놓는 것을 Continuous Deployment라고 한다.
최종 단계가 자동화가 되었는지, 되지 않았는지에 따라서 살짝씩 달라질 수 있다.
이 모든 과정을 어떻게 자동화를 해두냐 어떻게 스크립트를 쓰느냐 그리고 이 자동화와 테스팅에 대해서 얼마나 자신감이 있느냐에 따라서 어떤 회사는 지속 제공하는 단계가 있고, 어떤 회사는 지속 배포를 이용하는 경우도 있다. 회사마다 어느 정도의 얼마 만큼의 자동화를 하냐가 달라지기 때문에 CI / CD라고 해서 모든 회사가 똑같은 프로세스를 거치는 것은 아니다. 회사마다 팀마다 다른 방식으로 적용해서 사용할 수 있다.
CI/CD는 완벽히 분리된 것이 아니라 대부분의 회사에서 CI/CD를 거쳐서 배포를 하기 때문에 CI/CD를 묶어서 부르곤 한다.
CI / CD 파이프 라인 정리
개발자가 작은 단위로 기능을 나누어서 주기적으로 main Repository에 머지를 하면, 자동으로 Build를 하고, Test과정을 거쳐서, Release 준비를 하고, 여기서 수동적으로 또는 자동으로 최종 배포를 거치게 된다.
CI/CD를 위한 다양한 툴
2. Github Action의 구조
2018년 도입! 특정한 Event가 발생했을 때, 내가 원하는 일을 자동으로 수행 할 수 있도록 만들어주는 툴
1) Github Acitons 정리
(1) Events
on:push
어떤 일이 발생했는지를 지정할 수 있는 Event. Github에서 발생할 수 있는 대부분의 이벤트를 지정할 수 있다. 예를 들면,
- 내 PR을 main 브랜치로 머지할 때
- 새로운 issue를 누군가가 만들 때,
- commit을 깃허브에 push할 때,
이런 event를 지정해 줄 수 있다.
(2) Workflows
어떤 특정한 event가 발생했을 때, 어떤 일을 수행할 것이냐 명시할 수 있다.
(3) Jobs
Workflow 안에는 Job이 있다. Workflow는 하나 이상의 Job을 가진다. 하나의 Job은 무언가를 한다. 예를 들면,
- unit test를 실행한다.
- E2E test를 실행한다.
※ E2E 테스트는 End To End 테스트의 약자로 애플리케이션의 흐름을 처음부터 끝까지 테스트하는 것을 의미. 유닛 테스트나 통합 테스트는 모듈의 무결성을 증명할 수 있는 강력한 테스트이지만, 모듈의 무결성이 애플리케이션 동작의 무결성까지는 증명해 줄 수 없다. 그래서 E2E 테스트 과정에서는 실제 사용자의 시나리오를 테스트함으로써 애플리케이션 동작을 테스트하게 되고, 이 테스트를 통과함으로써 애플리케이션의 무결성을 증명할 수 있게 된다.
Job들은 병렬적으로, 동시 다발적으로 실행이 된다. 순차적으로 실행이 되도록 만들 수도 있다.
Job에는 어떤 순서대로 실행이 되어야 하는지 명시해주는 step이 있다.
Job: run unit tests
step1: action check out # 리포지토리 체크
step2: npm test
Job: run E2E tests
step1: action check out
step2: action setup node # 자동으로 node 환경을 setup할 수 있는 코드 실행
step3: npm install
step4: npm run e2e-test
(4) Actions
GitHub에서 제공해주는 action에서 쓸 수 있는 유용한 기능들
(5) Runners
Job을 실행하는 머신, VM 머신이라고 볼 수 있고 도커 컨테이너라고도 볼 수 있다. Job들은 개별의 runner에서 실행된다.
2) 예시
name: learn-github-actions
on: [push] # 언제 실행되도록 할 것인지
jobs:
check-bats-version: # job 이름
runs-on: ubuntu-latest # 무슨 환경에서 실행할 것인지
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
3. 실제 깃허브에서 써보기
간단하게 깃 레포지토리 파고 POST 방식의 createPost() 메서드가 있는 gradle spring 프로젝트를 만들어서 액션을 만들어 보자!
4. 트러블 슈팅 기록
Error: Gradle script '/home/runner/work/~' is not executable.
git에 파일을 실행할 권한을 주어야 하는데 두 가지 방법이 있다.
- git bash를 사용하여 실행시킬 권한을 주는 방법
- workflow에 권한을 주는 코드를 입력하는 방법
2번으로 작성하여서 통과!
Error: Gradle script '/home/runner/work/~' is not executable. 해결
spring boot 프로젝트를 github action을 이용해서 CI는 중 에러가 발생했다. 찾아보니 해결책이 3개 였는데, 3번째는 제외했다. script에서 권한을 주는 방법. - name: Run chmod to make gradlew executable run: chmod +x
devhooney.tistory.com
every step must define a uses or run key
- uses: actions/checkout@v3
- name: Set up JDK 11
uses: actions/setup-java@v3
with:
java-version: '11'
distribution: 'temurin'
라고 적었더니 난 오류! - uses와 - name이 붙어 있으니까 뭔가 오류가 나는 것 같아서
- name: 레포지토리 체크아웃
uses: actions/checkout@v3
- name: JDK 11 설치
uses: actions/setup-java@v3
with:
java-version: '11'
distribution: 'temurin'
라고 해주어서 해결!
Springboot 프로젝트 Github Action을 이용해서 배포 자동화하기
###🔥 주의 🔥 해당 글은 에러와 실패 과정을 모두 포함한 글이므로 만일 따라하실 때는 다 읽으시고 正道만 걸으시라는 뜻..... 참고 블로그 (처음에 따라할 때 ) https://stalker5217.netlify.app/devops/git
velog.io
FAILURE: Build failed with an exception. * What went wrong : A problem occurred configuring root project 'junit5-practice'.
아직 테스트 코드를 작성하지 않아서 그런가 싶어서 테스트 관련 빌드 에러로 생각하고 테스트 스킵하고 빌드하는거로 코드 변경
안된다. 좀 더 찾아보니
[Spring] A problem occurred configuring root project '...' 에러 해결
Spring Initializr를 통해 Spring 프로젝트 파일을 생성하고, build.gradle을 실행하면 다음과 같은 오류가 발생할 때가 있다. A problem occurred configuring root project '...' 이유는 Spring boot 3.x 버전은 JAVA 17부터 지
da-y-0522.tistory.com
이 페이지에서 Spring Initializr를 통해 Spring 프로젝트 파일을 생성하고, build.gradle을 실행하면 다음 오류가 발생할 때가 있다고 했다. Spring Boot 3.x 버전은 Java 17부터 지원을 하는데, Java 버전이 맞지 않으면 그럴 수 있다고..!
그래서 Github action JDK 17 설치하는 방법을 찾아 보았다.
[Git] Gradle JDK 17용 Github 워크플로 Github workflow 작성 방법 (Git Actions)
Intro 안녕하세요. 이번 시간에는 JDK 17용 Github 워크플로 Github workflow 작성 방법에 대해 알아보겠습니다. 참고로 github workflow에 대해 궁금하신 분 계시면 일전에 제가 작성한 포스팅 글 ([GitHub Actions
steady-learner.tistory.com
이 페이지에서 JDK를 17버전으로 설치하는 코드를 찾아서 workflow 수정.
ㅠㅅㅜ 일단 되긴 되었다.. 일단 초기 설정은 끝낸 것 같다.
원래 목표는 JUnit5 강의 듣고 테스트 코드 작성 후 action으로 검증해보는 것까지 였는데 거기까지는 못했다!
테스트 코드 외의 기능은 다음 주에 튜터님들께 질문을 해보고 추후 여기에 기록하기
참고 자료
action에는 어떤 event가 있는지
Events that trigger workflows - GitHub Docs
You can configure your workflows to run when specific activity on GitHub happens, at a scheduled time, or when an event outside of GitHub occurs.
docs.github.com
어떤 환경변수가 있는지
Contexts - GitHub Docs
Contexts are a way to access information about workflow runs, variables, runner environments, jobs, and steps. Each context is an object that contains properties, which can be strings or other objects. Contexts, objects, and properties will vary significan
docs.github.com
checkout의 기능에 대해 설명해 놓은 깃허브
GitHub - actions/checkout: Action for checking out a repo
Action for checking out a repo. Contribute to actions/checkout development by creating an account on GitHub.
github.com
생활 코딩 유튜브 - “github.com - action”
드림 코딩 유튜브 - CI/CD 5분 개념 정리(현업에서 쓰는 개발 프로세스)
드림 코딩 유튜브 - 제발 깃허브 액션 모르는 개발자 없게 해주세요
'STUDY > GIT' 카테고리의 다른 글
[TIL] Github Action 3 - Mockito 테스트(O) (0) | 2023.08.03 |
---|---|
[TIL] Github Action 2 - Workflow 구성해보기(작성 중) (0) | 2023.08.01 |
[Git] fork가 아니라 같은 Repo의 Collaborator일 때, Pull Request 방법 기록(레포지토리 파는 사람 / Collaborator) (1) | 2023.07.17 |
[TIL] 포크 저장소와 내 로컬을 동기화하기 (0) | 2023.06.18 |
[TIL] 풀리퀘스트로 코드 리뷰하기! (0) | 2023.06.13 |