[90DaysOfDevOps] Day 70 - CI/CD

Main Reference

• https://github.com/MichaelCade/90DaysOfDevOps/blob/main/2022/ko/Days/day70.md

90DaysOfDevOps/2022/ko/Days/day70.md at main · MichaelCade/90DaysOfDevOps

출처 없는 사진 출처는 모두 ↑

 

Day 70

< CI/CD 파이프라인 >

 

CI/CD(지속적 통합/지속적 배포) 파이프라인 구현 = DevOps 환경의 중추

파이프라인 = 애플리케이션의 빌드, 테스트 및 배포를 자동화 -> 개발과 운영 간의 격차를 해소

 

 

소프트웨어 개발 수명 주기(SDLC)

• 이 주기는 영원히 반복되는 주기이기 때문에 일반적으로 무한 루프 내에 단계가 기록됨
• 개발자가 코드를 작성하면 
  1. 빌드되거나 모두 컴파일되고,
  2. 버그가 있는지 테스트되고,
  3. 최종 사용자나 고객이 사용하는 프로덕션에 배포되고(운영), 
  4. 모니터링 및 피드백을 수집하고,
  5. 마지막으로 해당 피드백을 중심으로 개선 사항을 계획하고 반복하는 것이 이 주기의 단계

 

출처. :&nbsp;https://www.hanl.tech/blog/ci-cd-%EA%B8%B0%EB%B3%B8%EA%B0%9C%EB%85%90%EA%B3%BC-%EA%B0%80%EC%9E%A5-%EB%A7%8E%EC%9D%B4-%EC%93%B0%EC%9D%B4%EB%8A%94-%EB%8F%84%EA%B5%AC-5%EA%B0%80%EC%A7%80/

 

 

🛠CI/CD의 중요성과 사용 이유는? 

• 소프트웨어를 빠르고 효율적으로 배포
• 애플리케이션을 최대한 빠르게 시장에 출시하기 위한 효과적인 프로세스를 촉진
• 버전 릴리스를 위해 몇 달 또는 몇 년을 기다릴 필요 없이 버그 수정 및 새로운 기능을 지속적으로 제공
• 개발자가 영향력 있는 작은 변경을 정기적으로 수행할 수 있으므로, 더 빠른 수정과 더 많은 기능을 더 빨리 얻을 수 있음

• 수동으로 수행해야 하는 작업을 자동화하여 작은 문제가 메인 코드 베이스에 들어가기 전에 발견할 수 있음
• 고객에게 잘못된 코드를 push하면 큰 문제가 발생할 수 있잖니
• 메인 코드 리포지토리는 시간이 지남에 따라 지속적으로 구축되기 때문에, 첫날에 수행한 지름길 수정이 몇 년 후 기하급수적으로 더 많은 비용이 드는 수정이 될 수 있다는 생각인 기술 부채를 방지하는 데 도움이 됩니다.

 

 

🔨CI에 대해...

 

CI : 지속적인 통합

= 점진적인 코드 변경을 더 자주/더 안정적으로 수행하는 현대적인 SW 개발 관행

= 개발자가 하루에 여러 번 공유 리포지토리에 코드를 통합해야 하는 개발 관행

= 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 레포지토리에 통합하는 것

= "빌드와 테스트 자동화"

• CI에 의해 트리거되는 자동화된 빌드 및 테스트 Workflow Step은 리포지토리에 병합되는 코드 변경 사항을 신뢰할 수 있도록 보장함
• 해당 코드/애플리케이션은 지속적 배포 프로세스의 일부로 신속하고 원활하게 제공됨

 

 

Git에 코드 Build하는 단계: 

• 자동화된 빌드를 통해 코드가 검증됨 -> 팀/프로젝트 소유자가 문제 조기 발견 가능

 

Test 단계 : 코드를 분석하고 일련의 자동화된 테스트를 수행함

 

예시)

• 단위 테스트 = 소스 코드의 개별 단위를 테스트
• 유효성 검사 테스트 = 소프트웨어가 의도된 용도를 충족하거나 적합한지 확인
• 형식 테스트 = 구문 및 기타 형식 지정 오류를 확인

이러한 테스트는 workflow로 생성된 다음 마스터 브랜치로 push할 때마다 실행되므로,

거의 모든 주요 개발팀에는 일종의 CI/CD workflow가 있으며,

개발팀에서는 하루 종일 전 세계의 여러 팀에서 다양한 프로젝트를 진행하는 개발자로부터 새로운 코드가 들어올 수 있으므로,

코드가 승인되기 전에 모든 사람이 같은 페이지에 있는지 확인하는 테스트의 자동화된 workflow를 구축하는 것이 더 효율적입니다.

 

테스트 완료&성공 -> 컴파일하여 리포지토리로 보내기(예: DockerHub)

• 이 프로세스는 소프트웨어 개발 프로세스와 매우 유사하며, 애플리케이션을 만들고, 버그를 추가하고, 수정한 다음 소스 제어를 업데이트하고, 테스트하면서 버전도 관리힘

 

 

🔧CD에 대해...

 

 

CD = Continuous Delivery or  Continuous Depolyment 
해석하자면, 지속적인 서비스 제공 혹은 지속적인 배포

 

Continuous Delivery는 공유 레포지토리로 자동으로 Release 하는 것,
Continuous Deployment는 Production 레벨까지 자동으로 deploy 하는 것을 의미

정리하자면, CI가 새로운 소스코드의 빌드, 테스트, 병합까지를 의미하였는데,
CD는 개발자의 변경 사항이 레포지토리를 넘어, 고객의 프로덕션(Production) 환경까지 릴리즈 되는 것을 의미

 

CI에서 예로 든 MSA와 같은 환경에서 Agile 방법론이 적용될 경우,
서비스의 사용자는 최대한 빠른 시간 내에 최신 버전의 Production을 제공받을 필요가 있습니다.

이때, 소프트웨어가 언제든지 신뢰 가능한 수준의 버전을 유지할 수 있도록 support 하는 것이 CD라고 할 수 있죠.

이는 서비스의 개발팀과 비즈니스팀(영업, CS팀 등) 간의 커뮤니케이션 부족 문제를 해결해 줌으로써,
배포에 이르기까지의 노력을 최소한으로 단축시켜 준다~

 

 

 

이제 코드를 환경에 배포할 차례, 프로덕션 환경뿐만 아니라 스테이징과 같은 다른 환경도 포함될 것

 

• 소프트웨어 배포 1일차에서 다음 단계는 올바른 코드 베이스를 올바른 환경으로 가져오고 있는지 확인
• 소프트웨어 리포지토리(DockerHub)에서 요소를 가져올 수도 있지만, 다른 코드 리포지토리에서 추가 구성, 예를 들어 애플리케이션에 대한 구성을 가져올 수도 있습니다.
• DockerHub에서 소프트웨어의 최신 릴리스를 가져온 다음 이를 환경에 릴리스하는 동시에 Git 리포지토리에서 구성을 가져올 수 있습니다.
• CD 도구가 이 작업을 수행하여 모든 것을 환경에 push합니다. 이 작업은 동시에 수행되지 않을 가능성이 높습니다.
  • 즉, 구성이 올바른지 확인하기 위해 스테이징 환경으로 이동하여 이 구성에 대해 실행한 후 테스트를 위한 수동 단계일 수도 있고,이 코드를 프로덕션에 배포하기 전에 다시 자동화할 수도 있습니다.
• 그런 다음 애플리케이션의 v2가 나오면 이번에는 단계를 반복하여 애플리케이션 + 구성이 스테이징에 배포되어 모든 것이 정상인지 확인한 다음 프로덕션에 배포합니다.

---

 

; 참고

1. https://artist-developer.tistory.com/24