🌟개발 프로세스 - 개발환경

✅ Local

• 각자 컴퓨터에서 개발을 함
• 각자의 환경을 통일해줘야 하니까 Docker 등을 사용함 !

✅ Dev - [dev] Branch

• Local에서 개발한 기능 테스트하는 환경
• Test 서버

✅ Staging - [staging] Branch

• Production 환경에 배포하기 전에 운영, 보안, 성능 측정하는 환경
• Staging 서버

✅ Production - [main] Branch

• 실제 서비스를 운영하는 환경
• 운영 서버

🌟 Why? 개발환경을 나누나?

실제 운영 중인 서비스에 에러가 발생하면 안되기 때문에 !

• 예를 들어, 테스트하는 환경과 서비스가 돌아가는 환경이 동일하다면, 테스트 과정에서 에러는 서비스의 에러로 직결되기 때문에 개발 환경은 나눠줘야 함 !!

🌟 How? Git Flow 참고

[ main ] ← [ staging ] ← [ dev ] ← [ feature/기능 이름 ]

• Dev Branch에 Merge되면 => Local에서 Git Pull & Test 실행 후 괜찮으면 코드 배포(FTP로 파일 전송) 형태로 진행

✨ Continuous Integration(CI)

• 지속적 통합 ! (빌드, 테스트 자동화)

• 새롭게 작성한 코드 변경 사항이 Build, Test 진행 후에 Test Case에 통과했는지 확인하며 지속적으로 코드 품질을 관리하는 것

• 10명의 개발자가 코드를 수정했다면 모두 CI 프로세스 진행

✨ Continuous Deploy/Delivery(CD)

• 지속적 배포 ! (배포 자동화)

• 작성 코드가 항상 신뢰 가능 상태가 되면 자동으로 배포될 수 있도록 하는 과정임 !! 당연히 CI → CD 순서

• main / staging / dev 브랜치에 Merge가 될 경우 코드가 자동으로 서버에 배포함

🎇 Github Action

• Github에서 출시한 기능으로, 소프트웨어 Workflow 자동화 돕는 도구

👩‍💻 Workflow

1. Test Code

• 특정 함수의 Return 값 어떻게 나오는지 확인 및 특정 변수의 Type 확인
• Unit Test, End to End Test

2. 배포

• Prod, Staging, Dev 서버에 코드 배포 / FTP로 파일 전송 or Docker Image를 Push
• Node.js 등 다양한 언어 배포 지원

3. 파이썬, 쉘 스크립트 실행

• Github Repo에 저장된 스크립트를 일정 주기에 따라 실행시켜 줌
• crontab 대용이며, 데이터 수집을 주기적으로 해야할 경우 활용 가능

4. Github Tag, Release 자동으로 설정

• Main 브랜치에 Merge 될 경우 특정 작업 실행시켜주며, 기존 버전에서 버전 Up하기
• 새로운 브랜치 생성 시 특정 작업 실행도 가능함 !

🤝 Github Action 제약 조건

• 하나의 Github Repository 당 Workflow는 최대 20개까지 등록할 수 있음
• Workflow에 존재하는 Job(실행)은 최대 6시간 실행할 수 있으며, 초과시 자동으로 중지됨
• 동시에 실행할 수 있는 Job 제한 존재

🤝 Github Action 사용 방식

1) 코드 작업
2) 코드 작업 후, Github Action으로 무엇을 할 것인지 생각
3) 사용할 Workflow 정의
4) Workflow 정의 후 정상 작동하는지 확인

👩‍💻 Github Action Core 핵심 !!

핵심 개념 : Workflow, Event, Job, Step, Action, Runner

1. Workflow

• 여러 Job으로 구성되고 Event로 Trigger(실행)되는 자동화된 Process
• 최상위 개념
• Workflow 파일은 YAML으로 작성되고, Github Repository의 .github/workflows 폴더에 저장

2. Event

on: [push]

• Workflow를 Trigger하는 특정 활동, 규칙
• 특정 Branch로 Push, Pull Request하는 경우
• 특정 시간대에 반복(Cron)

3. Jobs

• Runner에서 실행되는 Steps의 조합
• 여러 Job이 있는 경우 병렬로 실행하며, 순차적으로 실행할 수도 있음
• 다른 Job에 의존 관계를 가질 수 있음

4. Steps

• Step은 Job에서 실행되는 개별 작업
• Action을 실행하거나 쉘 커맨드 실행
• 하나의 Job에선 데이터를 공유할 수 있음

5. Actions

• Workflow의 제일 작은 단위
• Job을 생성하기 위해 여러 Step을 묶은 개념
• 재사용이 가능한 Component
• 개인적으로 Action을 만들 수도 있고, Marketplace의 Action을 사용할 수도 있음

6. Runner

• Github Action도 일종의 서버에서 실행되는 개념
• Workflow가 실행될 서버
• Github-hosted Runner : Github Action의 서버를 사용하는 방법 (성능 : vCPU2, Memory 7GB, Storage 14GB)
• Self-hosted Runner : 직접 서버를 호스팅해서 사용하는 방법

Compute Engine에 Docker 이미지 배포하기 - Github Action

작업 흐름

1) Feature/xxx Branch에서 작업
2) Main Branch로 Pull Request
3) Review 후 Merge

CI/CD

4) Merge된 파일에서 Docker Image Build

docker build . -t "steamrec"

5) Docker Image Push
6) Compute Engine에 Docker Image 업데이트 요청