Docker와 GitHub Actions 를 통해 CI/CD 를 구축해볼 생각이다.
그전에 CI/CD에 대해 알아보자!
CI
CI: 지속적인 통합 (Continuous Integration)
"여러 개발자의 코드를 자주 합치고, 합칠 때마다 자동으로 테스트하여 코드의 품질을 유지하는 것"
CI 방식:
개발자들이 변경한 코드를 하루에도 몇 번씩 중앙 저장소(예: GitHub의 develop 또는 main 브랜치)에 자주 합칩니다.(Push/Merge).
코드가 합쳐질 때마다, CI 서버(예: GitHub Actions)가 이 변경을 자동으로 감지하고 다음과 같은 일을 수행합니다.
1. 빌드(Build): 코드가 문법적으로 오류 없이 잘 합쳐지는지 확인합니다. (컴파일)
2. 테스트(Test): 미리 작성해 둔 자동화된 테스트 코드를 실행하여, 새로운 코드가 기존의 기능을 망가뜨리지 않았는지 검증합니다.
3. 피드백(Feedback): 만약 빌드나 테스트에 실패하면, 즉시 모든 개발자에게 "방금 합친 코드에 문제가 생겼어!"라고 알려줍니다.
우리가 협업 개발할때 보통 깃허브로 머지를 자주 해서 개발했다. 즉 그걸 포함해서 GitHub Actions가 빌드하고 테스트하고 피드백을 주는 게 CI라고 하는 것 같다.
CI 목표
- 코드 품질 유지
- 버그 조기 발견
- 통합에 대한 두려움 사라짐
CD
CD: 지속적인 배포 (Continuous Delivery / Deployment)
"CI를 통과한 코드를 실제 서버에 안정적으로, 자동으로 출시(배포)하는 것"
CD 는 두 가지 종류가 있다고 한다.
| 지속적인 전달 (Continuous Delivery) |
| - CI 단계(빌드, 테스트)를 통과한 코드는 언제든지 배포할 수 있는 상태로 준비됩니다. - Docker 이미지를 만들어서 이미지 저장소(Docker Hub)에 올려두는 것까지가 자동화됩니다. - 하지만 실제 운영 서버에 배포하는 마지막 단계는 사람이 버튼을 클릭하는 등 수동으로 제어합니다. (예: "매주 금요일 오후 4시에 배포하자") |
| 지속적인 배포 (Continuous Deployment) |
| - 가장 높은 수준의 자동화입니다. - CI 단계를 통과한 코드가 아무런 사람의 개입 없이, 자동으로! 즉시! 실제 운영 서버에 배포됩니다. - 개발자가 main 브랜치에 코드를 merge하는 순간, 몇 분 안에 그 기능이 실제 고객들에게 서비스되는 것입니다. |
아래는 바로바로 배포되는 거고. 위에는 수동으로 제어하는 것 같다.
아래 같은 경우에는 위에서 말한 CI 서버에서 버그 검증이 필수 일 것 같다.
CD 목표
- 배포 과정 실수 줄임
- 새로운 기능 및 버그 수정을 빠르게 가능
- 배포 작업을 수월하게 만듦
CI/CD 파이프라인
| 단계 | 개념 |
| 코드 변경 | 개발자가 코드를 수정하고 Push |
| CI (지속적 통합) | GitHub Actions가 코드를 자동으로 빌드하고 테스트 |
| 산출물 생성 | 배포할 수 있는 패키지를 만듦 |
| CD (지속적 배포) | 패키지를 실제 서버에 자동으로 배포 |
정리하면 이렇다고 한다!
댓글