입사 후 몇달간 매번 배포시마다 테스트 서버 업데이트는 직접 테스트 서버 인스턴스에 접속해서 브랜치를 받아와 업데이트를 진행하고, 프로덕션 서버 업데이트는 블루/그린 배포를 손으로 진행했었다. (직접 템플릿을 사용해 인스턴스를 생성하고 로드밸런서에 추가한 이후, 기존 인스턴스는 제거했다)
매번 이렇게 수정본을 배포하기란 너무 불편했고, 생각보다 시간이 오래걸렸다. 그래서 많이 들어온 배포 자동화를 진행하기로 했다.
배포 자동화 선택
현재 develop, master브랜치가 있었고, develop브랜치를 개발용서버에서 배포하고, master브랜치를 프로덕션 서버에 배포하고 있었다.
기능 개발시 feature브랜치를 새롭게 생성해 개발 후 develop 브랜치에 추가하고, hotfix브랜치에서 급한 수정사항들을 수정하여 master, develop브랜치에 병합하는 식으로 개발을 진행해왔다.
(gitflow를 공부하며 나름대로 세운 방식이었다.)
그래서 develop브랜치에 변경이 생길 경우, 자동으로 테스트 서버에 배포가 이루어지고, master브랜치에 변경이 생길 경우, 자동으로 프로덕션 서버에 배포가 이루어질 수 있도록 하고 싶었다.
배포 자동화의 방식은 찾아보니 aws code pipeline, github action, circleCI, travisCI 등이 있다는 것을 알게 되었다. travisCI, circleCI 를 많은 곳에서 사용하고 있는 것 같았다.
결정은 단순히, aws 크레딧이 엄청 많이 있어서 aws를 사용하여 자동 배포를 구성해보기로 했다.
code deploy, code pipeline
처음 배포자동화를 적용할 당시 서버는 javascript로 구성되어 있었기 때문에, 별도의 빌드과정이 필요하지 않았다. 그렇기에 code pipeline을 통해 브랜치에 변경을 감지하고, code deploy를 통해 원하는 인스턴스에 배포될 수 있도록 환경을 구성했다.
테스트용 서버는 중간에 잠시 중단되거나 해도 문제가 되지 않기 때문에 in-place배포를 하고, 프로덕션 서버는 블루/그린 배포가 될 수 있도록 했다.
결과
환경을 구성하고 사용해본 결과, 정말 설정하기 위한 삽질이 보상받는 기분이었다. 단순히 develop브랜치에 푸시하는 것만으로 테스트 서버가 업데이트 되고, master브랜치에 푸시하는 것만으로 프로덕션 서버가 업데이트 되었다. 🙌🏻 (진심 신세계..)
매번 인스턴스에 들어가 업데이트하거나, 새롭게 인스턴스를 만들어서 업데이트하던 과정이 사라지게 되니 확실히 업데이트도 자주 할 수 있었고, 시간이 많이 줄어들었다. 그러다보니 자연스레 업데이트를 자주할 수 있었고, 생산성이 조금 올라가지 않았나하는 생각이 들었다.
다른 서비스를 이용해보진 않았기에, 타 서비스와 비교하기는 힘들 것 같지만 마음에 들었던 점들은 여러가지가 있었다.
- aws에서 진행상황을 편하게 확인 가능하다는 점
- 롤백 기능
- 블루/그린 배포시 기존 인스턴스를 원하는 시간만큼 삭제되지 않도록 할 수 있어, 문제시 기존 인스턴스로 빠르게 변경이 가능하다는 점
- chatbot이나 SNS(simple notification service)를 통해 slack 또는 메일로 배포 과정에 대한 알림을 받아 볼 수 있다는 점
