안녕하세요 올리브영의 POS서버를 맡고있는 개발자 Q평E평 입니다.
여러분은 운영 중인 시스템 배포를 어떻게 하고 있으신가요?
최근엔 다양한 CI/CD 도구를 사용하여 손쉽게 배포 파이프라인을 만들 수 있는데요, 이번 글에서는 저희 올리브영 셀프계산대의 TeamCity 기반 배포 파이프라인 구축 과정을 소개하려고 합니다!
걱정거리가 많았던 배포 시스템에서, 점진적으로 발전해 가는 저희 POS팀의 배포 이야기 들려드리겠습니다.
POS팀은 어떻게 배포해 왔을까?
놀랍게도 올리브영의 POS&셀프계산대 및 서버는 얼마 전까지만 하더라도 아래와 같이 수기 작업이 많은 배포 프로세스를 거쳤습니다.
- 개발자 PC에서 변경된 브랜치를
Pull후 빌드 - 빌드된 전체 파일 중에서 배포할 파일 선별
- 파일을 배포
Server: class 파일을 SFTP를 통해 수기로 옮기고 서버를 재기동POS Client: 배포될 파일을 특정한 물리 장비에 수기로 옮겨 놓으면 배포 솔루션을 통해 배포셀프계산대 Client: S3에 배포될 파일을 수기로 올려놓고 버전 파일의 정보를 수기로 변경하여 배포
지금은 어느 정도 개선되었지만, 빌드된 파일 하나를 수기로 변경하고 몇 번을 다시 확인했는지...
심각한 걱정이인 저로서는 매우 힘든 작업이었습니다.
올리브영의 현재 배포 상황
올리브영은 현재 전사적인 배포 도구로 TeamCity를 선택하여 사용하고 있습니다. 관련하여 과거 “코코리"님이 작성하신 글이 있습니다.
다행히 API 서버의 경우 올해 “IDC 물리 장비 + 기업 프레임워크”에서 “AWS 인스턴스 + Spring Boot”로 이관을 진행했습니다. 지금은 TeamCity를 통한 배포 파이프라인을 구성하여 현재는 마음 편한 배포를 하고 있습니다.
그리고 저희는 발맞추어 POS&셀프계산대도 TeamCity를 사용한 배포 파이프라인을 점진적으로 적용하기 시작합니다!
배포 프로세스 개선의 배경
현재 올리브영의 POS와 셀프계산대는 배포 프로세스가 다르므로, 모든 프로세스 개선이 완료된 셀프계산대를 기준으로 이야기를 진행하겠습니다.
1. 외부 운영 솔루션과의 의존성
Client의 기존 배포 프로세스를 변경하기 어려웠던 이유는, Bigfix라는 외부 운영 솔루션에 깊숙한 의존성을 가지고 있었기 때문입니다.
코드부터 시작하여 Bigfix를 위한 물리 장비까지 존재했고 이것에 굉장히 의존적이었습니다.
Bigfix는 스크립트를 통해 클라이언트에게 배포하기 좋은 기능을 갖추었지만, 물리 장비에 귀속되고 코드에 깊숙이 관여돼야 하므로 많은 부분 제약되었습니다.
2. 환경에 따른 휴먼에러 발생 위험성
- 환경에 의한 영향 : 개발자가 직접 PC에서 빌드하므로 배포마다 다른 개발자의 PC에서 빌드될 경우 환경에 의한 영향을 받을 수 있습니다.
- 휴먼에러 : 빌드 과정에서 개발자가 직접 빌드하거나, 파일을 옮기는 등 수기 프로세스가 존재하므로 휴먼에러의 발생 가능성이 있습니다.
3. 업데이트를 수행하는 주체가 개별 단말기
올리브영의 POS&셀프계산대는 3천 대가 넘고 장비가 항상 켜져있지 않기 때문에 Server에서 한 번에 업데이트 명령을 날릴 수 없습니다.
구조 자체가 업데이트를 Client가 요청하는 업데이트의 주체가 Client인 구조기 때문에 이 또한 고민 포인트였습니다.
다행히 셀프계산대는 POS보다 먼저 S3를 통해 빌드 파일을 받아올 수 있도록 최근에 개발하였고, TeamCity의 배포 시작점을 셀프계산대로 진행합니다!
어떻게 바꾸려고 노력했을까?
셀프계산대의 배포 프로세스에서, 개발자가 수기로 진행하는 요소들을 최대한 줄이고자 했습니다. 기존 프로세스는 다음과 같았습니다.
- 개발자가 github에서 소스의 브랜치를 Pull한다.
- 개발자가 로컬환경에서 최종 코드를 빌드한다.
- 파일을 클렌징하고, 선별한다.
- 개발자가 빌드된 파일을 압축하여 S3의 배포경로로 업로드한다.
- 개발자가 빌드버전이 명시된 JSON파일을 다운로드한다.
- 개발자가 빌드버전이 명시된 JSON파일을 변경한다.
- 개발자가 빌드버전이 명시된 JSON파일을 업로드한다.
- 셀프계산대가 실행 시, 버전파일을 읽는다.
- 업데이트가 필요한 버전이라면, S3를 통해 업데이트된 파일을 다운로드 받는다.
위 스텝 중 붉은색으로 처리된 부분이 개발자가 직접 수기로 진행하던 부분입니다.
어떻게 바뀌었을까?
아래와 같이 CI&CD 구성을 변경하기로 합니다.
- 개발자가 TeamCity 서버를 통해 빌드 명령을 보낸다.
- Build Agent가 github에서 소스를 Pull한다.
- Build Agent가 최종 코드를 빌드한다.
- (필요 시) 파일을 클렌징한다.
- AWS CLI를 통해 S3로 파일을 전송한다.
- 개발자가 TeamCity 서버를 통해 빌드버전이 명시된 JSON파일의 변경 명령을 보낸다.
- 셀프계산대가 실행 시, 버전 파일을 읽는다.
- 업데이트가 필요한 버전이라면, S3를 통해 업데이트된 파일을 다운로드 받는다.
한눈에 보아도 개발자가 수기로 작업하는 붉은색이 많이 줄었습니다.
그리고 다음과 같은 순서로 빌드 프로세스 구성을 진행했습니다.
1. AS-IS 배포 프로세스를 분석하고, CI&CD의 경계선 구분
업데이트의 주체가 Client이므로, 이에 알맞는 CI&CD의 경계선을 구분지었습니다.
2. CI&CD 각각의 프로세스를 작은 단위로 분리
스크립트 작성 및 테스트를 쉽게 할 수 있도록 전체의 프로세스를 작은 스텝으로 분해했습니다.
3. 셀프계산대의 개발 언어인 C#빌드 에이전트 리소스를 신규 발급
코코리님의 글을 보면 TeamCity의 에이전트들은 다음과 같이 1개의 TeamCity Server와 N개의 TeamCity Agent 구조를 가지고 있습니다. TeamCity Server는 TeamCity Agent에게 작업을 할당하고, 사용 가능한 리소스 기반으로 작업수행이 가능한 Agent가 그 명령을 수행하는 구조입니다.
기존에 Java용 빌드 에이전트만 존재했었고, 최대한 다른 빌드시스템에 영향을 받지 않기 위해 새로운 C# 빌드용 EC2 리소스를 새롭게 요청했습니다.
4. CI&CD 과정에 필요한 툴 사전 설치
에이전트 리소스를 할당받았다면 빌드를 위한 초기 세팅을 해주어야 합니다.
빌드 및 배포에 필요한 nuget (패키지 관리자), msbuild (빌더), jq (Json Parser) 등을 세팅 해 주었습니다.
5. Build Step 구성 및 테스트
전체 프로세스를 정리한 뒤 최대한 작은 스텝으로 나누고 이를 빌드 스텝으로 만들어 테스트를 진행하며 구성해 나아갔는데요.
위와 같이 최대한 작은 스텝인 1~5줄로 구성되는 작은 스크립트로 구성해 나가는 게 테스트에 도움이 되었습니다.
설명으로는 간단해 보이지만 사실 스텝 하나하나 검증하며 굉장히 많은 시행착오가 존재했습니다... 🥲
- 실행해 보면서 스크립트 검증을 해야 하는데 Windows 관련 빌드 사례가 많이 없어서 다수의 검증 시도
- 파라미터의 경우
Key=Value형태로 구성되는데,Key문자열에 대한 동적 할당이 어려움
6. 빌드 파일을 적용하여 QA
7. 점진적 배포 적용
최종적으로 저희의 배포 파이프라인은 다음과 같은 모습을 갖추게 되었습니다.
배포 자동화에 대한 부분이 버전이 명시된 JSON 파일을 변경하는 이유는 Client 업데이트에 대한 주체가 Server가 아닌 Client에 있기 때문입니다.
(셀프계산대는 서버의 버전이 명시된 JSON파일을 읽어 버전을 구분하고 프로그램 업데이트를 진행합니다.)
그렇기에 Client가 버전을 업데이트할 수 있도록 에이전트 서버에서 준비를 마치는 것이 CD라고 판단했습니다.
어떤 점이 좋아졌을까?
1. 빌드 환경의 자유
적용 후 가장 큰 장점은 개발자가 더 이상 각자의 PC에서 빌드하지 않음으로써 빌드환경에 신경 쓰지 않아도 된다는 점이었습니다.
2. 빌드를 위한 세팅 불필요
이제 각자 세팅해 둔 PC가 아닌 TeamCity Server에 접근하여 버튼만 누를 수 있다면 환경에 상관없이 빌드가 가능해졌습니다.
3. No more “It Works On My Machine”
“제 PC에선 잘 됐는데요?”의 변명이 사라졌습니다.
4. 빌드 시 휴먼 에러 방지
항상 같은 환경에서 같은 스크립트로 빌드가 진행되기 때문에 휴먼에러의 발생 소지가 줄어 개발자가 걱정할 필요가 없어졌습니다.
5. 배포 프로세스에 소요되는 시간 개선
기존 배포 프로세스 대비 상당한 시간적 개선이 있었는데요! 배포의 처음부터 완료까지 걸리는 시간이 기존 대비 66.8% 개선되었습니다.
6. 웹훅 알람으로 빌드&배포 결과 공유
TeamCity에는 빌드&배포 결과를 Slack 웹 훅을 통해 메신저로 보내주는 기능이 있습니다. 이로써 모든 담당자가 빌드&배포 결과를 인지할 수 있게 되었습니다.
What's Next?!
셀프계산대가 아닌 POS의 경우 외부 솔루션에 대한 의존도가 크기 때문에 아직은 완전한 배포 프로세스를 구성하지 못한점이 아쉬운 부분인데요!
완전한 배포 자동화를 이루기까지는 시간이 걸리겠지만, 사용성 좋은 시스템을 위해 빠르게 개선 해 나아갈 예정입니다!
앞으로도 이러한 개선을 통해 더욱 완성도 높은 올리브영 POS시스템을 만들어가고자 합니다. 감사합니다!
( 이 글을 빌어 많은 도움 주신 올리브영 PE팀께 감사인사를 드립니다 😄 )
