개발 환경
실제 운영중인 서비스에 장애가 발생하면 안되기 때문에 개발 환경을 나누어야함
local | Dev | Staging | Production |
---|
각자의 컴퓨터에서 개발 | local에서 개발한 기능을 테스트하는 서버 | 실제 배포하기 전에 보안,성능 측정 | 서비스 운영 환경 |
git flow로 보면,
- main → staging → dev → feature/기능 이름
(main에서 staging 브랜치 분기, staging 브랜치에서 dev 브랜치 분기, dev 브랜치에서 feature 브랜치 분기)
- 기능을 만들고 나면,
feature/기능 이름 PR,Review dev PR,Review staging PR,Review main
Q. 서버에는 어떻게 코드를 보낼까? & 반복적으로 진행할 test는 어떻게 실행할까?
A) dev 브랜치에 merge 되면, local에서 git pull & test를 수행 → 괜찮으면 배포 (FTP로 파일 전송); 번거로움
∴ 자동화를 해보자! → CI/CD
CI/CD
https://www.synopsys.com/glossary/what-is-cicd.html
CI | CD |
---|
지속적 통합 | 지속적 배포 |
빌드⋅테스트 자동화 | 배포 자동화 |
코드 품질 관리 | CI 통과 이후 자동으로 배포 수행 |
새로 작성한 코드 변경사항에 대해 build, test를 진행하여 test case를 통과했는지 확인 | 코드가 dev/staging/main 브랜치에 merge 되는 경우, 코드를 자동으로 서버에 배포 |
- CI/CD 솔루션: Jenkins, circleci, Travis CI, AWS CodeDepoly, Github Action, GCP Cloud Build
생각해볼 점
- CI/CD를 적용하였을 때는 어떤 이슈들이 있을까?
- 보안 이슈
- CI 프로세스가 너무 복잡하면 작업의 효율성이 낮아질 수 있음
- 시스템 확장성 이슈
- ML 관련 서비스를 deploy할 때 CI/CD 측면에서 특별히 더 생각해보아야할 부분이 있을까?
- ML 관련 서비스에서 CI는 코드 및 구성요소+데이터, 데이터 스키마, 모델도 테스트+검증
참고문헌