[QA] CI/CD 란?
- 3 minsCI/CD
앞선 포스팅(빌드 자동화)과 이어지는 내용이다.
사실 CI/CD 개념 자체만 두고 보자면 자동화와 직접적으로 관련있는 내용은 아니다.
그럼에도 불구하고 CI/CD하면 거의 항상 따라오는것이 자동화인데,
프로젝트의 크기가 커질수록 자동화가 배제된 CI/CD는 더더욱 상상하기 어려워진다.
이게 도대체 무슨 소리인지, 우선 CI/CD가 무엇인지부터 간략히 살펴보자.
CI
CI는 지속적 통합(Continuous Integration)으로,
모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적 방식의 단점을 해소하기위해 나타난 개념이다.
말그대로 개발을 하면서 ‘코드에대한 통합’을 ‘지속적’으로 진행함으로써 품질을 유지하자는 것이다.
조금은 극단적인 예를 들어보자.
10명의 개발자가 참여하는 프로젝트가 있다고 가정해보자.
git에 기본 틀이 잡혀있는 코드가 올라와있고, 각 개발자가 자신의 로컬환경에 clone 받아서 작업을 시작한다.
그런데 개발이 끝날때까지 모든 개발자가 한 번도 중앙저장소에 코드를 올리지 않았고,
개발이 끝난 이후에 10명의 개발자의 코드를 한 번에 통합해야하는 상황이라면?
상상만해도 끔찍하니 더 말하진 않겠다.
적절한 예시일지 모르겠지만, 이해를 돕기위해 다른 예를 들어보자.
건물을 전부 다 지어놓고 마지막에 다시 돈을들여 대규모 보수공사를 하는 것보다,
층을 하나씩 쌓을때마다 올바르게 지어지고있는지 체크해주는것이 질적, 비용적 측면에서 모두 유리할 것이다.
햄버거를 다 만들어놓고 모든 재료가 제대로 들어갔는지, 유통기한이 지나지 않았는지 확인하는 것보다,
재료 하나를 올릴때마다 유통기한이나 재료의 양 등을 체크하는게 더욱 유리한 것처럼 말이다.
그렇다면 지속적 통합을 이루기 위해서는 어떻게 해야할까?
첫 번째 예제의 상황에서, 이런 규칙을 정하면 어떨까?
1. 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 코드와 통합한다.
2. 통합된 코드에서 본인의 코드가 제대로 동작하는지 테스트한다.
3. 통합된 코드가 제대로 빌드되는지 테스트한다.
4. 결과를 정리하고. 버그가 있다면 다음날 업무 목록에 적어둔다.
쉽게 말하면, 매일 퇴근하기 전에 git에 코드를 올리고 문제가 없는지 테스트하라는 것이다.
이러한 과정이 프로젝트 시작부터 종료까지 잘 지켜진다면 코드의 품질을 어느정도는 유지할 수 있을 것 같다.
그리고 막판에가서 모든 개발자의 코드를 통합하겠다고 난리법석(?)을 떨지 않아도 될 것 같다.
근데 왜 “~하다.” 라고 표현하지 않고, “~ 것 같다.” 라고 표현했을까?
이 방식은 개념만 놓고보면 아주 이상적으로 보인다.
하지만 CI의 단점이 있는데, 이미 눈치챈 사람도 있겠지만 ‘너무 귀찮다’는 것이다.
git에 코드를 올리는 것 까지는 그렇다고 쳐도,
코드가 커질수록 테스트 양은 물론이거니와 테스트 시간도 점점 길어질 것이다.
게다가 이것은 굳이 사람이 일일이 돌리지 않아도 되는 매우 지루한 반복 작업이다.
이렇게 되면 어떨까?
git에 코드만 올려놓으면 알아서 테스트와 빌드를 수행하고,
그 결과를 잘 정리해 개발자에게 자동으로 알려주는 프로그램이 있다면 좋지 않을까?
그렇기에 CI를 설명할때 항상 자동화라는 키워드가 따라다니는 것이다.
그럼 CI 자동화가 잘 이루어졌을때, 위의 규칙이 얼마나 단순화되는지 확인해보자.
1. 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 코드와 통합한다.
2. 다음날 출근시 메일로 발송된 결과 리포트를 확인하고 버그가 있으면 수정한다.
테스트나 빌드등 복잡한 절차가 모두 생략되고,
그냥 퇴근전에 코드를 git에 올리고 가면 되는 것이다.
이정도의 의지도 없다면 사실상 CI를 통한 코드 품질 개선 의지가 없다고 보는게 맞다.
CD
그렇다면 CI/CD에서 CD는 무엇일까?
CD란 지속적 배포(Continuous Deploy 또는 Delivery)로써,
소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 지속적으로 관리하자는 개념이다.
사실 어려울 것 없이 그냥 CI의 연장선으로 생각하면 된다.
배포 이전에 테스트와 빌드는 필수적이기 때문에,
사실상 CD가 되려면 항상 CI가 선행되어야 한다고 봐도 무방하다.
즉, CI 프로세스를 통해 개발중에 지속적으로 빌드와 테스트를 진행하고,
이를 통과한 코드에 대하여 테스트서버와 운영서버에 곧바로 그 내용을 배포해 반영하는 것이다.
이상적인 환경이라면 테스트와 빌드가 ‘지속적’으로 이루어지기 때문에,
배포 또한 자연스럽게 ‘지속적’으로 이루어지게 된다.
사실상,
CI = 빌드 및 테스트 자동화
CD = 배포 자동화
라고 기억해도 무방하다.
중요한 것은,
코드 품질관리에 있어서 CI/CD 자동화가 ‘왜’ 필요하며,
이러한 시스템을 구축하는 것이 ‘왜’ 중요한지에 대해 이해하는 것이다.
그래서 그 다음은?
하지만 모든 개념이 그렇듯,
이론은 이해하기 쉬우나 그것을 구현하는 것은 또 다른 이야기이다.
CI/CD 를 자동화하기 위해서는 고려해야할 부분이 생각보다 많으며,
언제, 어떤 자동화 프로세스를, 어떻게 돌리고, 어떤 방식으로 결과를 리포트할지 등의 절차를 매우 엄밀하게 정의해야한다.
다행히도 CircleCI, Travis, Jenkins 와 같이,
CI/CD 자동화를 조금이나마 쉽게 구현할 수 있도록 도와주는 괜찮은 솔루션들이 이미 몇 가지 있다.
그 중에서도 우리 팀은 Jenkins를 사용해 전사 CI/CD 시스템을 구축할 것 같은데,
작업(?)에 들어가기 전에 정말 현상황에서 Jenkins가 최선인지, 마지막으로 한 번 더 검증해야할 필요가 있을 것 같다.
다음 포스팅에서는 각 CI/CD 솔루션의 장단점을 간략하게 정리해보고자 한다.
코딩장이
-장이: [접사] ‘그것과 관련된 기술을 가진 사람’의 뜻을 더하는 접미사.