개발 프로세스, CI/CD

Rosevillage·2023년 4월 3일

개발 프로세스

개발 프로세스는 소프트웨어 개발 생명주기(SDLC, Software Development Life Cycle)을 기반으로 만들어 졌으며, SDLC는 다음과 같은 단계를 가진다.

  • 요구분석 : 문제분석 단계 라고도 불리며, 개발할 소프트웨어의 기능과 제약조건, 목표등을 정의하고, 개발 방법과 필요 자원 및 예산 측정 후 요구명세를 작성한다.

  • 설계 : 전 단계에서 정의한 기능 구현을 위한 방법을 논리적으로 결정하며, 크게 시스템(내부 프로그램이나 모듈간의 관계나 구조), 프로그램(프로그램내의 각 모듈에서의 처리 절차나 알고리즘), UI(사용자에게 보이는 부분) 설계로 나뉜다.

  • 구현 : 설계 단계에서 결정한 방법을 실제 프로그램으로 작성 크게 두가지 방식이 존재한다.

    • 구조화 프로그래밍 : 조건문, 반복문을 사용하여 프로그램을 작성하고, 순차구조, 선택구조, 반복구조의 세 가지 제어구조로 표현해 구조가 명확하여 정확성 검증과 테스트 및 유지보수가 쉽다.
    • 모듈러 프로그래밍 : 프로그램을 여러 개의 작은 모듈로 나누어 계층 관계로 구성, 모듈별로 개발과 테스트 및 유지보수가 가능하고, 작성한 모듈을 재사용 할 수 있다.
  • 테스트 : 개발한 시스템이 요구사항을 만족하는지, 실행 결과가 예상한 결과와 정확하게 맞는지를 검사하고 평가한다.

  • 배포 및 유지보수 : 시스템이 인수되고 설치된 후(배포) 일어나는 모든 활동을 의미하며, 이후 일어나는 커스터마이징, 구현, 테스트 등을 포함하기 때문에 SDLC에서 가장 긴 기간을 차지한다.

    • 수정형 유지보수 : 사용 중에 발견한 프로그램의 오류 수정 작업을 진행
    • 적응형 유지보수 : 시스템과 관련한 환경적 변화에 적응하기 위한 재조정 작업
    • 완전형 유지보수 : 시스템의 성능을 향상하기 위한 개선 작업
    • 예방형 유지보수 : 앞으로 발생할지 모를 변경 사항을 수용하기 위한 대비 작업을 수행

전통적인 개발 프로세스, 모던 개발 프로세스

전통적인 개발 프로세스

워터폴(Waterfall) 방식이라고도 부르며, 단방향으로만 진행되는 개발 과정을 뜻한다.
마지막 단계인 유지보수 단계가 끝나면 다시 처음으로 돌아가는 방식으로 요구사항 수정이나, 버그 수정이 용이하지 못하기 때문에 안정성 개선을 위해 테스트 단계에 다양한 테스트들을 도입하기도 한다.

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

모던 개발 프로세스

애자일(Agile) 방식이라고도 부르며, 스프린트라는 짧은 주기의 개발 사이클을 계속 반복하는 방식으로 이루어 진다.
요구사항이 변하는것을 염두해두는 방식이기 때문에 애자일 방식을 적절히 사용하면 하루 안에도 여러번의 문제해결과 배포가 가능하다. SaaS(클라우드 서비스의 한 방식으로, 브라우저에 접속하는 것만으로 새 버전을 즉시 사용할 수 있는 서비스 방식)를 개발하는데에 적합하다.

워터폴, 애자일 장단점

워터폴애자일
장점-프로세스가 길고 순서가 잡혀 있으므로 팀의 규모에 상관 없이 따르기 쉽다
-개발 주기가 정해져 있으므로 새로운 프로젝트를 안정적으로 시작 가능
-요구 사항이 확정되어 있으므로 프로젝트를 실행하기 수월
-프로젝트의 전 과정에 필요한 예산 및 자원이 초기에 확정되어 예상 결과와 리스크를 통제하기 훨씬 쉬움
-빠르면서 유연한 개발 과정
-짧고 반복적인 스프린트로 구성되어 있어 결함을 빠르게 인지하고 수정 가능
-짧은 반복 과정으로 개발 과정 중에 신속히 제품 변경 가능
단점-앞 단계가 완성되지 않으면 다음 단계로 넘어갈 수 없어 개발 속도가 느리고 유연성이 떨어짐
-개발 요구 사항이 초기에 확정되므로 변경이 자유롭지 못함
-스프린트에 대한 경험이 있으며 빠른 반복 작업에 익숙한 스크럼 마스터가 필요
-고객이 수많은 변경 사항을 검토해야만 하는 번거로움 발생
-팀원이 잘 조직되어 있지 않거나 자립성이 떨어지는 경우 순탄한 진행 어려움

DevOps

애자일 프로세스를 기반으로하는 개발 문화로 소프트웨어를 빠르고 안정적으로 배포하는 것을 목표로 한다.

개발(Development), 운영(Operations) 까지 하나의 통합 프로세스로 묶고, 툴과 시스템을 표준화하여 의사소통의 효율성을 확보하고, 일련의 작업들을 자동화 즉 코드 통합, 테스트, 배포과정을 자동화 한다.
자동화 된 부분을 지속적으로 유지시키는 것을 지속적 통합 및 배포(CI/CD)라고 한다.

CI/CD

일반적인 앱의 개발 및 유지보수 단계는 다음과 같으며, plan을 제외한 나머지 단계를 CI/CD에 따라 구분 시킬 수 있다.

지속적 통합 (CI, Continuous Integration)

앱에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합된다.
다수의 개발자가 동시에 개발을 진행할 때 생길수 있는 충돌 문제를 해결할 수 있으며, Code-Bulid-Test 단계를 자동화 할 수 있다.

  • code : 개발단계에 작성한 코드를 원격 저장소(repository)에 push하는 단계
  • build : 원격 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
  • test : 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정

CI는 모든 코드 변화를 하나의 리포지토리에서 관리하는 것 부터 시작한다. 모든 개발팀이 코드의 변화를 확인할 수 있기 때문에, 투명하게 문제점을 파악할 수 있으며, 잦은 pull request와 merge로 코드를 통합한다. CI를 통해 개발팀은 각자 개발한 코드를 이른 시점에 자주 합치고, 테스트 해볼 수 있다.

보안 이슈, 에러 등이 쉽게 파악되기 때문에 해당 이슈를 빠르게 개선할 수 있으며, 코드를 merge 하기 전에 이미 빌드/테스트 오류를 확인했기 때문에 효율적으로 개발할 수 있게 된다.

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

지속적인 서비스 제공(Continuous Delivery) 혹은 지속적인 배포(Continuous Deployment)로 불리며, 서로 상호 교환적으로 사용되고, Release - Deploy - Operate 단계를 자동화 할 수 있다.

  • release : 배포 가능한 소프트웨어 패키지 작성
  • deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출(실질적인 배포)
  • operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지

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

CD를 완료하면 프로덕션 준비가 완료된 빌드를 리포지토리에 자동으로 배포할 수 있기 때문에 운영팀이 빠르고 손쉽게 앱을 프로덕션으로 배포할 수 있다.

최근에는 클라우드 기술 발전과 맞물려 지속적 통합과 지속적 배포가 빠른 속도로 진행되면서 CI/CD를 하나로 묶어서 다루는 경우가 증가하고 있다.

CI/CD 파이프라인

CI/CD에서 배포가 자동화되는 방법을 의미한다.
코드 빌드부터 배포까지의 단계를 지속적으로 통합/배포 하기 위해 일련의 자동화 단계를 만드는데, 이것을 파이프라인을 구축한다고 표현한다.

배포에서 파이프라인은 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻하며, 전체 배포 과정을 여러 단계로 분리한다. 크게 3가지 단계로 분리한다.

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

각 단계는 순차적으로 실행되고, 각 단계마다 주어진 작업들을 수행한다.

0개의 댓글