사전지식
staging: 실제 유저에게 배포되어 서비스 되는 단계인Production의 전 단계 서버를 의미함. 실제 유저에게 배포 전 테스트 용도로 사용
Build: 인간이 읽을 수 있는 소스코드를 프로그램 실행 시 컴퓨터가 읽을 수 있게 필요한 모든 것을 준비하는 작업(pre-processing, compiling, converting data files, running automated tests, packaging 등)
소프트웨어 빌드의 가장 중요한 단계 중 하나는 소스코드 파일을 실행코드로 변환하는 컴파일 프로세싱 단계이며, python과 JS 같은 interpreted language들은 컴파일 단계가 없기 때문에 빌드하는 과정이 뚜렷하지 않다는 특징이 있음.
그래서 파이썬이나 JS에서 빌드는 대부분 dependency와 라이브러리 설치가 대부분을 차지한다는 것.
하지만 이와 달리, JAVA나 C/C++같은 컴파일 언어들에서는 명확한 빌드 단계가 존재하여 그 중간 컴파일 과정을 개발자들이 직관적으로 확인할 수 있음.
개발자가 하는 일들 - 개발부터 배포까지
개발자는 코딩 이외에도 테스트, 배포 등의 다양한 업무들이 필요한 직업
EX)개발자가 하나의 기능이 완료된 후에는 자신의 코드가 제대로 작동하는지 확인하기 위해 테스트를 진행해야 함.
- 자신의
feature branch에서 Unit Test를 실행 - PR을 거쳐
develop branch에 머지 - 다시
develop branch에서 Unit Test를 실행 3번 과정 통과 시이를Staging서버에 배포해야 함
각 개발팀마다 배포 과정이 상이하지만, 일반적으로 Staging (1)서버에 직접 접속 후 새로운 코드를 pull로 내려받고, (2)빌드 명령어 실행해 빌드 과정을 거친 후 (3)애플리케이션 서버를 실행시키는 과정을 거쳐 배포를 완료
이러한 배포 과정에서 만일 빌드 시간이 오래 걸리면, 최종적으로 배포 과정에 드는 시간이 길어지게 되며, 특히 배포해야 하는 서버의 수가 여러개라 한다면 소요시간은 더욱 증가하게 될 것입니다.
Staging에서 배포가 끝난 후에는 더 복잡한 절차들이 남아있습니다.
unit test 만으로는 시스템 전체를 온전히 테스트 하기에 부족
-> 더 심화된 테스트 과정인 integration test와 E2E test를 진행
이러한 테스트들은 프로덕션과 최대한 동일환경을 구축한 후 진행되어야 합니다.
따라서 테스팅을 위한 제반 사항을 setup하는데 뿐만 아니라 실행하는 과정도 unit test보다 더 많은 노력이 필요할 것
Staging에서 모든 테스트가 완료되면 이제 Production 배포만 남게 됨
일반적으로 Staging 배포보다 더 시간이 들어감
Staging 환경보다 Production환경이 더 복잡하고 규모가 클 수 밖에 없기 때문
Production 배포까지의 과정이 한 번에 진행되지 않는다는 점이 많은 개발자들의 발목을 붙잡음
=> 테스트 중 대부분의 경우에서 예상치 못한 버그나 오류들이 자주 발견되기 때문
그 즉시 개발자는 발견한 오류나 버그를 수정해야 하고, 처음으로 돌아가 테스트부터 모든 배포 과정을 다시 밟아야 하는 수고가 동반됨
개발자의 생산성을 높일 수 있는 방법
개발부터 테스트, 그리고 배포까지의 과정은 쉽지 않은 과정
굉장히 반복적이고 메뉴얼적인 과정
Problem : 이러한 과정들이 개발자의 생산성을 낮춘다는 것
개발자의 시간은 새로운 기능들을 구현하고 시스템을 확장시키는데 쓰이는 게 가장 이상적
하지만, 현실은 많은 테스트와 배포를 반복하는 과정에 개발자들이 많이 뺏기게 됨
목적 : 많은 기업들과 개발자들이 어떻게 하면 테스트와 배포 같은 수동적이고 반복적이면서 비생산적인 업무를 최대한 줄이고, 그 시간에 개발을 더 할 수 있을지를 고민
자동화
Unit test, Integration Test, E2E Test 등의 테스트 과정과 모든 배포 과정을 굳이 사람이 직접 실행할 필요 없이 자동으로 실행되도록 하고, 문제가 생겼을 때 자동으로 알려주는 시스템을 구축해서 개발자 대신 모든 과정을 자동으로 진행되도록 하는 시스템, 즉 개발 환경 자동화를 통해서 개발자의 생산성을 높이게 됨
이러한 개발환경자동화 과정이 바로 CICD입니다.
Continuous Integration / Continuous Deplyment 의 약자인 CICD를 통해서 개발자가 최대한 실제 개발에만 신경쓰고 나머지 과정들은 자동으로 이루어질 수 있도록 해서 개발자의 생산성을 최대한으로 높일 수 있도록 함.
빈번하고 신속한 배포를 위하여
CICD 사용 전 : 모든 배포 과정이 쉽지 않아 대부분의 기업에서는 정해진 주기에만 배포 실행
CICD의 혜택 : 배포를 더 빨리, 그리고 더 자주할 수 있게 됨(생산성의 향상)
CICD 기능
- 개발자가 기능 구현을 하고, 코드를 푸쉬하는 순간부터 자동으로 테스트와 배포 과정이 이루어지므로 더 빠르게 더 자주 배포가 가능해짐 => 사람의 공수가 들지 않기 때문에, 테스트부터 배포과정을 굳이 정해진 주기에만 실행할 이유가 없어짐
2, 모든 커밋마다 테스트를 자동으로 실행하고 배포까지 한번에 할 수 있도록 함
테스트만 촘촘하게 구현이 잘 되어 있다면 굳이 정해진 주기에 한 번에 배포할 필요가 없이, 개별 기능들이 커밋될 때마다 바로 CICD 시스템을 통해 자동으로 테스트되고 배포될 수 있음 > CICD 시스템을 잘 구축해놓은 기업들은 하루에도 여러번 배포가 가능
CICD 개념 및 동작 원리
Continuous Integration / Continuous Deployment의 약자
지속적인 통합과 지속적인 배포 :Continuous, 즉 지속적이라는 단어는 자동화를 통한 지속을 이야기함.
CICD 시스템은 빌드, 테스트, 그리고 배포를 자동화 함으로서 개발자의 생산성을 높이고 배포를 더 빠르게 그리고 더 자주 할 수 있도록 함
이렇듯 더 빠르고 더 자주하는 배포를 바로 지속적인 배포라고 표현
CICD = CI(Continuous Integration) + CD(Continuous Deployment)
Continuous Integration(CI)
AKA. 지속적인 통합
개발자들이 작업한 코드가 통합되어 하나로 합쳐지는 것. 즉, GIT 환경에서 개발자들이 구현한 코드를 담고 있는 feature branch들이 develop branch에 머지되어 스테이징 서버에 배포 (혹은 실제 서버에 배포되지 않더라도 배포 될 수 있는 package나 argifact 형태로 생성)되는 것을 의미
개발자가 검색 기능 구현할 때
1. 검색 기능을 작업할 feature branch인feature/search브랜치 생성
2. 검색 기능을 구현한 후feature/search브랜치에 커밋
3. 문제가 없는지 확인하기 위해 (빌드 후) unit test 실행
4. unit test가 문제 없이 모두 통과하면 (PR리뷰 거친 후) develop 브랜치에 머지한다.
5. develop 브랜치에 머지된 후 develop 브랜치에서 다시 unit test를 실행하여 develop 브랜치에 머지 후 버그나 이상이 없음을 확인
CI는 바로 위 과정 중 3번에서 4번까지의 과정 자동화하여, 개발자가 개발을 끝내고 커밋하는 순간 테스트와 머지까지 자동으로 신속하게 이루어지게 하는 것을 의미
빌드부터 테스트, 그리고 develop 브랜치까지 merge 되는 과정이 자동화되었기 때문에, 개발자가 코드를 커밋하고 푸쉬하는 만큼 지체없이 바로 테스트와 merge가 (하루에도 여러번) 지속적으로 이루어질 수 있음
Continuous Deployment(CD)
AKA. 지속적인 배포
CI 다음 부분들이 자동화되는 것(develop 브랜치에 머지된 후 실제 production 서버에까지 배포하는 과정)
실제 Production 서버까지 배포가 완료되기 위해서는 많은 테스트들이 필요
1. Staging 서버에서 최신 코드를 배포한다.
2. Staging 서버에서 다음과 같은 다양한 테스트를 실행하여 production에 배포가 될 수 있을지를 판단 => Integration Test - E2E(End-To-End) Test - 그 외 Load Test등 필요한 테스트들
3. 모든 테스트가 통과하면 Production 서버에 배포하고 master(혹은 main)브랜치에 merge함
Continuous Deployment는 위 과정들을 자동화, 개발자가 개발을 끝내고 커밋 및 푸쉬를 하면 그대로 모든 테스트를 자동으로 거치고 바로 production 배포까지 완료되는 것을 이야기 함
CI와 CD까지 구축되고 나면, 개발자는 개발에만 신경쓸 수 있는 개발 환경이 구축됨.
CD의 다른 의미
CICD의 CD는 Continuous Delivery라는 의미를 가질 수도 있음
차이 : production 배포까지 모두 100% 자동으로 이루어지는지, 사람의 승인이 필요한지
Continuous Delivery
Continuous Deployment : 사람의 승인이 필요
production 배포가 모두 자동화되기 위해서는 테스트의 자동화가 정말 잘 구축되어 있어야 함.
그래서 대부분의 회사는 production 배포 전 사람이 직접 실행하는 테스트를 마지막으로 거침
다양한 CICD 플렛폼
CICD 중요성이 많이 대두되고 있기 때문에 CICD 구축을 도와주는 CICD 플랫폼들도 매우 다양해지고 있음
예전에는 CICD 시스템을 구축하기 위해 전담 엔지니어가 필요했으나, 요즘은 간단한 설정만으로 기본적인 CICD를 쉽게 구현할 수 있음
ex) Jenkins, Travis CI, Circle CI...
