[Dep/Jenkins] CI/CD [1]

이번글은 CI/CD에 관한 글이다.

논리적인 접근 및 타당성에 집중해서 글을 작성해보려고 한다.

근데왜 Jenkins목록에 있냐면 Jenkins를 공부하는것이 궁극적인 목표이고 이를 위한 초석은 CI/CD에 대한 정의를 알고가야 하기때문에 글을 작성하려고 한다.

Jenkins에 대한 글은 추후 작성된 글을 참고하면 된다.

---

CI/CD

1. CI/CD는 왜 필수적인가?

소프트웨어 개발 환경은 점점 복잡해지고 있다. 이에 따라서 빠른 출시와 품질 유지 사이에서 균형을 맞추는 것이 중요하다. 기존 개발 방식에서는 다음과 같은 단점을 가진다.

레거시 방식의 단점

1. 수작업 기반의 빌드와 배포 :
   - 사람이 개입하는 단계가 많아 실수가 발생할 수 있다.
   - 여러 개발자의 코드를 정상적으로 합치는 과정 혹은 모듈을 합치는 과정에서 시간 소모가 크고 효율성이 떨
2. 늦은 피드백과 오류 발견 :
   - 코드 병합 및 테스트를 개발과정 후반부에 진행됐을때 문제가 생기면 수정 비용이 엄청나게 증가한다.
   - 즉각적인 피드백이 이루어지지 않아 성능 혹은 유지보수 비용이 증가할 수 있다.
3. 일관성 없는 배포 환경 :
   - 일관된 환경이 아닌 특정 사람의 환경에서 빌드하게 됨으로 개발, 테스트, 운영 환경간 설정 불일치로 인해 배포시 문제가 발생할 확률이 많다.
   -  개발자마다의  IDE 혹은 Plugin 및 다른 software의 환경에 의존하게 될수 있으며 이는 개인 환경 의존성이 생길수 있고 실제 배포 환경에서 동일한 결과를 낸다고 확신할 수 없다.

결론 

이상적인 빌드와 배포 과정은 사람의 개입을 최소화하고 일관된 명령어 기반의 자동화된 시스템으로 실행되어야 한다. 또한, 특정 IDE나 개인 환경에 의존하지 않고 실제 배포 환경과 동일하거나 유사한 환경에서 수행되어야 오류를 방지하고 일관된 결과를 보장할 수 있다. 그리고 지속적인 피드백이 이루어져야 한다.

따라서 개발자라면 이러한 문제를 다음과 같이 해결할 수 있다.

지속적 통합 (Continuous Integration) -> 지속적 전달 (Continuous Delivery) ->연속 배포 (Continuous Deployment)

이에따른 CI/CD의 궁극적인 목표는 다음과 같다.

• 지속적인 가치 제공
• 리스크 최소화
• 개발 효율성 극대화
• 일관된 품질 보장
• 피드백 루프 단축
• 안정적인 운영

---

2. CI/CD의 개념 및 구조

1. CI 지속적 통합 (Continous Integration)
   코드 품질의 유지와 문제를 초기에 발견하는데 초점을 둔다.
   - 팀 구성원이 하루에 한번 이상 작업을 통합하는 소프트웨어 개발 방법론이다.
   - 코드가 커밋 혹은 병합 후 소프트웨어가 즉시 구축되고 테스트 되어야 한다. 이에 피드백이 동반되어야 한다.
   - 주로 단위 테스트로 진행하게 된다. 핵심 모듈 간의 연동도 확인한다.
2. CD 지속적 전달 (Continuous Delivery)
   시스템을 항상 배포 가능한 상태로 유지하는데 초점을 둔다.
   - CI를 통과한 코드는 자동화된 테스트, 패키지 과정을 거친다.
   - 배포 준비 상태로 실제 제품 환경과 유사한 환경에서 최종 검증을 거친다. 이에 피드백이 동반되어야 한다.
   - 주로 CI보다 더 광범위한 테스트로 진행한다. CI는 단위 테스틀 봤다면 CD에서는 통합, API, System, UI/UX, 성능, 보안 등의 테스트를 진행한다. 최종 환경을 검증하는 것이다.
3. CD 지속적 배포 (Continous Deployment)
   지속적 전달에서 더 나아가서 코드가 자동으로 실제 제품 환경에 배포하는데 초점을 둔다.
   - 사람의 개입 없이 자동으로 코드 변경 사항을 운영 환경에 반영하는 과정이다.
   - 이또한 배포후 모니터링을 통한 피드백이 동반되어야 한다.
   - 상황에 따라서 결정권자의 승인등을 필요로하거나 지속적 배포는 진행하지 않을 수도 있다.

CI/CD는 트렌드인가?

결론적으로 CI/CD는 단순 트렌드 및 다들하니까 우리도하자가 아니다.

Agile같은 현대 개발 상식에서 필수적인 요소로 자리 잡은 핵심 도구이다.

---

3. CI 시스템 사용의 우수 사례로 보는 중요 사항

CI 과정을 설계할때 다음 내용들에 초점을 맞춰야 한다.

• 일찍 커밋하고 자주 커밋하고 항상 커밋하자. 손상된 코드는 커밋하지 말자
• 빌드 실패시 즉시 수정하자
• 모니터링 및 측정 항목에 따라 조치하자
• 모든 제품 환경에서 빌드인 모든 빌드에서 아티팩트를 생성하자
• 소프트웨어 빌드는 자동화 될 수 있는 방식으로 수행되어야 한다
• IDE등 특정 Tool에 의존하면 안된다
• 변경시 모든 것들을 빌드하고 테스트 해야한다
• 데이터베이스 스키마는 모든 것들로 간주되어야 한다
• 잦 체크인하자
• 단위 테스트가 중요하다
• 빌드 속도를 빠르게 유지하자

설계시의 핵심은 즉 변경을 빠르게, 테스트를 즉시, 빠르게 수정, 특정 상황에 의존하지 않은 프로세스를 유지해야 하는것이다.

단점은 있나?

초기 설정 및 학습 비용, 추가 리소스 및 환경 필요, 테스트 리소스 부담, 프로세스 변환의 어려움과 코드 통합시 발생하는 대기 시간등이 단점이 될수있다.

그래도 사용해보자

CI/CD는 단순한 프로세스 개선이 아니라, 소프트웨어 개발의 논리적이고 필연적인 진화 과정이라고 생각한다.

개발 속도, 품질, 안전성을 모두 잡기 위해서 지속적으로 통합, 전달, 연속배포로 이어지는 CI/CD 이래도 도입하지 않을 것인가?

CI/CD를 통해서 개발자들은 빠르게 변화하는 세상의 빠르게 변화하는 비지니스 요구에 대응하고 더 좋은 제품을 생산해 낼수 있을것이다.