개발 프로세스, DevOps, CI/CD, GithubAction

개발 프로세스

요구분석 및 시스템 명세서 작성 → 설계 → 구현 → 테스트 → 배포 및 유지보수

 

전통적인 개발 프로세스, Waterfall 폭포수 개발 방식

출처: 코드스테이츠 학습자료

실제 출시 기한을 정해놓고 순차적으로 단계를 진행한다. 실제로 배포되어 유저에게 제공되는 시간이 오래 걸린다. 또한 실제 디자인 또는 개발 화면을 볼 수 있는 것은 꽤 많은 단계를 지나온 시점이기 때문에 버그나 수정 사항이 생기면 다시 처음으로 돌아가야 하므로 비용과 시간 등이 소요된다. 따라서 소프트웨어의 신뢰성 및 안정성을 보장하기가 힘들며, 배포된 후에도 많은 버그가 있을 수 있다.

 

모던 개발 프로세스, Agile 애자일 방식

전통적인 개발 프로세스에서 벗어나기 위해 고안된 방식으로, 짧은 주기인 스프린트(sprint)를 기준으로 개발 사이클이 돌아가고 반복한다.
애자일은 요구사항이 변동되는 것을 당연한 것으로 간주한다. 전통적인 개발 방식이 중간에 회귀할 수 없다는 문제를 보완하였고 하루에도 여러 번 배포가 가능하다. SaaS를 개발하는데 적합하다.

Saas (Software as a Service)

출처: 코드스테이츠 학습자료

클라우드 서비스의 한 방식이다. 브라우저에 접속만 해도 새 버전을 즉시 이용할 수 있다. 애플리케이션, 서버, 가상화, 스토리지, 네트워킹까지 모두 공급자 측에서 관리하기 때문에 고객이 따로 관리할 일은 없다. 모바일 어플리케이션처럼 사용자 업데이트에 대한 걱정에서 벗어날 수 있고 하루에도 여러번 배포가 가능하다. 또한 빠른 배포 속도도 보장받을 수 있다.

 

DevOps 

Dev: 잦은 배포 및 업데이트, 새로운 기능(리소스) 제공
Ops: 프로덕션 앱의 안정성 확보, 인프라 관리, 모니터링 및 제어

전통적인 IT조직의 구조는 Dev(개발)와 Ops(운영)을 분리해왔다. 개발팀이 제품에 변화를 만들어낸다면 운영팀은 안정성을 확보해야 한다. 그래서 둘은 상충되고 갈등을 유발할 수 있다. 이는 릴리스 주기도 길어지게 한다.

둘을 합친 DevOps가 등장했다. Dev와 Ops의 합성어이다. DevOps는 자주, 빨리, 안정적으로 배포하는 것을 목표로 하고, 애자일 기반이라고 할 수 있다. DevOps는 일종의 개발 문화이다. 만약 서비스가 중단된다면 누구라도 문제점을 진단하고 시스템을 복구하여 운영할 수 있는 절차를 알고 있어야 한다. 이를 위해서 지식과 훈련, 체계적인 협업체계가 요구된다.

DevOps는 개발부터 배포까지 하나의 통합적인 프로세스로 묶는다. 사용하는 툴과 시스템을 표준화하고 작업들을 자동화한다. 코드 통합, 테스트, 배포 과정을 자동화한다. 이들은 지속적으로 유지되어야 하는데, 지속적 통합 및 배포(CI/CD)라고 하며 DevOps의 핵심 원칙이라고도 할 수 있다. 잘 구축된 CI/CD는 어플리케이션의 배포시간을 크게 단축시킨다.

 

CI(Continuous Integration) 지속적 통합

개발자를 위한 자동화 프로세스이다. Code - Build - Test 단계이다. 

Code: 개발자가 코드를 원격저장소에 push하는 단계
Build: 원격저장소로부터 코드를 가져와 유닛테스트 후 빌드하는 단계
Test: 빌드 결과물이 다른 컴포넌트와 잘 통합이 되는지 확인하는 단계

개발자는 잦게 push하고 PR을 하고 머지를 한다. 이 과정에서 버그 발견, 빌드 성공/오류 확인, 결과물 빠른 전달, 지속적인 배포가 가능해진다. 지속적 통합을 통해 자주 합치고 자주 테스트 할 수  있다.

 

CD(Continuous Delivery/Deployment)

지속적인 서비스 제공과 지속적 배포는 상호교환적으로 사용되는 용어이다. Release - Deploy - Operate 단계가 있다.

Release: 배포 가능한 소프트웨어 패키지를 작성한다.
Deploy: 프로비저닝을 실행하고 서비스를 사용자에게 노출시킨다. 실질적인 배포부분이다.
Operate: 서비스 현황을 파악하고 실질적으로 발생할 수 있는 문제를 감지한다.

이전에는 배포 자체가 상당히 오래걸리고 힘든 일이었다고 한다. 서버를 전부 재시작하거나 일부 기능을 제공하지 못하는 경우도 있었다. 이는 지속적인 서비스 제공을 방해한다. 요즘은 지속적인 서비스 제공과 고객으로부터 피드백을 빠르게 받기 위해서라도 릴리스만 잘 기록해두고 바로바로 배포하곤 한다.

지속적 배포의 가장 흔한 케이스가 Github Page이다. 디렉토리에 정해진 방식에 따라 잘 커밋만 하면 Github Page가 알아서 index.html파일과 디렉토리 파일들을 잘 번들링하여 Github Page 서버에 업로드한다.