개발 프로세스의 발전
소프트웨어 개발 프로세스 모델은 소프트웨어 개발 생명주기(Software Development Life Cycle, SDLC)를 기반으로 만들어졌다.
계획, 개발, 테스트, 배포, 유지보수하는 과정을 정의하고 구조화시킨 것.
- 요구사항 수집 및 분석
- 계획
- 설계
- 개발
- 테스트
- 배포
- 유지보수
전통적인 개발 프로세스
워터폴 방식
폭포같이 한 방향으로만 프로세스가 진행되는 개발 과정을 뜻한다.
출시 기한을 정해놓고 순차적으로 프로세스를 진행시켜 애플리케이션을 완성해 배포하기 때문에 실제로 배포되어 유저에게 전달되는 시간이 오래 걸린다.
버그나 수정 사항이 생기면 다시 처음으로 돌아가 수정하기 때문에 일정과 비용 등 많은 부분에서 애로 사항이 생긴다.
이 단점들로 인해 소프트웨어의 신뢰성 및 안정성을 보장받기 힘들다.
신뢰성과 안정성을 보장하기 위해 테스트 단계에서 다양한 테스트들을 도입하기도 한다.
모던 개발 프로세스
애자일 방식
애자일 방식은 스프린트라고 불리는 짧은 주기의 개발 사이클을 계속해서 반복하는 개념.
계획에 의존하여 형식적인 절차를 끝까지 따라야 하고 중간에 뒤로 회귀할 수 없는 전통적인 개발 프로세스보다는 효율적으로 개발에 착수할 수 있다. 하루에 여러 번 배포할 수도 있다. 이러한 방식은 SaaS를 개발하는 데 적합하다.
SaaS (Software as a Service, 서비스형 소프트 웨어)
SaaS는 클라우드 서비스의 한 방식
DevOps
개발(Development) + 운영(Operations)
기존의 개발과 운영이 분리되어 있던 전통적인 접근 방식과 달리, DevOps는 개발과 운영팀 간의 협업을 강화하여 소프트웨어 제품의 개발부터 배포와 유지보수에 이르는 전체 라이프사리클을 더 빠르고 안정적으로 관리하는 것을 목표로 한다.
- 빠른 개발과 배포
- 높은 품질과 안정성: 자동화된 테스트, 지속적 통합, 지속적 전달 등의 방법을 통해 품질을 유지하고 안정적인 배포를 가능하게 한다.
- 문제 해결과 시간 단축
- 자동화
- 확장성
CI/CD
지속적인 통합(Continuous Integration) / 지속적인 배포(Continuous Delivery)
이러한 개념들은 개발 프로세스 단계마다 적용할 수 있다.
Plan - Code - Build - Test - Release - Deploy - Operate
CI
개발자를 위한 자동화 프로세스. Code - Build - Test 단계에 적용할 수 있다.
- Code: 코드를 원격 코드 저장소 (ex. github)에 push하는 단계
- Build: 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
- Test: 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는지 확인하는 단계
모든 개발팀이 코드의 변화를 확인할 수 있기 때문에, 모두가 문제점 파악 가능하다. 잦은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합한다. 이 때, 기본적인 테스트도 작동시킬 수 있다.
CD
Release - Deploy - Operate 단계에 적용할 수 있다.
- Release: 배포 가능한 소프트웨어 패키지를 작성하는 단계
- Deploy: 프로비저닝을 실행하고 서비스를 사용자에게 노출하는 단계
- Operate: 서비스 현황을 파악하고 생길 수 있는 문제를 감지하는 단계
Github Action
GitHub Actions는 Github가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼이다.
각 레포지토리마다 설정할 수 있으며, Pull Request나 push 같은 이벤트를 트리거로 GitHub 작업 워크플로우(Workflow)를 구성할 수 있다.
워크플로우는 .yml(혹은 .yaml) 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러 개의 워크플로우도로 만들 수 있다. 생성된 워크플로우는 .github/workflows 디렉토리 안에 위치하게 된다.
