CI/CD

• CI(Continuous Integration) : 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미한다. 지속적인 통합이 제대로 구현되면 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합된다. 따라서 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌하는 문제를 이 방법으로 해결할 수 있다.

• CD(Continuous Deployment) : 지속적인 배포로 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미한다. 이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결한다.

장점

• 자동화 시스템 - 테스트 : 반복적인 부분들을 자동으로 돌려서 생산력 향상. 예를 들어 개발자들이 작성한 코드들의 테스트를 자동화 시킬 수 있음.
• Incremental Change : 어떤 기능을 구현하기 위해 A, B, C라는 작은 기능을 우선적으로 구현해야 한다면 우선 A를 구현하고 test를 거치고 B를 작업하는, 이처럼 점차점차 프로그램을 수정시키는 작업을 하는데, CI/CD가 이런 기능을 가능하게 함.

만약 CI/CD가 없다면 프로그램 에러가 발생하여 이전으로 돌아가려고 할 때 매번 백업한 것을 이용해야 하고 그에 따른 테스트가 매우 번거로워 짐.

Code Commit

• 파일들을 보관하는 저장 장소 (Repository) - Github과 매우 유사
  • ex) 코드, 사진, 라이브러리 등
• 동시에 많은 사람들이 저장 장소 접근 및 업데이트 가능
• 버전 컨트롤 기능 제공
  • ex) 언제 어떻게 누가 저장 장소 내용을 변경하였는지

Code Deploy

Code Deploy는 자동배포라 불린다.

장점

• 새로운 기능들의 빠른 배포
• 소프트웨어 & 서버 다운타임 X
• 사람이 만들어내는 에러를 피할 수 있음

Rolling 배포

  일반적인 배포를 의미하며, 단순하게 서버를 구성하여 배포하는 전략이다. 다시 말해 구버전에서 신버전으로 트래픽을 점진적으로 전환하는 배포 방식이다. 배포를 다 마치면 이전 버전으로 돌아가기 힘들다는 단점이 있다.

원래 V0 버전이었는데 V1으로 점차적으로 바꿈

Blue/Green 배포

  구버전을 Blue, 신버전을 Green이라고 해서 붙여진 이름이다. 신버전을 배포하고 일제히 전환하여 모든 연결을 신버전을 바라보게 하는 전략이다. 구버전, 신버전 서버를 동시에 나란히 구성하여 배포 시점에 트래픽이 일제히 전환된다. 빠른 롤백이 가능하고, 운영환경에 영향을 주지 않고 실제 서비스 환경으로 신버전 테스트가 가능하다. 단 이런 구성은 시스템 자원이 두 배로 필요하여 비용이 더 많이 발생한다.

V0 버전의 트래픽을 줄이고 V1쪽으로 이동해가는 방식

Rolling vs Blue/Green

1. 맨 처음 배포할 때 Rolling 방식을 사용하는 것이 좋다.
-> 딱히 새로운 버전과 비교할 거 없고 상대적으로 빠른 배포가 가능하기 때문

2. 시간이 지나면서 배포가 복잡해질수록 Blue/Green을 사용하는 것이 좋다.
-> down time이 전혀 없고 이전 버전으로 복원이 수월하기 때문

Code Pipeline

• 빌드 테스트 배포 과정을 관리
• 코드 변경 시 Code Pipeline은 이를 감지할 수 있음
• 소프트웨어 및 애플리케이션 출시 자동화 가능
• 빠르고 쉬운 디버깅을 가능하게 해줌

Code Pipeline 작동 방법
Code Pipeline은 아래 단계들을 모두 자동화해준다.

Workflow : 코드 저장소의 특정 코드가 변경되었을 시 시작
staging 배포 : 기능을 테스트하는 단계를 거치게 됨
production 배포 : 출시한다는 뜻