본 내용은 회사 업무상 CICD에 대한 학습을 진행하며 조사한 내용에 대한 정리를 위한 블로깅이다.
시나리오
- JAVA / Spring 을 활용해서 코드 작성
- Git의 dev 브렌치에 있는 코드들만 지정된 서버에 Build
- 배포 서버는 리눅스
- 개발자는 코드를 구현
- 구현한 코드가 정상 작동하는지 테스트 진행
- 이상이 없을 경우 Git 에 코드 전달 (PUSH)
- Git 에서 특정 브렌치 이동
- Local에서 프로젝트 Build
- scp 명령어를 활용해 배포 서버에 jar 파일 전달
- 기존에 실행하고 있던 파일 종료 후 재 배포
문제
- 개발자가 테스트 코드를 실행하도록 강제할 수 없다.
- 간단한 변경이 있을 때도 항상 위의 과정을 수행해야된다. → 불필요한 리소스 낭비(귀찮음)
원하는 것
개발자들은 단순하게 개발만 진행하고, 서버에 배포하는 일련의 과정을 자동화 시키고 싶다. (불필요한 반복 작업의 축소를 통해 리소스 낭비를 막는다.)
CICD란
CICD는 Continuous Integration (CI)와 Continuous Deployment (CD)의 약자로, SW 개발에서 코드 변경을 자동으로 빌드하고 배포하는 과정 의미
CI (Continuous Integration)
- 개발자들이 코드를 VCS에 통합하는 과정
- 자동화된 테스트가 코드 변경 사항을 확인하여, 통합 후(merge)에도 애플리케이션이 정상적으로 작동 여부 검증
- 코드의 품질을 유지 및 버그를 조기에 발견하여 수정 가능
CD (Continuous Deployment or Continuous Delivery)
- CI 후, 코드가 자동으로 프로덕션 환경에 배포되는 과정 의미
- 새로운 기능이나 수정된 내용을 Client에게 신속하게 전달 가능
- 좋은 사용자 경험
- Continuous Delivery
- 배포 프로세스를 자동화하지만, 실제 배포는 수동으로 할 수 있는 상태를 유지
- Continuous Deployment
- 모든 변경 사항이 자동으로 배포되는 것을 의미
CICD를 적용 했을 때
DEV 브렌치의 변경을 감지 할 경우
CICD Tool 에서 코드의 Test / Build / Delpoy의 과정을 자동으로 진행
종합 요약
개발자들은 배포의 과정에 리소스를 투자하지 않고 순수하게 개발만 하고싶다. 그렇기 때문에 배포와 관련된 일련의 과정의 자동화를 원해 CICD가 필요하다.