저번 시간에 CI/CD에 대해서 간단하게 공부해봤으니 이번에는 툴 하나를 정해서 사용해보려고 합니다.
Jenkins, AWS Codepipeline 등 유명한 CI/CD 툴이 많지만 이번에는 github action을 사용해보려고 해요!
전세계적으로 많이 사용되는 github에서 지원하는 CI/CD 기능으로 진행 중인 프로젝트에 아주 간단하게 적용할 수 있는데 같이 공부해봐요!
2. 1. CI가 뭐죠?
● Continuous Integration
● 개발자를 위한 자동화 프로세스
○ 새롭게 수정한 소프트웨어가 빌드가 되는지 자동으로 확인
■ 단순 컴파일 에러가 발생하는 경우
■ 새로운 라이브러리를 필요로 하는 경우
■ 라이브러리의 버전이 컴파일에 영향을 끼치는 경우
○ 새롭게 수정한 소프트웨어가 테스트를 통과하는지 자동으로 확인
■ 인터페이스가 삭제 혹은 변경된 경우
■ API의 로직이 변경되어 동일한 값을 반환하지 않는 경우
3. 1. CI가 뭐죠?
● Continuous Integration
● github에 코드 푸시하면 미리 입력해놓은
빌드, 테스팅 스크립트를 실행시켜주면서
코드에 이상이 없나 확인해주는 도구
8. 이벤트 모니터링
● 대표적으로 push, pull_request
● master, develop 브랜치와 feat/ 으로 시작하는 브랜치들을 모니터링
https://docs.github.com/en/actions/reference/events-that-trigger-workflows
on:
push:
branches:
- master
- develop
- 'feat/**’
9. 작업 목록
● 하고 싶은 모든 작업을 실행할 수 있음
● 빌드 후 테스트 steps:
- uses: actions/checkout@v2
- name: Build
run: |
cd src
go get
- name: Run test
run: |
cd cachelib; go test -failfast -v
cd ../dblib; go test -failfast -v
cd ../fetcher/tests; go test -timeout 1800s -v -failfast
cd ../../resolver/tests; go test -failfast -v
cd ../../manager/robot/tests; go test -failfast -v
cd ../../mission/tests; go test -failfast -v
10. 너무 너무 간단한 Hands On Lab
github에 임시로 저장소를 만들어서 아래의 프로그램을
빌드, 실행 후 도커 이미지 빌드, 푸시하는 워크플로우 파일 작성해보기
#include <cassert>
int AlwaysSuccees()
{
return 0;
}
int main()
{
assert(AlwaysSuccees() == 1);
return 0;
}
FROM ubuntu:latest
WORKDIR /work
COPY . .
RUN apt update &&
apt install -y -qq gcc g++
RUN g++ main.cpp -o main
CMD [“./main”]
11. 로컬환경에서 작업한다면
1. main.cpp 작성
a. Ctrl-C + Ctrl-V
2. 빌드
a. g++ main.cpp -o main
3. 실행
a. ./main
4. 도커 이미지 빌드
a. docker build --tag too-simple-hol .
5. 도커 이미지 푸시
a. docker push too-simple-hol:latest
12. github action으로 똑같은 작업을 하기 위해서는?
1. 레포지토리에 코드가 푸시될 때마다 빌드, 실행이 되어야 함
=> push 이벤트를 모니터링 해야 함
1. github action 에서 저장소의 코드에 접근 가능할 수 있어야 함
2. 빌드, 실행, 도커 이미지 빌드, 푸시 명령 전달할 수 있어야 함
13. name: CI // 워크플로우 이름. 무슨 값이든 상관 없
음
1. github action workflow 생성
14. name: CI // 워크플로우 이름. 무슨 값이든 상관 없
음
on: [push] // 모니터링 할 이벤트
2. push 이벤트 모니터링
15. name: CI // 워크플로우 이름. 무슨 값이든 상관 없
음
on: [push] // 모니터링 할 이벤트
jobs:
ci: // 워크플로우 안에서 실행되는 작업의 이름
runs-on: ubuntu-latest // 작업 환경 - 우분투
3. workflow 설정
16. name: CI // 워크플로우 이름. 무슨 값이든 상관 없
음
on: [push] // 모니터링 할 이벤트
jobs:
ci: // 워크플로우 안에서 실행되는 작업의 이름
runs-on: ubuntu-latest // 작업 환경 - 우분투
steps:
- uses: actions/checkout@v2 // 저장소에 접근할 수 있는 권한 부여
- name: Build // 세부 작업(1) "빌드" 생성
- name: Test // 세부 작업(2) "테스트" 생성
- name: Docker build // 세부 작업(3) "도커 이미지 빌드" 생성
3. 작업 세분화
17. name: CI // 워크플로우 이름. 무슨 값이든 상관 없
음
on: [push] // 모니터링 할 이벤트
jobs:
ci: // 워크플로우 안에서 실행되는 작업의 이름
runs-on: ubuntu-latest // 작업 환경 - 우분투
steps:
- uses: actions/checkout@v2 // 저장소에 접근할 수 있는 권한 부여
- name: Build // 세부 작업(1) "빌드" 생성
run: g++ main.cpp -o main
- name: Test // 세부 작업(2) "테스트" 생성
run: ./main
- name: Docker build // 세부 작업(3) "도커 이미지 빌드" 생성
run: docker build --tag too-simple-hol .
- name: Docker push // 세부 작업(4) "도커 이미지 푸시" 생성
run: |
docker build --tag too-simple-hol .
4. 실제 명령어 추가