개발 환경의 분할
개발 환경
- Local
- (개발자가 사용하는) 개개인의 컴퓨터
- Docker 등을 활용하여 환경 공유
- Dev
- Local에서 개발한 기능을 테스트할 수 있는 Test 서버
- 모델 등의 제품이 정상적으로 돌아가는지 확인해 보는 서버
- Staging
- Production 환경에 배포하기 전에 보안, 성능 측정 및 운영을 시험해보는 Staging 서버
- 실제로 활용할 수 있는 정도인지 확인해 보는 서버
- Production
- 실제 서비스를 운영하는 운영 서버
- User가 실제로 활용하는 서버
개발 환경을 나누는 이유
-
Production 서버에 최대한 장애가 발생하지 않기 위함
-
여러 단계로 나눠 실험을 함으로써 에러 발생 확률을 줄이기 위함
- 많이 실험해볼수록 에러가 발생할 확률이 높아지고, 따라서 Production 상황에서 에러가 발생할 확률이 줄어듬
CI / CD
CI
-
Continuous Integration(지속적 통합)
-
새롭게 작성한 코드 변경 사항이 Build, Test 된 이후 Test Case에 통과하는지 여부 확인
-
지속적으로 코드 품질 관리
-
개발자 각각의 결과물에 대해 모두 CI 과정이 수행되어야 함
-
빌드 / 테스트 자동화
- 내가 제공하는 제품이 에러를 발생시키지는 않는지 확인
CD
-
Continuous Deploy/Delivery(지속적 배포)
-
작성한 코드가 신뢰 가능한 상태라면 자동으로 배포 될 수 있도록 하는 과정
- 작성한 코드가 신뢰 가능한 상태임을 확인하는 방법 : CI 과정을 거침
-
Dev/Staging/Main Branch에 Merge가 될 경우 코드가 자동으로 (매치된) 서버에 배포하게 만듦
-
배포 자동화
CI / CD에 활용하는 툴
-
Travis CI / AWS CodeDeploy : 이전 웹 개발에서 활용한 툴
- 코드를 Push 하면 Travis CI를 통해 명령어가 수행되고, CI 과정을 거친 이후 Jar 파일이 AWS CodeDeploy에 전달되면 해당 jar 파일이 서버에 배포되는 과정을 거침
- CI : Travis CI 툴이 담당
- CD : AWS CodeDeploy 툴이 담당
-
Jenkins : 최근 많이 활용하는 CI 툴
-
Github Action : 이번에 활용할 CI Tool
- Software Workflow 자동화를 도와주는 도구
Github Action
Workflow 예시
-
Test Code
- 특정 함수의 Return 값 확인 및 Type 확인
- Unit Test, End to End Test 등
-
배포
- Production, Staging, Dev 서버 등 매치된 서버에 코드 배포
- 방법 : FTP로 파일 전송, Docker Image를 Push하는 방법 등
-
Python, Shell Script 실행
- Github Repo에 저장된 스크립트를 일정 주기로 Shell Script를 실행시킴
- Crontabl의 대용으로 활용 가능
- 데이터 수집 및 전처리를 주기적으로 해야 할 경우 활용 가능
- Github Repo에 저장된 스크립트를 일정 주기로 Shell Script를 실행시킴
-
Github Tag, Release 자동 설정
- Main Branch에 Merge 될 경우 특정 작업 실행
- Version Up
- Branch 생성 및 변경에 따른 작업 설정
GitHub Action 제약 조건
-
하나의 Github Repository당 Workflow는 최대 20개까지 등록 가능
-
Workflow에 존재하는 Job은 최대 6시간 실행할 수 있음
- 초과시 자동으로 중지됨
-
동시에 실행할 수 있는 Job 개수 제한 존재
Github Action 사용하는 방식
-
코드 작업
- 제공할 제품(모델)을 만드는 과정
-
Github Action으로 무엇을 할 것인지 생각
- 자동 배포만 하고 싶을 수도 있고(Test Case를 로컬에서 모두 실행해봤으므로 필요 없는 경우), CI / CD까지 모두 수행시키고 싶을 수도 있음
- Crontab의 효과를 보고 싶거나 추가 작업을 원하면 이런 작업을 Github Action에 추가시켜줘야하므로, 미리 고려해야함
-
사용할 Workflow 정의
- 내가 원하는 Workflow를 코딩(설정)
-
Worfklow의 정상 작동 확인
Github Action 개념
Workflow
-
여러 Job으로 구성된 Process
-
특정 Event를 Trigger로써 수행되는 작업 내용물 모두를 저장한 Process
-
Github Action의 최상위 개념
-
YAML 파일로 작성되어 Github Repository의 .github/workflows 폴더에 저장함
-
Event가 발생하였을 때 자동으로 수행하고 싶은 내용을 설정한 파일
Event
- Workflow의 Trigger
- 특정 Branch에 Push가 발생
- 특정 Branch에 Pull Request가 발생함
- 특정 시간대에 반복되는 작업에 대하여, 지정한 시간이 됨(Cron)
Jobs
-
Runner에서 실행되는 Steps의 조합
-
Job이 여러 개 있을 경우 병렬로 실행될 수 있고, 순차적으로 실행될 수도 있음
- 다른 Job에 의존 관계를 가질 수 있음
-
Workflow에서 수행할 내용들만 입력된 공간
-
수행할 내용 1개에 대한 정보를 Step, 이러한 Step을 모두 모은 것을 Job이라고 함
Steps
-
Job에서 실행되는 개별 작업
-
Action을 실행하거나 Shell Command를 실행
-
하나의 Job에서는 데이터를 공유할 수 있음
Action
-
Workflow 중 제일 작은 단위
-
Job을 생성하기 위해 여러 Step을 묶은 개념
-
재사용이 가능한 Component
-
Actoin을 만들 수도 있고, Marketplace에서 미리 구현된 Action을 가져와 활용할 수도 있음
Runner
-
Workflow가 실행될 서버
- Github Action도 결국 서버에서 실행되는 것
-
Github-hosted Runner : Github Action의 서버를 활용하는 방법
-
Self-hosted Runner : 직접 서버를 호스팅해서 활용하는 방법
Github Action 활용해보기
1. Github Repository 준비 및 파일 Upload
2. Actions 클릭 & Continuous Integration 클릭
3. Python Application 파일 Commit
- 제대로 수행된 결과
- .github/workflows 경로에 yaml 파일이 들어오면 성공!
3-2. Github YAML 파일 분석
-
on : Event
- 언제 Workflow가 실행될 것인가
- 위 사진에서는 Main 브랜치에 Push나 Pull Request 요청이 올 경우 Workflow가 수행되도록 설정한 것
- push, Pull Request 등에 paths 활용 가능
- paths : 설정한 경로에 있는 파일이 변경된 경우 CI 실행
- paths-ignore를 설정하면 해당 파일에 존재하는 파일이 변경될 경우에는 CI를 실행하지 않는 것
- Docs : https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-including-paths
-
jobs
- build : job의 이름
- 여러 개의 job들을 모아 놓은 것
-
runs-on
- CI를 실행할 환경
- 위 예시에선 ubuntu 환경에서 실행했음
-
uses : 사용할 Github Action
- 미리 구현되어 있는 Github Action을 활용하는 것
-
name : Step의 이름
- 필수적이진 않음
- 단, 설정하지 않을 경우 어떤 과정을 수행했고, 수행하지 않았는지 확인하기 어려움
-
run : 내가 직접 설정한 Shell Command
- uses 설정이 없을 경우 run에 작성된 Shell Command가 실행됨
4. CI 설정
3-2에서 설명했던 것을 토대로, 내가 CI 과정을 수행하고 싶은 파일(예시에선 hello-world.py 파일)을 수행하려는 코드를 넣어줘야 한다.
그렇다면 어디에 넣어야 할까?
먼저 python hello-world.py를 통해 Python 파일을 수행시켜야 할 것이다.
이 명령어는 Shell Command이다.
그렇다면...? 그렇다. jobs의 steps 밑에 name, run을 생성해주어 위 Shell Command를 입력해주면 된다.
5. CI 과정 확인
-
Main Branch에 커밋하면 now 왼쪽에 노란색 동그라미가 발생하는데, 동그라미를 클릭하면 위 사진과 같은 창이 발생
-
CI 과정이 수행되고 있음을 알림
6. CI 중간 과정 확인
-
초록색 버튼 : CI가 성공함
- 즉, 에러 없이 Commit한 코드가 수행됨
- 참고로, 실패하면 빨간색 동그라미가 되며 가입한 이메일 주소로 실패를 알리는 메일이 옴
-
CI 과정에서 어떤 name을 가진 Job이 실행되었는지 볼 수 있음
-
내가 위에서 설정했던 "Test hello-world.py"도 아래에서 4번째에 존재함을 볼 수 있음
-
왼쪽 '>'를 클릭하여 해당 과정에서 어떤 작업이 수행되었는지 볼 수도 있음
- 로그 및 출력문 확인 가능
