소프트웨어 빌드
- 우리가 개발한 소프트웨어를 최종적으로 출시하기 위한 형태로 만드는 것
- 테스트가 빌드의 중요한 일부로 포함
- 테스트를 다 통과해야 패키지 포맷으로 만듦
- 테스트가 충분히 있어야 함
- 참여 개발자들이 많을수록 더 중요
- 개발이 끝나기 전부터 빌드를 하면 소프트웨어의 안정성 증대 -> Continuous Integration
개발자가 코드를 고칠 때 마다 테스트를 돌림 -> 테스트가 많아야 함 -> 작은 회사에서는 어려움
Continuous Integration (CI)
- 기본 원칙
- 코드 Repo는 하나만 유지 (master/main)
- 코드 변경은 최대한 자주 반영
- 테스트를 최대한 추가
- Test Coverage
- 빌드를 계속적으로 수행 (자동화)
- Commit Build vs. Nightly Build
- 성공한 빌드의 프로덕션 릴리스 (자동화)
- CD: Continuous Delivery
빌드 실패하면?!
- 새 코드의 커밋으로 인해 테스트가 실패하는 경우
- 많은 회사들이 빌드 실패 시 빌드가 다시 성공할 때 까지 코드 변경 금지
- 어느 정도 조직이 커지면 빌드만 전담하는 엔지니어가 생김
- 빌드 실패시 가벼운 형태로 패널티 부여
- 개발자가 code commit
- 다양한 종류의 테스트 수행
- 소프트웨어 배포를 위한 패키지로 만듦 -> 주로 docker image가 쓰임!
- 새로운 소프트웨어 배포 -> production server 환경은 주로 k8s이 쓰임
-> 이를 코드 변경이 생길 때 마다 계속 진행
Github Actions
- CI/CD를 Github 위에서 구현하기 위한 서비스
- 코드 테스트, 빌드, 배포 자동화 기능 제공
- workflow라 부르며 아래 컴포넌트로 구성
- Events
- Jobs: workflow가 jobs에 기술됨
- Actions
- Runner
- github hosted runners
- self hosted runners
flake8
- 파이썬 코드에서 에러나 코딩 스타일 등에서 이슈를 체크해주는 툴
- 이런 툴을 Linting tool이라 부름 (언어별로 존재)
반응형
