DevOps & CI/CD

Development + Operation

 

등장 배경

- 소프트웨어가 단순 비즈니스를 지원한 기능을 넘어 새로운 비즈니스를 창출하거나 기존 비즈니스를 주도하는 핵심으로 성장

- 기존의 SW 개발 방식과 운영(배포) 방식으로는 소비자가 원하는 서비스 신속히 제공 불가

 

기존 개발 체계 및 문제

- 개발 팀은 개발, QA는 테스팅하고 운영팀에 이관 (별도의 팀)

- 그 뒤 운영팀이 배포 및 관리 운영 시 개발팀 관여 안함

 

- 서비스에서 문제 생기면 서로 떠넘기기

기존 문제 해결 방식

- 문제 발견 단계(누가 해결?)

- 책임 회피 단계

- 갈등 단계

- 조정 단계(팀장의 역할 중요)

- 이제서야 문제 해결

=> 시간이 오래 걸리고 갈등이 남음 => 이직, 비용 손실, 서비스 저하

 

기존 개발 팀 관리의 문제

- 개발 팀은 프로덕트가 이관된 이후에는 관심이 없어 고객의 신규 요구 사항에 대해 저항, 거절

- 하지만 잦은 변경과 배포는 필수적

- 기존 방식으로는 문제 해결이 안됨

 

개선된 문제 해결 방식 1 (애자일)

- 애자일 개발 방식으로 기획팀과 개발팀을 하나의 팀으로 협력하여 요구사항 변화에 빠르게 반응

- 반복적이고 점진적인 개발, 잦은 릴리즈를 통해 요구사항을 신속하게 반영하여 변화에 대응

- 중소 규모의 소프트웨어 개발 적합

- 회사 CEO의 의지가 중요

- 개발 팀원의 적극적인 협조와 스크럼 마스터의 역할이 중요

.. 그런데 더 적극적인 방법으로 개발과 운영을 하나의 팀으로 구성할 필요가 있음

 

개선된 문제 해결 방식 2 (DevOps)

- Development(개발)과 Operation(운영)의 통합

- 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화, 철학, 방식 및 도구의 조합

- 기존 소프트웨어 개발 및 인프라 관리 프로세스를 통합하여 서비스를 더 빠르게 혁신하고 개선 가능

 

DevOps가 가능한 이유

- 예전에는 대형 벤더의 기술에 종속, 현재는 좋은 플랫폼과 오픈소스 활용 가능

- 기업이 원하는 소프트웨어를 통합적으로 개발하는 것이 아니라 여러 오픈소스를 합쳐서 개발하거나 다른 개발자의 도움을 받아 오픈소스 솔루션을 조합 및 구현하는 개발 형태가 훨씬 더 효율적인 시대

 

> 좋은 도구들의 등장 : 개발, 빌드, 테스팅, 배포 및 운영 모니터링 등에 대한 다양한 도구가 등장하여 개발 공정의 상당한 부분이 자동화

> 클라우드 시스템의 등자 : 개발 환경 뿐만 아니라 네트워크, 서버 등 인프라에 대한 전문 운영팀 및 전문 지식이 없어도 클라우드의 도움으로 운영 가능

 

DevOps의 작동 방식

- 개발팀과 운영팀이 서로 협력/벼압하여 개발, 테스트, 배포, 운영에 이르기까지 전체 소프트웨어 개발 주기에 광범위하게 적용

- DevOps는 하나의 아이디어(새로운 소프트웨어 기능, 개선 요청 또는 버그 수정 등)가 사용자에게 가치를 제공할 수 있도록 통합 운영 환경에서 개발로부터 배포로 진행되는 프로세스의 속도를 높이는 접근 방식

- 때로는 보안을 결합하여 DevSecOps

- DevOps를 제공하는 기술 스택과 도구를 사용함으로써 코드 배포 등을 독립적으로 수행할 수 있어 작업 속도가 빨라짐

- 이러한 접근 방식을 적용하려면 개발팀과 운영팀이 자주 커뮤니케이션하고 팀원들과 공감하면서 업무에 접근해야 함

- 확립 시 셀프 서비스와 자동화를 통해 다양한 이점과 경쟁력을 얻을 수 있음

 

DevOps로 지속적인 배포, 확장

- 데브옵스 구현의 주요 성과는 지속적인 통합(CI) 및 지속적인 배포(CD) 파이프라인 구성

- CI/CD를 통해 애플리케이션의 제공 주기를 단축하고 사용자의 개입을 최소화하여 소프트웨어 품질 검증 가능

- CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공하여 신속하게 문제 및 결함을 식벼랗고 수정

- 이러한 구축 사례 -> CI/CD 파이프라인

---

DevOps의 핵심 요소

- Culture .. 개발팀과 운영팀 간 경계를 허물고 협업하는 문화

- Automation .. 반복 작업의 자동화

- Share .. 지식의 공유, 공동 작업 공간

- Measure 키 성과 지표(KPI)

 

CI/CD (Continuous Integration / Continuous Delivery, Deployment)

- CI는 개발자를 위한 자동화 프로세스, 지속적인 통합 (Continuous Integration)

- CI 성공적 구현 시 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 빛 테스트 되어 공유 리포지토리 통합

-> 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제 해결 가능

- CD는 지속적인 서비스 제공(Continous Delivery) 및 지속적인 배포(Continuous Deployment)

- 지속적인 제공이란 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리에 자동으로 업로드되는 것을 뜻함

 

지속적인 통합(CI)

- 개발자들은 코드 변경 사항을 공유 브랜치 또는 트렁크로 다시 병합하는 작업을 더욱 수월하게 자주 수행 가능

- 개발자가 애플리케이션에 적용한 변경 사항이 병합되면 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축하고 각기 다른 레벨의 자동화 테스트

- 클래스와 기능에서부터 전체 애플리케이션을 구성하는 서로 다른 모듈에 이르기까지 모든 것에 대한 테스트를 수행, 자동화된 테스트에서 기존 코드와 신규 코드 간의 충돌이 발견되면 CI를 통해 이러한 버그를 더욱 빠르게 자주 수정할 수 있음

 

지속적인 제공(CD)

- 지속적인 제공 프로세스에서는 유효한 코드를 리포지토리에 자동으로 릴리스

- 코드 변경 사항 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계에는 테스트 자동화와 코드 릴리스 자동화가 이루어짐, 이 프로세스를 완료하면 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 됨

- 이 모든 과정이 소프트웨어 도구를 사용하여 자동으로 이루어짐

 

CI 단계

- 개발 : 여러 명의 개발자가 개발

- 통합 : 소스 코드를 하나로 통합

- 저장 : 소스 저장소에 저장 (Github ,GitLab ..)

- 빌드 : 실행 파일 생성

- 테스트 : 실행 파일의 동작 여부를 점검

    * Committer .. 코드 통합 관리 담장자

 

CD 파이프라인

- 테스트

- 배포

- 운영

- 모니터링

---

CI/CD pipeline

- 빌드 : 애플리케이션을 컴파일하는 단계

- 테스트 : 코드를 테스트하는 단계, 이 단계를 자동화하여 시간과 수고를 줄일 수 있음

- 릴리스 : 애플리케이션을 리포지토리에 제공하는 단계

- 배포 : 코드를 프로덕션에 배포하는 단계

- 검증 및 컴플라이언스(Validation & Compliance) : 빌드 검증 단계는 해당 조직의 필요에 따라 결정됨

 

혹은

플래닝 -> 코드 -> 빌드 -> 테스트 -> 릴리스 -> 디플로이 -> 오퍼레이트 -> 모니터

이렇게 구성되기도 함