CI/CD
필자는 지금까지 앱 출시를 목적으로 도전 중에 있다. 개발에 변경사항이 생길 때마다 또는 오류 발생시 코드를 수정하고 깃허브에 푸시하고, 오라클의 인스턴스에 ssh로 접근해서 클론하고 빌드해서 서버를 배포하는 과정을 열댓번 정도 한거 같다. 하면서 느꼈던 점은 아.. 이거를 어떻게 자동화할 수 있는 방법이 없을까 였고 이 시점에서 CI/CD 기술은 나에게 너무나도 필요한 기술이 되었다. youtube에 jscode 박재성님의 강의를 하나씩 따라가면서 github Actions 과 CI/CD를 하나씩 파헤쳐 보겠다.
깃허브 액션을 선택한 이유는 Jenkins 와 달리 별도의 빌드용 서버를 갖출 필요가 없고, 무료이기 때문에 선택했다.
Github Actions
github actions 를 로직을 실행시킬 수 있는 컴퓨터라고 생각하자 CI/CD 과정에서 Actions는 "빌드, 테스트 배포" 에 대한 로직을 실행시키는 역할을 한다.
CI/CD
CI/CD 흐름은 이렇다. 개념은 실제 spring boot를 배포할 때 정리해보겠다.
- 개발자가 코드 작성 후 커밋 & 푸시
- 깃허브가 푸시 action을 감지해서 깃허브 액션에 작성한 로직 실행(빌드 -> 테스트 -> 서버로 배포)
- 서버에서 배포된 최신 코드로 서버를 재실행
GitHub Actions 기본 문법 정리
자 개념을 알아보기 전에 간단한 프로세스를 따라오면서 Actions를 먼저 실행해보자
-
깃 레포 먼저 생성
-
deploy.yaml 작성하기
name: Github Actions 실행시켜보기 on: push: branches: - main jobs: My-Deploy-Job: runs-on: ubuntu-latest steps: - name: Hello World 찍기 run : echo "Hello World" -
본인이 생성한 로컬의 프로젝트 폴더에 .github/workflows 라는 하위 디렉토리를 만들어서 여기에 yaml 파일을 저장해 둔다
-
위에서 새로 생성한 레포와 로컬 레포를 연결한다.
git init git add . git commit -m "first commit" git remote add origin https://github.com/tomchaccom/github-actions-prac.git git remote -v git push git push --set-upstream origin master\n푸시가 완료
- 깃허브 상단에 actions에 들어간다
내가 작성한 커밋이 Actions에 추가되어 있다는 것을 확인했다. 여기서 주의점은 yaml 코드에 on:push:branch:main 설정을 첫줄에 적었는데, main에 커밋이 푸시되지 않으면 이 Actions은 동작하지 않는다는 점을 유의하자
접속하면 이렇게 내가 yaml 코드에 적은 동작이 수행되었음을 알수 있다. 이제 github Actions 문법에 대해서 알아보겠다
YAML(workflow) 분석하기
이제 yaml 파일을 보면서 하나씩 분석을 시작해 보겠다. 이 하나의 YAML 설정을 workflow라고 한다
github actions에서 사용하는 개념
workflow : yaml에 정의되어 있는 작업들, YAML 파일 그 자체
Event : 이 workflow가 실행되는 시점
Jobs : workflow에 존재하는 작업 단위, workflow는 한개 이상의 jobs을 가진다
step : Job 내부에 어떤 동작을 수행할건지에 대한 내용을 정의
name: Github Actions 실행시켜보기 // workflow의 이름을 정하기
// 깃허브에 어떤 액션이 발생했을 때 로직을 실행시키겠다.
// Event : 실행되는 시점을 설정
// 아래 코드는 main branch에 push 되었을 때!
on:
push:
branches:
- main
# 하나의 워크 플로우는 한개 이상의 job으로 구성되고
# 여러 job은 기본적으로 병렬 수행된다.
jobs:
# job을 식별하기 위한 식별자
My-Deploy-Job:
# 깃허브 액션은 로직을 실행하는 컴퓨터, runs-on은 운영체제와 버전을 선택
runs-on: ubuntu-latest
# steps: 특정 작업을 수행하는 가장 작은 단위
steps:
- name: Hello World 찍기
# run 리눅스 명령어로 동작을 수행
run : echo "Hello World"
workflow에 step 추가하기
이번에는 step을 한번 추가해보면서 push 해보면서 결과도 확인해보고, 각종 유용한 설정 및 step을 작성해보자
name: Github Actions 실행시켜보기
on:
push:
branches:
- main
jobs:
My-Deploy-Job:
runs-on: ubuntu-latest
steps:
- name: Hello World 찍기
run : echo "Hello World"
- name : 여러 명령어 문장 작성하기
run : |
echo "good"
echo "Morning"| 을 사용하면 여러 명령어 문장을 작성할 수 있다. 이제 다시 push 하고 Actions를 확인해보자
내가 적용한 두번째 푸시에 대한 Actions가 생성되었음을 확인했다 내부를 들어가서 확인해보면 내가 추가한 "여러 명령어 문장 작성하기" step이 실행되었음을 확인할 수 있다
$GITHUB_SHA // 현재 해당하는 커밋의 해시값
$GITHUB_REPOSITORY // 깃허브의 레포명그런데, 레포에 접근하면 다른 사람이 Actions에 들어와서 step에서 사용하는 변수 값을 확인할 수 있다. 이제 나만 볼수 있는 변수를 설정해 보겠다.
setting -> secrets and variable -> Actions -> new repository secret
settins 에 왼쪽 Security 구역에 secrets and variable 을 선택
actions 를 선택
들어오면 new Repository secret을 선택
비밀로 할 변수의 이름을 입력하고, secret 안에 내용을 적으면 된다.
이제 두개의 시크릿이 만들어졌다. YML을 다시 작성해보고 push 후 결과를 확인해보자
이전에는 현재 화면에서 명령어의 실행결과가 잘 보였지만 현재는 보이지 않는 모습이다!
github Actions 의 구조
특정 Event가 발생했을 때 workflow가 실행이되고, 이 workflow는 한개의 이상의 job으로 구성되어 있으며, 이 job에는 여러개의 step이 존재한다 .
우리가 작성한 yml 기준으로는 main에 push가 발생했을 때 = Event, jobs에는 Hello world 찍기, 여러 명령어 출력하기 등의 step이 job을 구성하고 있다는 것을 알 수 있다.
글을 마치며
오늘은 강의를 보면서 배웠던 내용을 정리해보았다. 항상 새로운 기술을 접할 때 타 기술 블로그를 참고하면서 시도했을 때는 Event가 뭐고, workflow는 뭐고 yaml 은 왜 작성하는지에 대한 근본적인 의문이 생기기 마련인데, 강의를 보면서 실제로 만들어보면서 이 개념이 어디에 적용되는지를 눈으로 보고 배우는 것이 그냥 개념만 먼저 공부하는 것보다 10배는 더 효율이 좋다고 생각한다. 다음 시간에는 스프링 부트 서버를 github Actions를 통해서 배포하는 법에 대해서 알아보겠다
