2022. 11. 22. 12:42ㆍ백엔드/기본
개발자라면 한번 쯤은 들어봤을 것이라고 생각한다.
DevOps 엔지니어의 핵심 업무인 만큼 인터뷰에서도 거의 빼먹지 않고 나오기 때문에 잘 이해하고 넘어가도록 하자
서비스를 오픈하거나 뭔가 핵심 기능을 운영 서버에 배포할 때 다들 한번쯤은 기도를 해본적이 있을 것이다.
항상 기도가 통한다면 좋겠지만 열명 사람 속은 알아도 프로그램 속은 모른다고(응?) 종종 문제가 생기곤 한다.
예를 들어 어떤 프로젝트를 배포했는데 갑자기 로그인이 안된다고 생각해보자.
개발자들은 난리가 날 것이고 모든 개발자가 붙어서 이 문제를 해결하려고 할 것이다.
급한 프로젝트일수록 더욱 빠르게 문제를 수정해야만 한다.
하지만 문제점을 찾아서 수정을 했다고 해서 끝이 아니다.
수정을 했으면 다시 컴파일, 빌드, 배포하는 과정을 통해 수정된 코드가 제대로 동작하는지 테스트하고 검증할 필요가 있다.
이 과정들은 시간도 많이 걸리고 실수하기도 쉽다.
이 과정에서 다른쪽에서 문제가 발생될 수도 있고 수정된 코드에 문제가 다시 생기면 또 다시 과정을 반복해야한다.
이를 위해서 CI/CD가 생겨났다.
CI (Continuous Integration) - 지속적인 통합
CI 란 Continous Integration의 축약어로
continuous 미국∙영국 [kənˈtɪnjuəs]
1. [형용사] 계속되는, 지속적인
2. [형용사] (선 같은 것이 끊어짐 없이) 계속 이어지는
3. [형용사][비격식] (여러 번) 반복된[거듭된] (=continual)
integration 미국∙영국 [ˌɪntɪˈɡreɪʃn]
1. [명사] 통합
2. [명사] (보통 피부색·인종·종교 등을 이유로 분리되어 있던 사람들의) 통합단어 그대로 지속적인 통합이라는 뜻이다.
애플리케이션의 버그 수정이나 새로운 코드 변경이 주기적으로 빌드 및 테스트되면서 공유 레파지토리에 통합되는 것을 의미한다.
CI가 나오기 전까지는 위와 같이 개발을 끝마치고 배포가 되어야만 코드에 오류는 없는지, 올바르게 동작하는지를 검증하며 코드 품질을 관리할 수 있었다.
CI가 필요한 환경에는 어떤 조건들이 있을까?
- 다수의 개발자가 형상관리 툴을 공유하여 사용하는 환경
: N년차 개발자 분들이시라면, 형상관리 툴(Git, SVN 등)을 사용하고 계시죠?
지속적으로 서비스해야 하는 어플리케이션이나 현재 개발 중인 어플리케이션은
기능 추가 시마다 commit 등을 날려 레포지토리(Repository)에 버전 업데이트를 하는데요.
다수의 개발자가 한 팀으로 작업할 경우, 이 공유 레포지토리에 수많은 commit들이 쌓이게 됩니다.
그럴 때마다, 기능별로 빌드/테스트/병합(Merge)까지 하려면 상당히 번거롭겠죠?
이런 상황에서, 자동화된 빌드&테스트는 원천 소스코드의 충돌 등을 방어하는 Benefit을 제공할 수 있습니다.
- MSA(Micro Service Archietecture) 환경
: 최근 IT 업계에 붐처럼 떠오르고 있는 아키텍처 모델입니다.
기존의 어플리케이션이 모든 기능을 포함하는 하나의 거대한 서비스이었다면,
MSA는 작은 기능별로 서비스를 잘게 쪼개어 개발하는 형태를 의미합니다.
MSA 환경에서는 대부분 Agile(소규모 기능 단위로 빠르게 개발 & 적용을 반복하는 개발방법론) 방법론이 적용되기 때문에, 기능 추가가 매우 빈번하게 발생하게 됩니다.
작은 micro service의 긴밀한 동작 테스트도 중요해지고요.
그러한 상황에서 CI의 적용은 기능 충돌 방지 등의 Benefit을 제공할 수 있습니다.
출처 : https://artist-developer.tistory.com/24
CI를 적용하게 되면 각자의 개발자 자신이 맡은 기능을 구현하면 된다.
이후 완성이 되면 main 브랜치와 통합하고 빌드 및 기능들이 올바르게 동작하는지 테스트하며 문제가 생기면 해결한다.
하지만 개발자가 직접 merge하고 빌드, 테스트를 검증하는 것은 프로젝트 크기에 따라서 양이나 걸리는 시간이 천차만별이다.
하지만 이것을 자동화하면 개발자가 빌드와 테스트를 직접 하지 않고도 브랜치에 merge하기만 하면 자동으로 빌드와 테스트를 할 수 있다.
개발자가 단위별로 구현한 부분을 merge할 때마다 자동화된 빌드와 테스트가 트리거되어 실행된다.
이러한 자동화를 통해서 어떤 부분에서 문제가 있는지 배포 전에 확인할 수 있고, 배포가 완성된 후에야 버그를 수정할 수 있던 기존의 문제를 빠르고 정확하게 해결할 수 있다.
요약하자면 CI의 간단한 순서는 아래와 같다.
1. 수정된 부분을 merge 한다,
2. merge된 코드가 올바르게 동작하고 빌드되는지 검증한다.
3. 결과에 문제가 있다면 수정 후 다시 1로 돌아가고 문제가 없다면 배포를 진행한다.
CD (Continuous Delivery 또는 Continuous Deployment)
- 지속적인 제공 또는 지속적인 배포
CD란 Continuos Delivery 또는 Continuos Deployment 의 축약어로
continuous 미국∙영국 [kənˈtɪnjuəs]
1. [형용사] 계속되는, 지속적인
2. [형용사] (선 같은 것이 끊어짐 없이) 계속 이어지는
3. [형용사][비격식] (여러 번) 반복된[거듭된] (=continual)
delivery 미국∙영국 [dɪˈlɪvəri]
1. [명사] (물품·편지 등의) 배달[인도/전달]
2. [명사] 출산, 분만
3. [명사] (연설·공연 등의) 전달[발표] (태도)
deployment
[명사] 전개, 배치
-> 개발 쪽에서는 deploy는 배포라는 뜻으로 사용된다지속적인 전달 혹은 지속적인 배포라는 뜻이다.
Continuous Delivery ( 지속적인 전달 )는 공유 레포지토리( git, svn ...등 )로 자동으로 릴리즈 하고 Production 레벨에는 수동으로 배포하는 것이고,
Continuous Deployment ( 지속적인 배포 )는 자동으로 릴리즈 후 Production 레벨까지 자동으로 배포하는 것 즉 자동화를 의미한다.
즉 Continuous Delivery는 수동 Continuous Deployment는 자동 이라고 생각하면 된다.
참고 : https://aws.amazon.com/ko/devops/continuous-delivery/
정리하자면
CI -> CD 로 진행되며
CI는 빌드, 테스트, merge까지를 의미하고
CD는 CI에서의 새로운 소스코드가 Production 환경까지 릴리즈 되는 것을 의미한다.
'백엔드 > 기본' 카테고리의 다른 글
| ORACLE ROWNUM 사용시 주의 (0) | 2024.01.24 |
|---|