[이런저런] 제한된 조건에서 노력을 해본 잡담

이런저런1

회사에서 새로운 걸 도입해 보려고 애를 쓴 하루였습니다. 개발 중인 어떤 서비스가 있습니다. 이 프로젝트를 개발하면서 현재 운영 서버를 이관해야 하는 상황이 생겼습니다. 정확하게는 기존 운영 서버를 꾸미기 개념으로 남겨두고 새 장비에 운용 서버를 새로 셋업 하는 미션이었습니다.

이런저런2

어느 정도 이관에 관한 내용을 알고 있어서 빌드 배포 환경을 제한적으로 구성 해두고 사용하였습니다. 여태 사용한 장비에서 프런트는 배포 브렌치 기준으로 병합, 커밋 즉 변경 점이 발생하면 웹 훅을 사용하여 젠킨스를 물려서 자동 빌드 배포되게 하여 사용 중이었습니다. 백엔드는 사람이 직접 빌드 -> 배포까지 진행하고 있었습니다.

이런저런3

이번 장비에 신규로 셋업 하면서 gitea의 릴리즈 기능을 사용해 보았습니다. 처음부터 조금 난관이었는데 gitea 워커에서 바로 젠킨스를 호출하면 쉽게 끝났겠지만, 내부적인 이슈로 그건 불가능해서 머리를 굴려 보던 중 젠킨스의 웹 훅 URL을 열어서 릴리즈 태그를 리퀘스트 바디로 받아서 사용하는 방법을 채택하였습니다. 이를 가능하게 해준 건 Generic Webhook Trigger Plugin였습니다.

이런저런4

gitea의 릴리즈를 사용하게 된 건 운영 서버의 브렌치를 관리하기 이전에 현재 회사 내부에서 요구 사항이 도메인은 실 서버(운영-라이브)지만 아직은 영업 단계이고 그렇기 때문에 특별한 버전으로 배포를 원하는 일이 잦을 것으로 판단했습니다. 현재 B2C로 트래픽도 잘 나오는 상황에서의 유지보수인인 라면 실서버를 바라보는 브렌치를 두고 관리하는 게 맞지만 지금 상황에서는 특수한 버전으로 잦은 변경이 클 것으로 판단했고 이 구조를 B2C에서 사용해도 무리 없겠다고 생각했습니다.

이런저런5

그래서 이제는 릴리즈 기능을 사용해서 특정 브렌치로 릴리즈하면 해당 버전으로 빌드-배포가 진행되고 별다른 요구 사항이 없다면 운영 서버 브렌치를 두고 배포가 필요할 때 해당 브렌치를 릴리즈하면 되는 구조가 되었습니다.

이런저런6

"결국 Jenkins에서 특정 브랜치의 현재 코드를 빌드해 배포하는 것과 무엇이 다른가?”라는 생각도 들었습니다. 실제로 빌드와 배포 과정 자체만 놓고 보면 큰 차이는 없습니다.

차이는 배포 대상을 관리하는 방식에 있습니다. 브랜치 기반 배포에서는 배포 시점의 브랜치 상태를 기준으로 하지만, Release 기반에서는 해당 시점의 코드를 하나의 버전으로 명시하고 Tag로 고정합니다.

덕분에 현재 운영 서버에 어떤 버전이 배포되어 있는지 보다 명확하게 확인할 수 있고, 문제가 발생했을 때 이전에 배포했던 버전을 찾거나 다시 배포하는 과정도 단순해집니다. 또한 Release note와 함께 변경사항을 관리할 수 있어 배포 이력을 확인하기도 쉬워졌습니다.

결국 기존의 “특정 브랜치의 현재 상태를 배포한다”는 방식에서 “특정 시점의 코드를 하나의 버전으로 정의하고 그 버전을 배포한다”는 방식으로 변경한 것이 가장 큰 차이 같습니다.

이런저런 6

그리고 노티를 해주는 기능이 있으면 좋을 것 같아서 플로우 업무툴 API를 붙여서 젠킨스 빌드 성공/실패 과정을 게시글로 누적시키는 부분까지 자동화 해두고 되돌아보니 제한된 환경에서 할 만큼 한 거 같아서 뿌듯합니다. 다음 주 출근해서는 개선점 있는지 확인해 보고 동료들에게 공유를 해야겠습니다.

ragnarlog.out();