💻 CI/CD 개념 정리 - 지속적 통합(Continuous Integration) / 지속적 배포(Continuous Deployment)

---

CI/CD 5분 개념 정리 (현업에서 쓰는 개발 프로세스)

---

✅ 해당 영상을 보고 정리하여 작성한 내용입니다.

요즘같이 빠르게 진화하고 변화하는 시대에 어떻게 하면 시장과 고객의 요구에 빠르게 반응해서 제품을 출시, 업데이트할 것인가가 큰 과제로 떠오르고 있다.

바로 위와 같은 문제를 위해서 세계적으로 많은 기업들이 CI/CD를 개발 프로세스로 사용하고 있다.

---

🔍 CI/CD

간단하게 말해서 어플리케이션 개발 단계부터 배포때까지 이 모든 단계들을 자동화를 통해서 조금 더 효율적이고 빠르게 사용자에게 빈번히 배포할 수 있도록 만드는 것을 말해요.

---

💡 CI | 지속적 통합, Continuous Integration

버그 수정이나 새로 만드는 기능들이 main repository에 주기적으로 빌드 되고 테스트 되어 Merge 되는 것을 뜻한다.

1991년 그래디 부치(Grady Booch)에 의해 처음 사용되다가 나중에는 익스트림 프로그래밍(extreme programming) 개발 방법론에서 채택된다.

그래디 부치(Grady Booch) 🤔
그래디 부치는 미국의 소프트웨어 개발자이다. 래셔널 소프트웨어의 수석 과학자이다. 이바 야콥슨, 제임스 럼바와 함께 UML을 개발한 것으로 유명하다.

익스트림 프로그래밍(extreme programming) 🤔
익스트림 프로그래밍은 켄트 백 등이 제안한 소프트웨어 개발 방법으로, 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다.

---

📍 CI 포인트

01. 개발자들은 그들의 코드 변경 사항을 main repository에 주기적으로 빈번하게 Merge해야 한다.

동일한 소스 파일 위에서 두 명의 개발자가 서로 다른 코드를 작성하고 있다가 오랜 기간 동안 서로 변경을 하다가 나중에 Merge를 하려고하면 서로 다른 코드를 어떻게 통합해서 적용해 나갈건지 고생을 많이 하게 된다.

이렇게 되면 새로운 기능을 개발하기 위해서 코드를 작성하는 시간보다 이 Merge충돌을 해결하기 위해서 더 많은 시간을 사용해야 할지도 모른다.

그렇기 때문에 버그를 수정하거나 또는 새로운 기능을 구현할 때는 더더욱 이 기능을 어떻게 작은 단위로 나뉘어서 내가 main repository에 반영하거나 또는, 작은 단위로 나누어서 내가 사용자에게 배포할 수 있을지, 최대한 작은 단위로 나누어서 개발하고 통합해나가는 것이 중요하다.

02. 통합을 위한 단계 (Build, Test, Merge)

주기적으로 Merge된 이 코드의 변경 사항이 자동으로 빌드 되어서 코드 변경 사항 이후에도 빌드가 성공적으로 되는지 확인이 되어야한다.

새로 추가된 코드의 변경사항뿐만 아니라 기존의 시스템에 다른 버그를 초래하지는 않았는지 자동으로 테스트까지 되어야한다.

ex) 보통 개발팀에서 진행하는 예시

• Main Repository가 있고 개발자들은 하루에도 몇 번씩 주기적으로 코드의 변경사항을 main repository에 Merge를 한다.(그전에 코드 리뷰를 통해 코드가 적절한지 확인 과정 필요)

• 이렇게 Merge가 되었으면 자동으로 팀에서 만든 CI 스크립트를 통해서 추가된 코드와 함께 이 repository가 빌드화가 되고, 빌드가 잘 된다면 팀에서 작성한 유닛 테스트 등 여러 가지 테스트들도 스크립트를 통해서 실행

• 빌드도 잘 되고 테스트 잘 되어서 초록색 사인(Green)이 나오면 무사히 통과가 되어서 나중에 배포할 때 반영이 될 수 있다.

• 새로 추가한 코드에 문제가 있어서 빌드에 실패하거나 또는 빌드는 성공했는데 테스트에서 실패한다면 레드 사인(Red)이 뜨면서 문제를 일으킨 개발자에게 자동으로 알려준다.

---

👍🏻 CI 원칙을 따라갈 경우 장점

• 주기적으로 Merge를 하기 때문에 Merge충돌을 피할 수 있어서 개발 생산성 향상
• Merge되는 모든 코드들은 자동으로 빌드 되고 테스트 되기 때문에 코드의 결함이나 문제점을 빠르게 발견
• 주기적으로 Merge를 하기 위해서 코드의 변경사항이 작고 문제를 수정할 때도 조금 더 고립된 작은 단위의 문제를 확인할 수 있어 발생되는 결함은 빠르게 수정 가능
• CI를 잘 운영하기 위해서는 모든 개발자들이 자신이 새로 작성하는 코드에 한 해서는 유닛 테스트를 꼭 포함해야하기 때문에 조금 더 나은 코드의 퀄리티 향상 및 안전성 있는 제품 개발 가능

---

💡 CD | 지속적 배포(제공) , Continuous Deployment(Delivery)

마지막 배포 단계에서 어떻게하면 자동화해서 이 배포를 만들 수 있을 지를 고민하는 단계

Continuous Delivery

• CI를 통해서 주기적으로 Merge된 코드의 변경사항들이 자동으로 빌드가 되고 테스트가 되었다면,

• 이제 배포 하는 단계에서, Release 할 준비 과정을 거치고, 준비된 Release가 괜찮은지 정상적인지 아무런 문제가 없는지 직접 개발자나 또는 검증팀이 검증을 한 다음에 "이제 최종적으로 사용자에게 배포해도 되겠다!" 라고 결정이 되면

• 수동적으로 배포하는 단계를 Continuous Delivery 라고 한다.

Continuous Deployment

• Release가 준비가 되자마자 자동으로 사용자에게 배포할 수 있도록 만들 수도 있다.

• 이렇게 모든 과정을 자동화 해놓는 것을 Continuous Deployment 라고 부른다.

Continuous Delivery 와 Continuous Deployment는 살짝 비슷하지만 최종 단계가 자동화가 되었는지 되지 않았는지에 따라서 달라질 수 있다.

이런 모든 과정을 어떻게 자동화를 해두냐, 어떻게 스크립트를 쓰느냐, 그리고 이 자동화와 테스트를 얼마나 자신감이 있느냐에 따라서 어떤 회사들은 최종 단계를 수동적으로 릴리즈 하는 경우가 있다. 어떤 회사는 Continuous Deployment를 사용하는 경우도 있어요.

회사마다 어느 정도의, 얼마만큼의 자동화를 하냐가 달라지기 때문에 CI/CD 라 해서 모든 회사가 똑같은 프로세스를 거치는 것은 아니다. 회사마다 팀마다 다른 방식으로 적용해서 사용할 수 있다.

⏳ CI/CD 파이프라인 정리

CI와 CD는 완벽히 분리된 것이 아니라 대부분의 회사에서 CI와 CD를 거쳐서 배포를 하기 때문에 CI/CD 묶어서 부른다.

1. 개발자가 작은 단위로 기능을 나누어서 주기적으로 main repository에 Merge
2. 자동으로 빌드
3. 테스트 과정
4. 릴리즈 준비
5. 수동 또는 자동으로 최종 배포 완료

🧰 CI/CD를 위한 다양한 툴

회사마다 각각의 다른 툴을 사용하고 있기 때문에 회사에서 어떤 툴을 사용하는지 알아보고 그 툴에 대해서 정확히 알아보고 공부하는 것이 좋다.

• Jenkins, Buildkite (주로 많이 사용되는 툴)
• GitHub Actions (요즘 많이 사용하는 툴)
• GitLab CI/CD, Bitbucket Pipelines, circleci