CI/CD 도전기(1)

유재경·2021년 6월 12일
0
post-thumbnail

※ Apple Developer 계정이 있어야 합니다. 개발자 계정이 없어서 마지막 과정은 링크를 걸어두었습니다.

현업에서 앱 배포하기 전 CI/CD를 거친다는 내용을 들어만 보았고, 구인공고를 보면 사용하는 Tool에 Jenkins, Fastlane, Jira (Github, Slack은은 무엇인지 알고 있었다.) 가 단골로 등장하는 걸 볼 수 있었다
그래서 뭔데..?라는 생각이 들다가 이번에 본격적으로 공부하여 이것이 무엇이고, 왜 쓰는 것이고, 어떻게 설치하는지 겪어보기로 하였다!
이번 파트에서는 개념과 Tool 위주로 작성하였다

CI/CD란?

CI

Continuous Integration, 직역하면 지속적인 통합이다.
코드가 신뢰성 가능한 수준으로 배포될 수 있도록 지속적으로 빌드와 테스트를 통해 관리하는 것이다.
정기적으로 코드가 테스트 및 빌드되어 여러 명의 개발자가 협업할 때 충돌 위험성을 줄여준다. = 빌드&테스트 자동화

CD

Continous Deploy(Delivery), 직역하면 지속적인 배포를 말한다.
앞서 CI에서 통과한 코드에 대하여 테스트서버와 운영서버에 곧바로 그 내용을 배포해 반영하는 것을 말한다. 따라서, 테스트를 거쳐 리포지터리(Github)에 자동으로 업로드되고, 실시간 프로덕션 환경으로 배포된다. = 배포 자동화

CI/CD 파이프라인은 짧은 단위의 작업을 신속하게 테스트 및 배포하는 과정을 반복하는 Agile 방식에서 활용된다.

자동화를 하는 이유?

다음과 같은 상황을 살펴보자

총 5명의 사람이 프로젝트를 진행하기로 했다. 
Github에 큰 틀이 잡혀 있는 코드를 각자의 local repository로 fork해서 작업을 하기 시작한다.
각자의 작업을 다 끝낸 후 마지막에 코드를 한 번에 통합했다

엄청난 양의 코드를 한 번에 통합하려는 순간, 각종 오류들이 발생할 위험성이 커진다. 그래서 방식을 다음과 같이 바꿨다

이번에는 마지막에 전체 코드를 통합하는 것이 아니라, 하루 끝에 각자의 작업을 중앙 코드와 통합하고, 본인의 코드가 잘 빌드되고 테스트되는지 확인한다.
결과를 정리하고, 버그를 기록해둔다.

아까보다는 협업 시 오류 발생 가능성을 줄일 수 있다. 그치만 매일 이렇게 빌드, 테스트 해야한다면?? 코드가 점점 방대해져서 테스트 시간이 길어지게 된다면?? 퇴근 또한 늦어지고 기다리는 시간이 아깝게 된다.
그래서 다음과 같이 작업을 더욱 단순화 시켰다.

모든 개발자는 퇴근하기 전 자신의 코드를 중앙 코드와 통합한다.
다음 날 출근 시 메일로 발송된 결과 리포트를 확인하고 버그를 수정한다
통과한 코드에 대하여 테스트서버와 운영서버에 곧바로 그 내용을 배포해 반영한다.

매일같이 반복된 작업을 하는 것은 지겹기 때문에 빌드->테스트->배포 일련의 작업들을 파이프라인으로 자동화 한 것이다.이렇게 파이프라인을 형성해 놓으면 중간 과정을 빠트릴 일이 없고 일일이 빌드가 되었나?? 그 다음에 빌드가 되었으니 테스트를 해볼까?? 테스트가 잘 되었는지 확인해볼까??? 과정이 생략되는 것이다.

결론

CI/CD 파이프라인은 여러 개발자가 협업할 때 정기적으로 빌드, 테스트, 배포 과정을 거쳐 충돌 위험성을 줄임과 동시에 자동화를 통해 시간을 절약해준다.

CI/CD Tool

Travis CI, Jenkins, TeamCity의 장단점으로 잘 비교해주셨다.
https://elfinlas.github.io/2019/08/14/ci-tool/

국내에서는 CI는 Jenkins로, CD는 Fastline으로 파이프라인을 구현하는 것으로 보인다. 다음 포스팅에서는 Jenkins, Fastlane을 설치해보겠다~

(출처 https://itholic.github.io/qa-build-automation/
https://itholic.github.io/qa-cicd/
https://www.redhat.com/ko/topics/devops/what-is-ci-cd)

profile
iOS 개발

0개의 댓글