개발프로세스
- 요구분석 및 시스템 명세 작성 : 문제 분석, 개발할 기능과 목표 등을 정의하는 단게입니다.
- 설계 : 정의한 기능을 실제로 수행하기 위한 방법을 논리적으로 결정합니다.
👇🏻 아래 구현단계부터 실제 개발에 착수합니다.
- 구현 : 문제해결방법을 프로그래밍 언어를 사용해 실제 프로그램으로 작성합니다. 이때 구조화 프로그래밍과 모듈러 프로그래밍 기법으로 나뉩니다.
- 테스트 : 개발한 시스템이 요구사항을 만족하는 지 검사하고 평가하며 미처 발견못한 오류를 발견합니다.
- 배포 및 유지 보수 : 배포 후의 모든 활동을 말합니다.
전통적인 개발 프로세스, 워터폴 방식
한방향으로만 프로세스가 진행되는 개발과정을 뜻합니다. 유지 보수까지 끝나면 다 시 처음으로 돌아가 시작하는 것이 가장 기본적입니다.
실제 출시 기한을 정해놓고 순차적으로 진행시켜 어플리케이션을 완성해 배포하므로 실제로 배포되어 전달하기까지 오래걸리고, 시각적으로 확인할 수 있는 단게에서 어떤 버그나 수정사항이 생기면 다시 처음으로 돌아가야하므로 많은 에로사항이 생깁니다. 출시 시점에 신뢰성, 안정성을 보장받기 힘들며 배포 직후에도 많은 버그를 마주할 가능성이 높습니다.
이를 개선하기위해 테스트 단게에 다양한 테스들을 도입합니다.
- 시스템테스트 : 최종적으로 완성된 시그템이 요구사항을 만족하는지 확인하고 불만족시 다시 처음 단계로 돌아갑니다.
- 알파테스트 : 완전히 개발된 시스템을 개발현장에서 비공개로 테스트합니다.
- 베타테스트 : 실제 고객의 환경에서 수행되는 테스트로, 미리 선별된 유저들이 사용하고 에러나 버그가 발견되면 수정하는 식으로 진행됩니다.
모던개발 프로세스, 애자일방식
스프린트라고 불리는 짧은 주기의 개발사이클을 반복하는 것으로, 요구사항이 변할 것을 전제로 두고 있습니다. 계획에 의존하는 것보다 효율적으로 개발에 착수할 수 있고, 빠르게 문제를 해결할 수 있어 하루에도 여러번의 배포가 가능합니다. 서비스형 소프트웨어(SaaS)를 개발하는데 적합합니다.
SaaS ?
클라우드 서비스의 한 방식으로, 브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있는 서비스 방식입니다. 공급자 쪽에서 전부 관리하므로 고객이 제어하거나 관리할 부분이 없어 사용자업데이트 걱정에서 벗어날 수 있습니다. 대표적으로 Gmail이 SaaS방식으로 서비스를 제공하고 있습니다.
전통적 개발 프로세스 VS 모던 개발 프로세스
어느 정도의 규모인지, 어떤 종류인지 고려해 선택해 사용하므로 어느 것이 더 낫다고 할 수 없습니다.
DevOps
전통적으로 개발팀과 운영팀이 소프트웨어의 개발과 관리 및 유지보수를 담당해왔습니다. 개발팀이 잦은 업데이트로 변화를 만들면 운영팀은 서비스 구성의 변경을 최소화해 안정성을 확보하는데 이 과정에서 많은 갈등이 야기됩니다. 이를 개선하기 위해 DevOps 개념이 만들어졌습니다. 게봘과 운영의 합성어로 애자일 개발 프로세스를 기반으로 합니다.
문화
일종의 개발 문화로, 서비스 중단시 누구든 문제를 진단하고 복구해 운영할 수 있는 절차를 할도록 합니다. 이를 위한 기술과 지식이 제공되기 위해 훈련과 협업체계를 만드는 것이 중요하며, 실제 실무에서는 업무 분리를 위해 따로 부서를 둘 수 있습니다.
특징
개발에서 운영까지 하나의 통합된 프로세스로 묶어내고 사용하는 툴과 시스템을 표준화해 의사소통의 효율성을 확보하고 일련의 작업을 자동화합니다. 즉, 코드통합, 테스트, 배포과정의 자동화를 말합니다. 지속적으로 통합 및 배포하여 유지하는 것이 핵심원칙입니다. 이를 CI/CD라고 하며 애플리케이션의 배포시간을 단축시킵니다.
CI/CD
CI는 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미합니다. 성공적으로 구현할 경우 새 코드변경 사항이 정기적으로 빌드, 테스트되어 공유 리포지토리에 통합되므로 여러 개발자가 동시에 개발할 경우의 충돌문제를 해결할 수 있습니다.
CD는 지속적인 서비스제공 및 지속적인 배포를 의미합니다. 두가지 의미가 상호 교환적으로 사용되며 모두 파이프라인의 추가 단게에 대한 자동화를 뜻합니다. 혹은 얼마나 많은 자동화가 이루어지는 지를 설명하는 별도의 용어로 사용되기도 합니다.
CI/CD 단계
지속적인 통합(CI)
개발자를 위한 자동화 프로세스입니다.
- Code : 개발자가 코드를 원격 코드저장소(깃헙)에 push
- Build : 코드를 가져와 유닛 테스트 후 빌드
- Test : 빌드 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정
이 과정에서 개발자는 코드를 잦게 원격저장소에 push하고, 빌드를 확인하고 통합테스트를 통해 개선방향을 찾습니다. 지속적인 통합과정으로 버그를 일찍 발견하고, 테스트 완료된 코드를 빠르게 전달할 수 있고 지속적인 배포가 가능해집니다.
지속적 통합은 모든 코드 변화를 하나의 리포지토리에서 관리하는 데서 시작합니다. 모든 개발팀이 확인 할 수 있어 투명하게 문제점을 파익할 수 있습니다. 잦은 풀 리퀘스트와 머지로 자주 통합합니다.
지속적 통합으로 보안이슈, 에러 등을 쉽게 파악할 수 있어 빠르게 개선할 수 있습니다.
지속적 배포(CD)
지속적인 서비스 제공, 지속적인 배포를 의미합니다.
- Release : 배포 가능한 소프트웨어 패키지를 작성
- Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출(실질적 배포)
- Operate : 서비스 현황을 파악하고 문제를 감지
코드 변경사항의 병합 ~ 프로덕션에 적합한 빌드제공까지의 단계로, 테스트 자동화와 코드 배포 자동화가 포함됩니다.
최근 클라우드 기술 발전으로 지속적 통합과 배포가 CI/CD 하나로 묶어 다루는 경우가 증가하고 있습니다.
영역
지속적 통합 및 지속적 제공의 구축 사례만을 지칭하기도 하고, 지속적 통합, 제공, 배포라는 3가지 사례를 모두 의미할 수 있습니다. 파이프라인으로 표현되는 실제 프로세스를 의미하고 개발에 지속적 자동화와 모니터링을 추가하는 것을 의미합니다.
CI/CD 파이프라인
배포자동화
한번의 클릭이나 명령어 입력으로 전체 배포과정을 자동으로 진행하는 것을 말합니다. 수동적이고 반복적인 배포과정을 자동화해 시간을 절약하고 사람이 수동적으로 배포시 생기는 실수들을 방지할 수 있습니다.
CI/CD 파이프라인
수업이 진행되는 배포과정을 자동화시키는 방법을 말합니다.
개발자가 코드를 원격저장소에 올리면, 코드가 빌드 및 테스트와 릴리즈를 거쳐 배포서버로 전달됩니다. 배포서버에 도달된 코드는 애플리케이션 서버로 최종 배포되면 결과물을 유저가 직접 확인합니다. 여기서 코드가 빌드되면서 최종 배포시까지의 단계를 자동화단계로 만드는데 이것을 파이프라인을 구축한다고 합니다.
기본단계와 수행작업
파이프라인은 전체 배포과정을 여러 단계로 분리해 각 단게가 순차적으로 실행되며 주어진 작업을 수행합니다.
- Source : 원격 저장소에 관리되는 소스 코드에 변경사항이 일어날 경우 감지하고 다음 단게로 전달하는 작업을 수행
- Build : 전달받은 코드를 컴파일, 빌드, 태스트하여 가공한 결과물을 다음 단게로 전달하는 작업을 수행
- Deploy : 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행
구성요소 및 장점
빌드, 테스트, 릴리스, 배포, 규정준수 및 유효성 검사로 이루어져 있으며, 실무에서 반복적으로 수행되어 자동화 단계로 만듭니다.
Github Action
깃헙이 공식적으로 제공하는 파이프라인을 자동화할 수 있는 CI/CD 플랫폼입니다. 레포지토리에서 바로 소프트웨어 개발 워크플로우(하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상머신 또는 컨테이너 내부에서 실행)를 자동화, 사용자 지정 및 실행할 수 있게 합니다.
워크플로는 .yml(yaml)파일에 의해 구성되며, 기능에 따라 여러개의 워크플로를 만들 수도 있습니다. .github/workflows디렉토리 아래에 위치합니다.
