[Deploy]CI/CD

2023. 4. 3. 12:48ㆍ코드스테이츠/코드스테이츠S4 Chapter & Unit

개발 프로세스

개발 프로세스, 즉 소프트웨어 개발 프로세스 모델은 소프트웨어 개발 생명주기(SDLC, 이하 Software Develpment Life Cycle)을 기반으로 만들어졌다.

요구분석 및 시스템 명세 작성

문제분석단계라고도 하며, 개발할 소프트웨어의 기능과 제약조건, 목표 등을 사용자와 함께 정확히 정의하는 단계입니다. 개발하고자 하는 소프트웨어의 성격을 정확히 이해하여 이를 토대로 개발 방법과 필요한 자원 및 예산 예측 후 요구명세를 작성합니다.

설계

설계단계에서는 앞서 정의한 기능을 실제로 수행하기 위한 방법을 논리적으로 결정합니다. 크게 시스템, 프로그램, UI(User Interface) 설계로 나뉘며, 시스템 구조설계는 시스템을 구성하는 내부 프로그램이나 모듈 간의 관계와 구조를 설계하고, 프로그램설계는 프로그램 내의 각 모듈에서의 처리 절차나 알고리즘을 설계합니다.UI(User Interface) 설계는 사용자 인터페이스 설계로, 사용자가 시스템을 사용하기 위해 보이는 부분을 설계합니다.

구현

설계 단계에서 논리적으로 결정한 문제 해결 방법 =>프로그래밍언어를 사용하여 실제 프로그램을 작성.
이때 프로그래밍 기법은 구조화 프로그래밍과 모듈러 프로그래밍 두 개로 나뉩니다.
- 구조화 프로그래밍 : 조건문, 반복문을 사용하여 프로그램을 작성하고, 순차구조, 선택구조, 반복구조의 세 가지 제어구조로 표현하며, 구조가 명확하여 정확성 검증과 테스트 및 유지보수가 쉬운 장점이 있습니다.
- 모듈러 프로그래밍 : 프로그램을 여러 개의 작은 모듈로 나누어 계층 관계로 구성하는 프로그래밍 기법으로, 모듈별로 개발과 테스트 및 유지보수 가능하며, 모듈의 재사용 가능하다는 장점이 있습니다.

테스트

테스트 단계에서는 개발한 시스템이 요구사항을 만족하는지, 실행 결과가 예상한 결과와 정확하게 맞는지를 검사하고 평가하는 일련의 과정입니다. 미처 발견하지 못한 오류를 발견할 수 있기 때문에 매우 중요한 과정입니다.

배포 및 유지보수 :

배포와 유지보수 단계는 시스템이 인수되고 설치된 후(배포) 일어나는 모든 활동을 지칭. 이후 일어나는 커스터마이징, 구현, 테스트 등 모두 이 단계에 포함되므로 소프트웨어 생명주기에서 가장 긴 기간을 차지합니다. 유지보수의 유형에는 수정형, 적응형, 완전형, 예방형 총 네 가지가 있습니다.
- 수정형 유지보수 : 사용 중에 발견한 프로그램의 오류 수정 작업을 진행합니다.
- 적응형 유지보수 : 시스템과 관련한 환경적 변화에 적응하기 위한 재조정 작업을 합니다.
- 완전형 유지보수 : 시스템의 성능을 향상하기 위한 개선 작업을 합니다.
- 예방형 유지보수 : 앞으로 발생할지 모를 변경 사항을 수용하기 위한 대비 작업을 수행합니다.

무엇을 개발할지 결정하고 요구사항들을 구현 작업에 적합하게 명확하고 조직화된 구조로 바꾸는 과정을 거쳐, 실제 개발에 착수하는 단계는 ‘구현’부터입니다. 현재 그림 상으로는 이 단계들이 계속 꼬리를 물고 도는 순환 구조로 되어 있지만, 실제 개발 환경에서는 환경에 따라 각각의 단계가 또 세밀하게 나뉘어져 있기도 하며, 각 단계가 계속해서 반복되기도 합니다.

폭포수 모델(Waterfall)

개발진행 과정이 한 방향으로만 진행되는 모델.

한 싸이클의 프로세스가 끝나기 전 까지 이전단계로 돌아가지 않는다.

장점

전체 과정의 이해가 쉽다.
현재 단계에 대한 이해가 빠르고 쉽다.
문서, 산출물의 관리와 적용이 쉽다.

단점

병행 작업이 안된다.
피드백에 대한 반복 단계가 어렵다.
테스트 단계에 발견된 중요 결함에 대한 대응이 어렵다.
고객 요구사항에 대한 상세한 반영이 어렵다

개선방법

시스템 테스트 : 모든 모듈을 통합한 후 최종적으로 완성된 시스템이 요구사항을 만족하는지 확인합니다. 요구사항을 만족하지 않는다면 다시 요구분석 단계로 돌아가 새로 개발을 하기도 합니다.
알파 테스트 : 완전히 개발된 시스템을 개발 현장에서 비공개로 테스트하는 것으로, 주문형 제품의 경우 개발진과 클라이언트 사이에서 동의가 이루어질 때까지 수행됩니다. 대기업의 경우 이 업무를 주로 하는 전문 QA팀이 존재합니다.
베타 테스트 : 고객의 실제 사용 환경에서 수행되는 테스트로, 미리 선별된 유저들이 해당 제품을 사용해 봅니다. 이 과정에서 에러나 버그가 발견되면 수정하는 식으로 진행됩니다.

애자일 모델(Agile)

전통적인 개발 프로세스 폭포수 모델(Waterfall)에서 벗어나기 위해 만들어진 프로세스 중 하나가 애자일 방식입니다.

이 방식의 가장 큰 특징은 ‘스프린트(sprint)'라고 불리는 짧은 주기의 개발 사이클을 계속해서 반복한다.

이러한 방식은 SaaS(Software as a Service, 서비스형 소프트웨어)를 개발하는 데에 적합합니다.

SaaS란?

SaaS는 클라우드 서비스의 한 방식으로, 브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있는 서비스 방식입니다. 애플리케이션부터 서버, 가상화, 스토리지, 네트워킹까지 전부 공급자 쪽에서 관리하기 때문에 고객이 제어하거나 관리할 부분이 거의 없게 됩니다. 따라서 사용자 업데이트에 대한 걱정에서 벗어나며, 하루에 여러 번의 배포도 가능합니다. 또한 빠른 배포 속도도 보장 받을 수 있습니다.

장점

프로젝트 계획에 걸리는 시간을 최소화할 수 있다.
점진적으로 테스트할 수 있어서 버그를 쉽고 빠르게 발견할 수 있다.
계획 혹은 기능에 대한 수정과 변경에 유연하다.
고객 요구사항에 대한 즉각적인 피드백에 유연하며 프로토타입 모델을 빠르게 출시할 수 있다.

단점

확정되지 않은 계획 및 요구사항으로 인한 반복적인 유지보수 작업이 많다.
고객의 요구사항 및 계획이 크게 변경되면 모델이 무너질 수 있다.
개인이 아닌 팀이 중심이 되다 보니 공통으로 해야 할 작업이 많을 수 있다. (회의, 로그 등)
반복적인 업무로 속도는 빠를 수 있으나 미흡한 기능들에 대한 대처가 필요하다.
확정되지 않은 계획으로 개발 진행 시 이해하지 못하고 진행하는 부분이 많을 수 있다.

워터폴모델 애자일모델

이런 상황에 적합	- 높은 예측 가능성과, 순차적인 프로젝트 타임라인, 사전 확정 예산이 필요한 경우 - 프로젝트 팀의 경험이 적은 경우 - 요구사항이 간단하거나, 타임라인이 긴 프로젝트를 수행하는 경우	- 고성능 소프트웨어 개발 중에서도 특히 소프트웨어 개발을 할 경우 - 고품질의 결과물과 지속적인 개선에 초점을 맞출 경우 - 프로젝트가 완벽히 수행될 때까지 결과물을 기다리는 것보다 결과물에 대해 빠른 피드백이 필요한 경우
이런 기업 및 팀에 적합	- 개발상의 변경이나 리스크에 덜 민감한 기업 및 팀 - 제한적인 시간과 자원 탓에 협업이 자유롭지 못한 고객을 둔 기업 및 팀	- IBM, 시스코, AT&T, 마이크로소프트와 같이 크고 복잡한 회사들이 프로세스를 간소화해 변화에 더욱 신속하게 대응하고자 할 때 - 고객 및 외부 관계자와 정기적으로 긴밀한 협업을 수행하는 프로젝트 팀

DevOps

Dev(개발팀): 아니!! 이거 업데이트 해야한다구요 Ops팀!!!

Ops(운영팀): 아니!! 구성을 자꾸 바꾸면 서비스의 안정성이 떨어져서 안된다구요 Dev팀!!!!

아니!!!!!!!!! 싸울거면 둘 다해 너네.

"Dev(였던 것)Ops(였던 것);;"

Dev 특성상 지속적인 업데이트와 배포를 통해 에플리케이션의 새로운 기능(리소스)를 제공하는게 주 업무이고,

Ops 특성상 서비스의 구성 변경을 최소화하여 안전성을 확보하고, 모니터링 및 제어를 하는게 주 업무이다.

그러다보니 두 부서의 특성상 상충되는 부분이 많아 갈등이 야기되기도했다.

이러한 갈등은 현대 IT 시장에는 맞지않기도 하고, 릴리즈 주기를 길어지게 만들기도 한다.

그렇기 때문에 만들어진 개념이 DevOps!

Dev 와 Ops의 합성어로 특정한 업무라던지 부서가 아닌 일종의 개발 문화입니다.

만약 서비스가 중단된다면, 누구든지 문제점을 진단하고 시스템을 복구하여 운영할 수 있는 절차를 알고 있어야합니다.

이를 위한 기술과 지식이 제공되기 위해서 훈련과 효과적인 협업체계를 마련하는 것이 매우 중요합니다.

DevOps 사례

실제 인터넷 상에서 스트리밍이나 사진과 같은 엄청난 트래픽과 다양한 사용자 환경 및 요구에 빠르게 대응하기 위해 배포가 많은 기업 중에 Devops를 활용하여 성공한 기업 들이 많습니다.

미국 최대 온라인 스트리밍 서비스를 제공하고 있는 넷플릭스(Netflex)는 2012년 기준으로 3천만 명이 넘는 가입자를 보유하며 엄청난 스트리밍 트래픽을 아마존 웹 서비스(AWS)에서 10,000여개 이상의 인스턴스를 10여명 정도의 Devops팀으로 관리하고 있습니다.
사진 SNS 서비스로 야후에 합병된 Flickr는 초당 40,000 장의 사진이 업로드 되는데 Devops를 통하여 모든 배포 및 운영을 자동화하여 하루에도 10여 번 씩 이상의 배포를 하곤 합니다.
음악 스트리밍 서비스로 최근 각광을 받고 있는 Spotify도 강력한 Devops 개발문화를 갖추고 오픈소스 도구를 활용하여 배포와 운영을 자동화하여 관리합니다.

이렇게 Devops를 통하여 새로운 기능을 시장에 보다 자주 그리고 빨리 출시할 수 있고, 장애발생시 보다 대응과 시스템의 안정성을 향상시킬 수 있음을 알 수 있습니다.

CI/CD

DevOps의 핵심 원칙이라고 해도 과언이아닌 지속적 통합 및 배포.

CI

지속적인 통합(Continuous Integration)을 의미
CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합
여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결

CD

지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미

두 용어는 상호 교환적으로 사용됩니다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 합니다.

CI/CD의 단계

지속적 통합(Continuous Integration, CI)

개발자를 위한 자동화 프로세스라고 볼 수 있으며, Code => Build => Test 단계에서 CI적용을 생각 해 볼수 있습니다.

Code : 개발자가 코드를 레포지토리에 push하는 단계이다.
Build : 레포지토리로부터 코드를 가져와서 유닛 테스트 후 빌드하는 과정.
Test : 코드 빌드의 결과물이 다른 컴포넌트와 정상적으로 merge 되는지 확인하는 과정.

Code => Build => Test 과정에서 개발자는 코드를 레포지토리에 자주 push하게 되고, 테스트 및 빌드를 통해 빌드 결과가 성공적으로 빌드됐는지 아니면 실패했는지를 확인하고 실패했다면 통합 테스트 결과를 통해 개선 방안을 찾습니다.

이러한 과정을 통해서 버그를 조기에 발견가능하고, 테스트 코드를 빠르게 전달 가능하며, 지속적인 배포가 가능해집니다.

하나의 레포지토리에서 모든 코드의 변화를 관리하기 때문에, 개발팀 전체가 코드의 변화를 확인 가능하고, 투명하게 문제점을 파악할 수 있습니다.

한마디로 개발과정 도중에 오류나 문제점을 파악가능하고, 빠르게 대처가 가능하다는게 가장 큰 장점이다.

지속적 배포(Continuous Delivery/Deployment, CD)

지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용되며, Release => Deploy => Operate 단계에서 CD적용을 생각 해 볼수 있습니다.

Release : 배포 가능한 소프트웨어 패키지를 작성.
Deploy : 프로비저닝(사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다.)을 실행하고 서비스를 사용자에게 노출합니다. 실질적인 배포 부분입니다.
Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지합니다.

지속적 배포의 경우, 코드변경 사항의 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계로, 테스트 자동화와 코드 배포 자동화가 포함됩니다.

최근에는 클라우드 기술 발전과 맞물려 지속적 통합과 지속적 배포가 빠른 속도로 진행되면서 CI/CD를 하나로 묶어서 다루는 경우가 점차 증가하고 있습니다. 예를 들어, 이전에는 배포 자체가 상당히 오래 걸리고 힘든 일이어서 배포 이전 단계에서 많은 고민을 하곤 했습니다. 서버를 전부 재시작해야 한다거나, 일부 기능을 제공하지 못하는 경우도 많았기 때문입니다. 요즘은 고객의 피드백을 빨리 받기 위해서라도, 서비스를 중단하지 않기 위해서라도 릴리즈만 잘 기록해두고 바로바로 배포하는 사례가 증가하고 있습니다.

지속적 배포의 가장 흔한 사례가 Github Page입니다. 지정해둔 디렉터리에 정해진 방식에 따라 잘 커밋하기만 하면, Github Page가 알아서 해당 index.html 파일과 해당 디렉터리에 있는 파일을 잘 번들링해서 Github Page 서버에 업로드합니다. 이렇게 자동으로 인터넷에 배포가 되었고, 주변 가족이나 친구들에게 쉽게 만든 결과물을 공유할 수 있었습니다. (틀린 부분이 있다면 빠르게 피드백도 받을 수 있었습니다.) 이전 솔로 프로젝트에서 Github Page 배포에 성공했다면, 이미 지속적 배포를 경험해봤다고 볼 수 있습니다.

정리

빠르고 즉각적인 에러 대처 및 개선

CI(Code => Build => Test)

빠른 재배포 및 지속적 배포

CD( Release => Deploy => Operate)

CI/CD => 빠르고 즉각적으로 에러에 대처하고 개선 후 호다닥 배포하면서 항상 최상의 서비스를 제공하기위함

배포 자동화

배포자동화란 클릭 혹은 명령어 입력을 통해 전체 배포과정을 자동으로 진행하는 것을 뜻합니다.

배포자동화는 왜 필요할까?

수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절약됩니다.
휴먼 에러(Human Error)를 방지할 수 있습니다. 여기서 휴먼 에러란 사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수들을 뜻합니다. 그 전에 했던 배포 과정과 비교하여 특정 과정을 생략하거나 다르게 진행하여 오류가 발생하는 것이 휴먼 에러의 예로 볼 수 있습니다.

배포 자동화를 통해 전체 배포 과정을 매번 일관되게 진행하는 구조를 설계하여 휴먼 에러 발생 가능성을 낮출 수 있습니다.

CI/CD 파이프라인

폭포수 모델과 애자일 모델에 차이를 배웠습니다. 그리고 SaaS가 애자일 모델로 개발하기 적합한 소프트웨어임도 확인했습니다.

그렇다면 이번에는 이렇게 생각해볼까요? 사용자 업데이트에 대한 걱정에서도 벗어났고, 하루에 여러 번의 배포도 가능해졌습니다. 그렇다면 어떻게 빠른 배포 속도를 보장 받을 수 있을까요? 개발자가 배포할 때마다 일일히 빌드하고 배포하는 과정을 진행하는 것은 한두 번이면 충분하겠지만, 이러한 과정이 수없이 진행된다면 일일히 이 과정을 수행하는 것이 번잡스럽고 지루할 것입니다.

그래서 이 수없이 진행되는 배포 과정을 자동화시키는 방법을 구축하게 되는데, 그것을 CI/CD 파이프라인이라고 합니다.

개발자가 코드를 원격 저장소에 올리면, 그 코드가 빌드 및 테스트와 릴리즈를 거쳐 배포 서버로 전달 됩니다.
배포 서버에 도달한 빌드된 코드는 애플리케이션 서버로 최종 배포가 완료 되고, 그 결과물을 유저가 직접 확인하게 되는 것입니다.
여기서 자동화를 꾀하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계까지입니다. 이 부분을 지속적인 통합 및 배포를 위하여 일련의 자동화 단계로 만드는데, 이것을 파이프라인을 구축한다고 표현합니다

파이프라인을 여러 단계로 분리할 때, 대표적으로 쓰이는 세 가지 단계가 존재합니다. 각 단계의 이름 및 수행하는 작업에 대해서 알아보겠습니다.

Source 단계: Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행합니다.
Build 단계: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공합니다. 또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행합니다.
Deploy 단계: Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행합니다.

CI/CD 파이프라인 구성 요소 및 장점

빌드 (소프트웨어 컴파일)
테스트 (호환성 및 오류 검사)
릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
배포 (개발에서 프로덕션 환경으로의 변환)
규정 준수 및 유효성 검사

로 이루어져 있으며, 이 과정이 실무에서는 반복적인 프로세스이기 때문에 이 부분을 일련의 자동화 단계로 만든다고 볼 수 있습니다.

이렇게 구축된 파이프라인은 최신 버전의 소프트웨어 애플리케이션을 업데이트하고 제공하려는 일련의 처리 단계에 걸리는 시간을 수동으로 하는 것보다 더 빠르고 안정적이며 효과적으로 줄여주고 CI/CD 인프라와의 호환성과 효율성을 높여줍니다.

'코드스테이츠 > 코드스테이츠S4 Chapter & Unit' 카테고리의 다른 글

[Deploy] Amazon Web Service (0)	2023.03.31
[React] React Hooks (0)	2023.03.22
[React] Virtual DOM (0)	2023.03.22
[React] 번들링과 웹팩 (0)	2023.03.20
[HTML/CSS] 웹의 동작원리 (0)	2023.03.20

범이의 코딩의 코짜 배우기