CI/CD, 어떻게 접근해야 할까?

업데이트: January 12, 2022

CI/CD Build Automation by Elastic 7.16

~~출근하고 업무 시작시간 전에는 보통 그 날 업무 to do list 를 작성하는데 오늘따라 재밌는 메일이 와있길래…~~
Elastic 7.16 버전 업데이트 관련 소개 문서를 읽다가 꽤 관심 가는 내용이 보여서 영어 공부 겸 번역해보기로 했다.

~~번역하는 데만 시간 엄청 걸린~~ https://www.elastic.co/kr/blog/whats-new-elastic-observability-7-16-0 페이지의 CI/CD 관련 내용은 아래와 같다.

CI/CD 빌드 자동화와 배포에 대한 가시성을 확보하자

현대의 애자일 배포 프로세스와 CI/CD 자동화로 인해 소프트웨어 개발 팀들은 빠르게 빌드하고 배포함으로서(ship releases) 혁신을 가속화하고 시장 출시 시간을 앞당길 수 있게 되었다. 그러나 빌드부터 테스트, 배포에 이르기까지 파이프라인에 대한 퍼포먼스의 인사이트(통찰력, insight) 없이는 어플리케이션 팀들은 개발의 급작스런 중지(outages)에 취약해지고, 출시 사이클이 연장되고 최종 단계(the bottom line)에 영향을 끼칠 수 있다.

Elastic Observability 는 소프트웨어 개발 수명 주기(Software Development Life Cycle, SDLC)의 전 단계에 걸쳐 각종 이슈(오류가 잦은 작업(error-prone jobs), 느린 빌드 과정, 혹은 까칠한(flaky) 테스트) 에 대한 모니터링 및 알람, 트러블 슈팅을 위한 주요한 파이프라인 인사이트를 제공한다. Elastic 7.16 버전에서는, 기존 버전에 존재하던 Jenkins pipeline observability 플러그인은 물론, Ansible 과 Maven 을 위한 OpenTelemetry 통합을 사용하여 CI/CD 파이프라인 가시화를 더욱 세세하게 나누어 작업할 수 있게 되었다. 이러한 툴들은 DevOps 와 SRE 는 물론 개발 팀에 이르기까지 폭넓게 사용할 수 있어, 개발을 위한 파이프라인을 자동화시킬 수 있다(만약 이 툴에 문제가 생기면 파이프라인 움직임 또한 실패하게 됨) ※ OpenTelemetry : telemetry(trace, metric 및 logs) 데이터를 만들고 관리하는 API, SDK, 도구 통합 세트

Ansible 과 Maven 을 이용한 새로운 통합은 작업을 실행하거나 트러블 슈팅 및 최적화, 문서화를 위해 배포할 때 발생하는 에러에 대해 더욱 깊은 가시성을 제공하여, 릴리즈를 담당하는 팀으로 하여금 빠르게 운영하고 더욱 안정적인 자동화 시스템을 가능케 한다. 그들은 모든 Ansible 플레이북과 Maven 빌드를 이용해서 종합적인 가시화를 제공하고, 각 움직임(each run)에 대한 트레이스(추적, trace)를 생성하며, 팀원들이 쉽게 이해할 수 있도록 아래와 같은 퍼포먼스 메트릭을 만들어 준다.

어떤 Ansible task 나 Maven goal 이 가장 많이 움직였는지(run the most)
(배포 등의 작업이) 얼마나 자주 실패했는지
(배포 등의 작업을) 완료하기까지 얼마나 시간이 걸렸는지

이 모든 것들을 무료로 오픈하기 위한 Elastic 사의 노력의 일환으로서, 우리는 Ansible 이나 Jenkins, 그리고 다른 OpenTelemetry 커뮤니티와 같은 오픈소스 기반의 CI/CD 통합 툴에 기여해 왔습니다.

Elastic 의 CI/CD Observability 는 파이프라인과 기존 작업(jobs)들에 대해서 기존 스크립트를 수정할 필요 없이 자동으로 구성해 주기 때문에 쉽게 실행할 수 있다. 파이프라인을 실행함으로서, 어떤 중단 이슈(outage)의 원인(nature)과 영향(impact)을 평가하기 위해 파이프라인의 모든 단계를 분석하는 기능을 통해, 곳곳에 퍼져 있는 트레이스(추적)를 직관적으로 가시화할 수 있다. 트러블 슈터들은 에러와 지연 문제에 대한 원인을 식별할 수 있어, 더욱더 안으로 파고들어가는(drill into) 추적이 가능해진다.

또한 CI/CD 관리자들은 파이프라인을 통해 시스템의 헬스 체크 및 에러, 성능 메트릭 정보를 확인하고, 시간이 지남에 따라 그 성능에 대해 깊이 이해할 수 있게 된다. 하나의 파이프라인은 물론이고 광범위한 복수의 파이프라인에 이르기까지, 전체 CI/CD 플랫폼은 아닐지라도 다양한 이슈에 대해 영향을 빠르게 체크할 수 있게 해 준다.

CI/CD

무튼 Observability 를 위해 Elasticsearch 를 사용하는 조직에서 버전 7.16 에서는 이 CI/CD 파이프라인을 이용해서 더욱 효율적으로 telemetry 기능을 활용할 수 있다는 것인데, 정작 CI/CD 란 무엇인가? ~~통합 배포라고 해 봐야 감이 잘 안잡힌다~~ 마침 Redhat 공홈에 내용이 알기 쉽게 정리되어 있어서 정독하며 정리해본다.

(Redhat 에서 알려주는) CI/CD 개념

CI/CD 는 Continuous Integration(지속적인 통합)/Continuous Deployment(지속적인 배포) 의 줄임말이다. 어떤 애플리케이션이나 프로그램을 개발 및 운영할 때, 각각의 단계를 자동화함으로써 보다 빠르게 서비스를 제공할 수 있음은 물론이요, 기존 코드를 버전 관리할 때 생기는 문제들(인테그레이션 헬)을 해결할 수 있는 효과적인 기술이다.

특히, 애플리케이션 개발을 위한 (통합, 테스트, 배포, 제공에 이르는) 라이프사이클을 지속적으로 자동화하고 모니터링할 수 있는 기능을 제공해준다. 이를 일반적으로 CI/CD 파이프라인이라 일컫는다.

구성

그림 하나 추가하면 좋을듯 : 흐름 흘러가듯이 화살표로. redhat 에서 가져오면?
- Continuous Integration
- Continuous Delivery
- Continuous Deployment

과제

Terraform - Ansible - Jenkins 으로 구성하는 CI/CD
SRE 와 CI/CD 의 관계성, 내가 나아갈 방향

Julie Lee

CI/CD, 어떻게 접근해야 할까?

CI/CD Build Automation by Elastic 7.16

CI/CD 빌드 자동화와 배포에 대한 가시성을 확보하자

CI/CD

(Redhat 에서 알려주는) CI/CD 개념

과제

참고

참고

업무적 글쓰기가 고민인 당신을 위하여 - 개발자의 글쓰기

Review! AWS Online Edu 「AWS 에센셜 - 클라우드 기초의 모든 것」

Mapping Type in Elasticsearch

Review! AWS Online Edu 「초보자를 위한 컨테이너 시작하기」