CI/CD

JBoB·2023년 3월 6일
0
post-custom-banner

🐧CI(**지속적 통합(Continuous Integration))이란?**

CI

: 빌드/테스트 자동화 과정이다. CI은 개발자를 위한 자동화 프로세스인 지속적인 통합

CI(****지속적 통합(Continuous Integration))** 을 의미 한다. CI을 성공적으로 구현할 경우

애플리케이션에 대한 새로운 코드 변경사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로

여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수있다.

지속적 통합의 실행은 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작한다. 커밋할 때마다 빌드와 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장한다.

CI의 핵심 목표

버그를 신속하게 찾아 해결하고,

소프트웨어의 품질을 개선하고,

새로운 업데이트의 검증 및 릴리즈의 시간을 단축시키는것에 있다.

🐧CD(**지속적 배포(Continuous Deployment))이란?**

CD

: 배포 자동화 과정이다.CD는 지속적인 서비스 제공(Continuous Delivery)또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용한다.

⇒ CI에서 Build되고 Test 된 후에 배포 단계에서 release 할 준비 단계를 거치고 문제가 없는지 수정할만한 것들이 없는지 개발자가 검증하는 팀이 검증한다.

지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 방식을 논리적 극한까지 끌어 올립니다. 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포됩니다. 지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있습니다.

⇒ ‘사용자들에게 서비스를 제공해도 되겠다!’라고 정해 배포를 수동적으로 진행하는 것

지속적 서비스 제공는 또한 성숙하고 입증된 지속적 통합 및 지속적인 전달 단계를 기반으로 합니다. 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포됩니다. 강력하고 신뢰할 수 있는 자동화 배포 파이프라인을 구축하면 하루에도 여러 번 이루어지는 릴리스가 특별하지 않은 일상이 됩니다.

⇒ 배포할 준비가 되자마자 자동화를 통하여 배포를 진행하는 것

CD를 적용한 후의 흐름
1. CD를 적용하여 코드를 검증한다.
2. 배포 환경과 비슷한 곳에서 김증을 진행한다.
3. 검증된 소프트웨어를 실제 프로덕션 환경으로 배포한다.

CD의 핵심 목표

  • 개발자는 배포보다는 개발에 더욱 신경 쓸 수 있도록 도와준다.
  • 개발자가 원클릭으로 수작업 없이 빌드,테스트, 배포까지의 자동화를 할 수있다.

🐤 CI/ CD 적용 전과 후 차이

CI/CD를 적용하기 전의 고전적인 코드 통합 과정을 생각해봅시다.

1. 개발자들이 개발하여 코드를 수정합니다.

2. 각자의 feature 브랜치에 코드를 push합니다. (but, 어느 한 부분에서 에러가 났지만 개발자들은 눈치채지 못합니다.)

3. 각자의 코드를 git에 올리고 통합(Intergration)합니다.

4. 에러가 발생했지만 어느 부분에서 에러가 났는지 모르므로 다시 어디부분에 에러가 있는지 디버깅하고 코드를 수정합니다.

5. (1) ~ (4)의 과정을 반복합니다.

6. 많은 시간을 할애하여 에러가 해결되었으면 배포를 시작합니다. 하지만 배포과정 또한, 개발자가 직접 배포과정을 거치므로 많은 시간을 소요합니다.

코드의 양이 적다면 조금만 시간을 할애해도 에러를 찾아낼 수 있지만, 코드의 양이 많다면 에러 추적이 안되므로 어마어마한 양의 디버깅 과정을 마주하게 될 수도 있습니다.

CI/CD를 적용 후의 과정

(이 과정은 하나의 예시일 뿐 다르게 변경할 수 있습니다. 예를 들면 중간에 PR과정을 추가할 수 있고, sonarqube나 lint를 돌린다던지, git tag를 통해 Deploy를 Trigger 시킬 수 있습니다.)

1. 개발자들이 개발하여 feature브랜치에 코드를 push합니다.

2. git push를 통해 Trigger되어 CI서버에서 알아서 Build, Test, Lint를 실행하고 결과를 전송합니다.

3. 개발자들은 결과를 전송받고 에러가 난 부분이 있다면 에러부분을 수정하고 코드를 master 브랜치에 merge합니다.

4. master 브랜치에 코드를 merge하고 Build, Test가 정상적으로 수행이 되었다면 CI서버에서 알아서 Deploy 과정을 수행합니다.

참고:https://seosh817.tistory.com/104

profile
간절하고 치열하게 살자
post-custom-banner

0개의 댓글