서론
프로그래머는 제품(소프트웨어)을 생성하기 위해 머리를 쥐어짜서 코딩을 한다.
어떻게 하면 더 효율적으로 자원을 사용할지, 속도는 어떻게 개선할지, 버그는 어떻게 고쳐야 할지...
그렇게 힘들게 만들어낸 코드를 사용자에게 선보이기 위해선 작성한 코드를 빌드, 테스트하고 배포 하여야 한다.
컴파일(Compile) 및 빌드(Build)
컴파일은 우리가 작성한 코드를 컴퓨터가 이해하고 동작시킬 수 있도록 번역해주는 작업이라고 할 수 있다.
이러한 작업을 수행하는 것을 컴파일러(Compiler)라고 하며, 컴파일을 마친 소스코드를 링크 과정을 거쳐
실제 실행 가능한 소프트웨어(. exe파일)로 만들어주는 과정 전체를 빌드라고 한다.
- 전처리
전처리가 전처리 구문을 처리하는 것을 말한다.
C언어에서 볼 수 있는 #include, #define 등이 이에 속한다.
전처리 과정을 통해 .i파일을 생성한다. - 컴파일
전처리가 끝난 .i파일을 어셈블리어로 변경해주는 작업을 한다.
컴파일 과정을 통해 .s파일을 생성한다. - 어셈블
컴파일이 끝난 .s파일을 기계어로 바꿔주는 작업을 한다.
어셈블 과정을 통해 .o파일을 생성한다. - 링크
링커가 어셈블링된 .o오브젝트 파일과 프로그램에서 사용된 표준 라이브러리, 사용자 라이브러리 등을 링크한다.
이러한 일련의 과정들은 적잖은 시간을 소요하고, 번거로운 일이 될 수 있다.
때문에 시간을 단축시키기 위해서 등장한 것이 CI/CD라고 할 수 있다.
CI(Continous Integration)
CI는 지속적인 통합(Contionous Integration)을 의미한다.
두 명, 혹은 그 이상의 개발자가 하나의 프로젝트를 협업하여 진행한다고 생각해보도록 하자.
개발자들은 각각 코드를 수정하고 이들을 추후에 통합하게 될 것이다.
이때 코드 작성 기간이 길어질수록 의도치 않게 동일한 부분을 수정하여 코드가 충돌하는 상황이 발생할 수 있다.
필자도 실제로 대학교 팀 프로젝트 진행 중 git을 사용해 협업을 진행했는데,
팀원들과 동일한 부분을 수정하여 충돌이 발생해 이에 대한 문제를 해결하는데 시간을 소비하기도 했다.
이런 상황을 해결하기 위해선 개발자들이 짧은 주기로 지속적으로 코드를 통합하는 방법을 사용할 수 있다.
하지만 이와 같이 코드를 통합할 경우 해당 코드가 정상적으로 동작하는지 빌드 및 테스트를 진행해야 한다.
짧은 주기로 코드를 통합할 때마다 빌드 및 테스트를 진행하면 그만큼 시간이 더 소비되고, 번거로울 것이다.
때문에 개발자들은 코드를 통합만 하고, 빌드 및 테스트는 굳이 사람이 하지 않고 자동화하자는 것이 CI이다.
이러한 자동화를 통해 개발자는 좀 더 개발에 집중할 수 있고, 시간을 단축시킬 수 있다.
테스트 과정에서 버그 및 오류가 발생했을 시에는 추후에 이를 해결할 수 있다.
CD(Continous Delivery&Continous Deployment)
CD는 지속적인 제공(Continous Delivery) & 지속적인 배포(Continous Deployment)를 의미한다.
제공과 배포라는 말에서 알 수 있듯이, 개발자가 만들어낸 소프트웨어를 사용자에게 전달하는 것을 의미한다.
먼저 지속적인 제공(Continous Delivery)은 CI과정을 통해 테스트를 끝낸 코드를
github 등의 저장소(레포지토리)에 자동으로 업로드하는 것을 의미한다.
개발자, 혹은 개발팀에선 이렇게 업로드된 코드에 문제나 수정할 부분이 없는지 확인하여
사용자들에게 `수동적`으로 배포하는 것이 지속적인 제공이다.
지속적인 배포(Continous Deployment)는 위의 과정을 거치고 배포할 준비를 끝마치면
사용자에게 제품(Product)을 `자동적`으로 배포하는 것을 말한다.
장점
1. 시장 출시 기간 단축
CI/CD과정을 통해 빌드, 테스트, 배포 과정을 자동화하여 사용자에게 제대로 동작하는
소프트웨어를 자주, 빠르게 업데이트하여 배포할 수 있다.
2. 검증 시간 단축
CI과정에서 말했듯이 빈번한 통합 과정에서 생기는 빌드, 테스트 과정에 대한 불필요한 시간을 단축시킬 수 있다.
빈번한 통합과정을 작은 단위로 진행하면, 그만큼 메시지가 구체적이 되기 때문에 개발 과정을 파악하기가 용이하다.
3. 코드 품질 개선
CI/CD과정에서의 지속적인 테스트를 통과한 코드만이 통합되고, 이 과정에서 걸러진
버그나 오류가 있는 코드들을 지속적으로 수정함으로써 시간이 지남에 따라 코드의 품질이 향상된다.
4. 빠른 버그 수정
상술했듯이 빈번한 통합 과정으로 인해 세분화되어있기 때문에
버그나 오류 발생 시 문제가 되는 부분을 찾아 수정하기가 용이하다.
5. 파이프라인에 대한 평가 및 개선
CI/CD파이프라인에 사용되는 도구들을 통해 프로세스를 평가할 수도 있다.
이를 통해 빌드 시간, 테스트 커버리지, 결함률, 테스트 수정 시간 등의 평가 지표가 제공된다.
제공된 지표를 토대로 일련의 과정들을 지속적으로 개선할 수 있다.
6. 사용자 피드백
빈번한 업데이트 및 배포를 통해서 사용자로부터 해당 버전에 대한 피드백을 받고, 이를 즉각적으로 수용할 수 있다.
예를 들어 시험적인 디자인이나 동작 등을 릴리즈하여 사용자의 피드백을 받아볼 수도 있다.
피드백 과정을 통해 작업 수행에 있어 수정 및 개선할 부분의 우선순위를 정할 수 있다.
7. 용이한 협업
상술한 CI/CD과정의 빈번한 통합을 통해 개발자 간의 협업 중 중복 코드 충돌 등의 문제를 해결할 수 있고,
세분화된 개별 작업들을 팀원끼리 리뷰하는 상호 피드백을 통해 보다 질 높은 코드를 작성하여
결과적으로 질 높은 제품을 사용자에게 제공하게 된다.
'Computer Science' 카테고리의 다른 글
| 해시맵(HashMap) (0) | 2022.02.01 |
|---|---|
| [알고리즘/정렬] 선택, 버블, 삽입, 병합, 퀵, 힙 (0) | 2022.01.16 |
| (메모리)코드, 데이터, 힙, 스택 영역 (0) | 2022.01.15 |
| [자료구조] 트리(Tree) (0) | 2022.01.13 |
| 동기(Synchronous)와 비동기(Asynchronous) (0) | 2022.01.11 |