소프트웨어 공학
CI/CD 업무 자동화
nooblette
2021. 10. 1. 12:13
개발 -> 빌드 -> 테스트 -> 배포
개발 부터 배포까지는 보통 위의 과정을 거치게된다.
하지만 만약 위 과정을 모두 수작업으로 처리한다면 여러가지 불편한 점이 있을 것이다.
코드 작업부터 배포까지 과정에서 중간중간에 일일히 오류를 수정하고 다시 빌드하고 테스트하는 것은 큰 시간과 체력소모를 하게된다. 큰 규모의 프로젝트일수록 이러한 작업은 피로도를 높일 것이다.
기존 과정의 문제점
1. 수동화 된 작업 : 빌드 오류, 배포가 잘 진행되고 있는지, 신규 버전에서 오류가 발생하는지 등 상황을 확인하면서 이후 작업을 수작업으로 진행하면, 모두가 피곤할 것이다.
2. 작업의 누락 : 장애가 발생하지 않으면 누락 사실을 인지하기 어려운 작업을 놓칠 가능성이 존재한다.
3. 기능 추가 및 변경의 부담 : 기존 작업에서 새로은 기능을 추가하거나 실무라면 담당자가 변경된다면 이는 큰 불편을 초래할 것이다.
CI/CD 자동화
개발 - 빌드 -테스트 - 배포까지의 전 과정의 자동화를 통해 이러한 문제를 해결할 수 있다.
이러한 구축 사례를 CI/CD 파이프라인이라고 부르고, 애자일(Agile) 방식의 협력을 도와준다.
CI(Continuous Integration) : 지속적 통합
- 지속적으로 코드에 대한 통합을 진행.
- 개발의 편의성 증가.
- 빌드 및 테스트를 거쳐 공유 리포지토리에 병합.
- 기존 코드와 신규 코드의 충돌이 발생하면 빠르게 수정할 수 있다.
- 중간에 누군가 합류를 해도 빌드가 되는 코드를 받을 수 있다.
- 항상 좋은 퀄리티의 코드를 유지할 수 있다
- 지속적으로 테스트를하고 통과한 코드만 공유 리포지토리에 올라갈수 있기 때문
- 흐름
- 자신이 개발한 코드를 형상관리 시스템(e.g. Github, Gitlab)에 저장한다
- 코드에 변경이 생기면 해당 시스템은 CI/CD 툴(e.g. Jenkins)에 통보한다
- CI/CD 툴(e.g. Jenkins)은 변경된 코드를 Build, Test, Merge하고 모두 통과하면 통합 결과를 알린다
CD(Continuous Delivery / Continuous Deployment) : 지속적 제공 또는 배포
- 지속적인 제공
- CI를 통해 빌드와 테스트를 진행하면, 이를 통과한 코드에 대해 테스트서버와 운영서버에 자동으로 릴리즈
- 항상 배포할 준비가 되어있는 퀄리티의 소스코드를 자동으로 올려준다
- 지속적인 배포
- CI/CD 파이프라인의 최종 단계
- 지속적인 제공을 거쳐 배포가능한 코드를 프로덕션 레벨로 릴리즈하는것을 의미한다
- 개발~배포까지의 과정이 간소화 되기 때문에 피드백을 빠르게 반영할 수 있다.
- 장애 대응이 빨라진다
- 원 클릭으로 개발 -> 빌드 -> 테스트 -> 배포를 수행할수있다(자동화)
- 변경 사항을 작은 조각으로 세분화하여 더 쉽게 릴리즈를 할 수 있다.
- 흐름
- CI를 통해 코드를 검증
- 배포환경과 유사한 곳(Docker)에서 실행시킨다
- 검증 후 통과하면 실제 프로덕션 환경으로 배포한다
Jenkins
주로 사용되는 CI/CD 툴
-장점
- 무료
- reference, 사용자가 많음
- 다양한 플러그인 제공
- 파이프라인 구성의 높은 자유도
- 단점
- 직접 설치해서 서버를 운용해야함
- 프로젝트 별 보안 및 권한 설정이 불편
- 흐름
Jenkins와 같은 지속적 통합 서비스를 제공하는 툴로 CI/CD를 자동화하여 진행 할 수 있다.
- Github에 소스코드를 commit하면, GIthub이 이를 Jenkins에 통보함
- Jenkins에서 빌드 테스트를 진행, 검증된 소스코드로 Docker 이미지를 생성
- Jenkins 내부 설정된 스크립트로 만들어진 이 Docker 이미지를 Docker hub로 Push
- Jenkins에서 프로덕션 서버로 스크립트 실행 명령을 보냄
- 운용 서버는 Docker hub에서 해당 이미지를 다운로드 받은 후 배포
출처