🚀 Start
대부분의 경우, 비즈니스 앱 개발은 매우 힘들고 긴 시간을 요하는 작업이다. 부분적으로는 앱 개발 및 제공 프로세스 때문이다. 앱을 초기 브리핑에서 실행 가능한 전략으로 발전시키는 개념적 사전 디자인 단계에서부터 디자인 및 개발 단계를 거쳐 최종 출시 및 지원 단계에 이르기까지, 앱을 출시하려면 수많은 단계와 작업이 수반되어 소프트웨어를 빌드하고 출시하는 데 오랜 시간이 소요될 수 있다.
😃 이 점을 해결하기 위한 것이 CI/CD의 목표이다.CI/CD는 앱 개발 단계에 자동화를 통합하는 앱 제공 방식이다.
CI/CD는 지속적인 통합/지속적인 제공 또는 배포를 뜻하며, 앱 개발 시간을 줄이고 릴리스 수를 늘리는 것을 목표로 하는 Agile 개발 방식에서 비롯된다. CI/CD는 운영 원칙 및 사례 모음을 포함하는 포괄적인 용어로, DevOps 팀이 코드 변경을 앱에 쉽고 빠르게 구현하도록 지원한다.
⭐️ CI(Continuous Integration)
CI란 개발자를 위한 자동화 프로세스인 지속적인 통합, 즉 빌드/테스트 자동화 과정을 뜻한다.
예를 들어 CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.
지속적 통합의 실행은 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작한다. 커밋할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장한다. 지속적 통합은 그 자체로 유익하지만 CI/CD 파이프라인을 구현하기 위한 첫 번째 단계이기도 하다.
최적의 도구가 뒷받침되는 CI/CD를 제대로 사용할 경우, 소프트웨어 제품을 신속하게 출시하는 동시에 새로운 기능과 수정 사항을 정기적으로 쉽게 구현할 수 있는 믿을 만한 프로세스가 마련된.
✏️ CI Tool
Jenkins를 가장 많이 사용한다. CI와 CD를 모두 구현할 수 있으며 사용할 수 있는 여러 플러그인들이 있어서 CI/CD를 구현하는 것을 편리하게 할 수 있다. 단지 CI 전용 서버를 따로 구축해야 한다는 부담은 있다.
최근에 나온 Github Action에서는 따로 CI서버를 구축할 필요 없이 CI를 구현하게 해주고 있다.
중요) github Action
⭐️ CD(Continuous Delivery)
CD는 배포 자동화 과정이다. CD는 지속적인 서비스 제공 또는 지속적인 배포를 의미하며 이 두 용어는 상호 교환적으로 사용된다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.
지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 DevOps 방식을 논리적 극한까지 끌어 올린다. 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포된다. 지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있다.
지속적 배포는 또한 성숙하고 입증된 지속적 통합 및 지속적인 전달 단계를 기반으로 한다. 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포된. 강력하고 신뢰할 수 있는 자동화 배포 파이프라인을 구축하면 하루에도 여러 번 이루어지는 릴리스가 특별하지 않은 일상이 된다.
💡 간단 정리
✏️ CI는 지속적 통합이라는 의미이다.애플리케이션의 새로운 코드들이 자동으로 빌드 및 테스트 되어 레포지토리에 통합되는 것을 의미한다.
CI의 포인트
- 개발자들은 최대한 작은 단위로 만들어서 개발해가며 빈번하게 merge해야한다.
- 애플리케이션들의 빌드, 테스트, 병합하는 과정을 주기적으로, 자동화시켜야 한다.
이런 포인트를 따라가면 병합시 충돌을 예방할 수 있고, 코드의 결함이나 문제점을 빠르게 발견할 수 있다.
빠르게 해결 가능
Why ? 작은 단위로 빈번하게 merge하기에 문제 발생 범위가 작기 때문이다(빈번하게 merge해도 빌드, 테스트가 자동이라 간편) 결과적으로 코드의 품질이 올라간다.✏️ CD는 지속적 제공/배포라는 의미이다. CI를 통해서 빌드, 테스트가 완료되어 배포될 준비가 끝난 애플리케이션을 개발자가 수동으로, 혹은 자동으로 배포를 진행하는 것.
👍 CI / CD 이점
✏️ 신속한 반복 작업
DevOps 라이프사이클의 일환으로 CI/CD 방식을 채택하면 코드 베이스 관련 변경 사항을 검증하고 배포하는 수동 작업을 자동화함으로써 개발 속도를 높일 수 있다.
✏️ 더욱 깔끔한 코드
하루 종일 수많은 사소한 변경 사항을 확인하면 소스 코드로 유입되어 빌드를 손상시키는 오류가 발생할 위험을 크게 줄일 수 있다.
✏️ 더욱 빠르게 버그 해결
CI/CD를 통해 소규모 체인지 세트를 더 자주 병합하면 코드 오류가 더 큰 문제로 발전하기 전에 손쉽게 이를 식별하고 해결할 수 있다.
✏️ 피드백 루프 단축
CI/CD를 통해 반복적으로 발생하는 사소한 변경 사항을 손쉽게 통합, 테스트, 배포할 수 있어 피드백 루프를 단축할 수 있다.
✏️ 더욱 효율적인 협업
CI/CD는 코드를 커밋하고 빌드를 출시하기 위한 프로세스와 일정을 정립함으로써 작업에 명확성을 더한다. 보다 명확해진 목표를 통해 팀은 향상된 민첩성에 대응할 수 있다.
✏️ 고객 만족도 향상
CI/CD를 통해 빌드가 출시 준비 완료 상태이므로 고객이 서비스 중단을 경험할 가능성이 줄어들 뿐 아니라 고객 피드백이 훨씬 빠르게 통합될 수 있다.
⚙️ CI/CD 파이프라인
-
빌드(Build) - 애플리케이션을 컴파일하는 단계
-
테스트(Test) - 코드를 테스트하는 단계. 이 단계를 자동화하여 시간과 수고를 줄일 수 있다.
-
릴리스(Release) - 애플리케이션을 리포지토리에 제공하는 단계
-
배포(Deploy) - 코드를 프로덕션에 배포하는 단계
-
검증 및 컴플라이언스(Validation & compliance) - 빌드 검증 단계는 해당 조직의 필요에 따라 결정된다. Clair와 같은 이미지 보안 스캔 툴을 사용하여 알려진 취약점(CVE)과 비교하는 방법으로 이미지의 품질을 보장할 수 있다.
👉 CI / CD 적용 전 과정
-
개발자들이 개발하여 코드를 수정
-
각자의 feature 브랜치에 코드를 push (but, 어느 한 부분에서 에러가 났지만 개발자들은 눈치채지 못한다.)
-
각자의 코드를 git에 올리고 통합(Intergration).
-
에러가 발생했지만 어느 부분에서 에러가 났는지 모르므로 다시 어디부분에 에러가 있는지 디버깅하고 코드를 수정.
-
(1) ~ (4)의 과정을 반복합니다.
-
많은 시간을 할애하여 에러가 해결되었으면 배포를 시작. 하지만 배포과정 또한, 개발자가 직접 배포과정을 거치므로 많은 시간을 소요.
👉 CI / CD 적용 후 과정
-
개발자들이 개발하여 feature브랜치에 코드를 push.
-
git push를 통해 Trigger되어 CI서버에서 알아서 Build, Test, Lint를 실행하고 결과를 전송.
-
개발자들은 결과를 전송받고 에러가 난 부분이 있다면 에러부분을 수정하고 코드를 master 브랜치에 merge.
-
master 브랜치에 코드를 merge하고 Build, Test가 정상적으로 수행이 되었다면 CI서버에서 알아서 Deploy 과정을 수행.
참조 및 참고하기 좋은 사이트
