CI/CD 시리즈는 유데미의 Master CI/CD for iOS Developer 강의를 보고 정리한 내용입니다!
곧 진행할 프로젝트에서 CI/CD 도입하기라는 목표를 두었음.
자세한 이유는 많지만.. 간단히 말하자면, 배포까지 진행해야 하기에 반복되는 작업들을 자동화 할 필요성을 느꼈기 때문!
처음 해보는거라 걱정이 태산...
DevOps란?
DevOps = Development + Operation
애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합이다. 기존의 소프트웨어 개발 및 인프라 관리 프로세스를 사용하는 조직보다 제품을 더 빠르게 혁신하고 개선할 수 있다. 이러한 빠른 속도를 통해 조직은 고객을 더 잘 지원하고 시장에서 좀 더 효과적으로 경쟁할 수 있다.
개발팀과 운영팀이 단일팀으로 병합되어 엔지니어가 개발에서 테스트, 배포, 운영에 이르기까지 전체 애플리케잇연 수명 주기에 걸쳐 작업하고 단일 기능에 한정되지 않은 광범위한 기술을 개발한다.
- aws 공식문서
항상 정의는 와닿지 않는다..
DevOps의 뜻
실제 서비스를 배포하고 관리한다면 기능 구현 외에도 빌드, Merge, 테스트, 배포 등 할 일이 되게 많음.
'개발만 하기도 바쁜데 반복되고 시간이 많이 걸리는 일들을 자동화 시킨다면 생산성을 더욱 높일 수 있지 않을까?'
라는 생각에서 출발된게 DevOps!
또 실제 회사라고 생각한다면 장애 대응, 새로운 버전 릴리즈 등을 빠르게 해야 경쟁에서 밀리지 않을 수 있음!
따라서 새로운 기능을 추가했을 때
- 빌드가 올바르게 실행되는지?
- 테스트가 통과하는지?
- (문제가 없다고 판단되면) 사용자에게 배포
위 과정들을 자동화하여 빠르게 사용자에게 새로운 버전을 릴리즈 하도록 하는 것.
두 줄 요약
DevOps는 빌드, 테스트, 배포를 자동화하여 사용자에게 빠르게 새 버전 릴리즈를 할 수 있도록 도와줌.
개발자는 기능 개발에만 집중하도록 하여 팀 전체의 생산성을 높여줌.
DevOps의 필요성
DevOps의 뜻을 설명하면서 필요성도 언급했지만..! 장점과 관련해서 같이 한 번 더 봅시다.
DevOps는 새로운 기능을 사용자에게 더 빠르게 전달하기 위한 철학 또는 방법론임.
이를 통해 개발자가 기능 개발에만 집중할 수 있도록 해주는 것.
특히, 현업처럼 프로젝트의 규모가 큰 경우에는 빌드 시간이 엄청나게 걸림!
'빌드 시간이 길어봤자 얼마나 길겠어?'라고 생각했었는데... 컨퍼런스 뒤적거리다가 아래 영상을 발견함...
카카오뱅크 iOS 프로젝트의 모듈화 여정: Tuist를 활용한 모듈 아키텍처 설계 사례 /if(kakao)2022
카카오뱅크 iOS 프로젝트의 경우 21년도 당시 10,000개의 파일, 99만줄의 코드로 구성된 프로젝트였음.
- 빌드 시간
- 프로젝트 규모
풀 빌드 하는데 10분이 넘게 걸리게 됨...
프로젝트 규모 사진에서 오른쪽 스크립트를 요약하면
- 빌드 시간이 길어져 버그 기능 개선과 같은 유지 보수 작업에 시간이 많이 소요
- 테스트 작성, 실행 및 확인 시간 오래 걸림
- 기술 부채가 점점 쌓임.
- 코드 품질이 점점 나빠짐.
- 악순환 반복
긴 빌드 시간으로 인해 생산성 저하가 발생했다는 것...
물론 이 문제는 CI/CD로만 해결할 수 있는 문제가 아님. 컨퍼런스의 주제가 모듈화를 통해 해결했다라는 내용이지만, 대규모 프로젝트의 빌드 시간을 체감하기에 도움이 되서 첨부함!!
다시 본론으로 돌아와 빌드도 많은 시간이 걸리는 작업이고, 테스트도 테스트 코드 작성뿐만이 아니라 테스트 통과를 확인하고, 원인을 파악하는데 많은 시간이 걸림.
따라서 이 모든 것을 자동화하고, 배포 과정까지 자동화하여 생산성을 높이는 것이 DevOps의 목표이자 필요성인 것임!
또 다른 상황은 애플에서 새로운 정책을 발표하는 경우도 있음.
예전에 소셜 로그인 기능 사용 시 Sign in with Apple을 무조건 추가해야 되는 정책을 발표한 적이 있음.
이때, 빠른 대응(개발, 테스트, 배포)을 하기 위해 DevOps가 필요함.
또 다른 상황은 사용자의 요청이 들어왔을 때 빠르게 반영하기 위해서도 DevOps가 필요함.
한줄 요약
DevOps를 이용하면 사용자를 빠르게 만족시킬 수 있고, 생산성 측면에서 이점을 가진다!
CI/CD란?
참고자료
https://www.redhat.com/ko/topics/devops/what-is-ci-cd
https://www.servicenow.com/kr/products/devops/what-is-cicd.html#what-is-the-difference-between-continuous-deployment-and-continuous-delivery
CI/CD는 Continuous Intergration(지속적 통합)과 Continuous Delivery/Deployment(지속적 제공/배포)를 의미함.
CI/CD는 DevOps와 같은 말이 아니라 DevOps의 일부로 구체적인 방법론/도구로 사용됨.
CI/CD 파이프라인
CI는 코드 변경 사항을 공유 소스 코드 레포지토리에 자동으로 자주 통합하는 사례를 의미한다. CD는 코드 변경 사항의 통합, 테스트, 제공을 나타내는 프로세스로, 두 부분으로 구성된다.
Continuous Delivery에는 자동 프로덕션 배포 기능이 없는 반면, Continuous Deployment에는 업데이트를 프로덕션 환경에 자동으로 릴리즈한다.이렇게 연결된 두 사례를 일반적으로 CI/CD 파이프라인이라 부른다.
- Red Hat 공식문서
CI란?
CI는 지속적 통합을 의미함!
예를 들어, develop 브랜치에서 개발자 각각이 작업하는 feature 브랜치를 만들어 작업한다고 가정하면 PR을 날린 후 빌드해보고, 테스트하고, merge하는 작업을 해야됨..!
CI는 이 과정을 자동화 함.
변경 사항을 기존의 프로젝트에 병합하고, 변경 사항이 기존의 프로젝트를 손상시키지 않도록 자동으로 빌드하고, 테스트(단위 테스트, UI 테스트, 통합 테스트)를 트리거하여 변경사항을 검증함.
이런 자동화된 테스트를 통해 충돌이 발생했을 때 버그를 빠르게 개선할 수 있음.
→ 개발 주기 초기의 문제 감지 가능!
또한 오류를 더 빨리, 많이 파악한다면 우선순위가 높은 수정 사항을 자동으로 지정하여 백로그로 빠르게 옮길 수 있음.
CD란?
CD는 두 가지 의미를 가짐. 바로 Continuous Delivery(지속적 제공)과 Continuous Deployment(지속적 배포).
두 용어를 혼합하여 사용할 수 있지만, 자동화의 진행 상황을 파악하기 위해 별도로 사용하기도 함!
Continuouos Delivery(지속적 제공)
Continuouos Delivery는 CI에서 빌드와 테스트를 마친 후 검증된 코드를 저장소로 릴리즈 하는 것을 자동화 하는 과정.
따라서 Continuouos Delivery 하기 전, CI가 선행되어야 더욱 효과적임.
Continuous Deployment와 가장 큰 차이점은 프로덕션 배포 전에 사람(운영 팀)의 승인이 필요하다는 것.
Continuouos Delivery 목표는 배포할 준비가 되어 있는 버전을 항상 가지고 있고, 새로운 코드를 배포하는 데 필요한 노력을 최소화 하는 것.
+추가)
항상 프로젝트의 작동하는 버전을 가지고 있는 것은 매우 중요함!
프로젝트에서 새 기능울 구현한 후, 어떤 문제가 발생해도 항상 작동하는 버전으로 되돌아갈 수 있어야 하기 때문.
또한, 실제 서비스에서 프로젝트의 작동하는 버전이 없다면..? 아찔...
Continuous Deployment(지속적 배포)
Continuous Deployment는 CI/CD 파이프라인의 최종 단계라고 볼 수 있음.
Continuous Delivery를 마친 후 제품을 릴리즈 하는 것을 자동화 하여 최종적으로 유저가 사용할 수 있도록 하는 것을 의미.
Continuous Deployment에서는 사람의 개입이 필요하지 않으므로 테스트의 신뢰성이 보장되어야 함.
또한, 완전 자동이기 때문에 매우 빠르게 배포가 가능하다는 점!
지속적 배포의 원칙
자세한 내용은 레퍼런스 참고
- 반복 가능하고 신뢰할 수 있는 과정 생성에 집중
- 가능한 모든 영역 자동화
- 가장 까다로운 작업을 먼저 수행
- 속도보다 품질이 더 중요
- 사용자 제공 준비가 완료되어야 변경 완료로 간주
- 책임의 공유
- 지속적 개선을 장려
전반적인 과정
강의에서는 AppCenter를 이용해 CI/CD 과정을 간략하게 먼저 보여주었음.
아직 프로젝트에서 어떤 도구를 사용할 지 결정하지 않았기에 실습은 미뤄두고, 정리만 해두었음!
브랜치 전략
브랜치: master ← test ← develop ← feature-branch
흐름
-
feature-branch에서 develop 브랜치로 PR을 날린다면?
→ PR 빌드 트리거
→ PR 빌드 실행
→ feature-branch에서 develop 브랜치로 merge 완료
→ Automatic Build 트리거 및 실행
→ IPA(iOS Package Appstore) 생성함.
-
develop 브랜치에서 test 브랜치로 PR을 날린다면?
→ PR 빌드 트리거
→ 빌드 실행
→ 테스트 트리거
→ 테스트 실행
→ IPA 파일 생성.
→ (테스트 성공 시) 새로운 릴리즈 베타 테스터에게 배포
-
test 브랜치에서 master 브랜치로 PR을 날린다면?
→ PR 빌드 트리거
→ PR 빌드 실행
→ 다른 팀원이 리뷰 후 merge 승인 (다른 팀원이 승인해야 merge되도록 설정했음)
→ PR 빌드 성공 && merge 승인
→ master 브랜치에 병합
→ Automatic Build 트리거 및 실행
→ Automatic Build 완료
→ 새로운 릴리즈 생성
→ App Store에 배포
