Jenkins를 이용한 배포 자동화

Jenkins는 무엇인가?

젠킨스(Jenkins)는 소프트웨어 개발 시 지속적 통합(continuous integration) 서비스를 제공하는 툴이다. 다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유 영역에 있는 Git 등의 저장소에 빈번히 업로드함으로써 지속적 통합이 가능하도록 해 준다. MIT 라이선스를 따른다.

 

왜 Jenkins를 사용하는가?

저는 개인적으로 CI/CD툴 중에서는 젠킨스를 가장 선호합니다. 주로 젠킨스를 사용하였기에 익숙하고 편한 것도 이유가 될 수 있지만 플러그인을 통해서 확장이 가능하고 스케줄러 등 시스템적으로 필요한 기능들 역시 젠킨스에서 기본 제공을 해주는 덕분에 서버 상태 체크나 혹은 자동 배포 등 여러 방면에서 활용할 수 있기 때문에 젠킨스를 사용합니다.

 

Jenkins 어디까지 활용할 수 있을까?

저는 젠킨스를 자동 배포를 위해서 주로 사용하지만 Slack을 통한 팀원들에게 메시지를 공유하거나 혹은 주기적으로 반복해야하는 업무를 젠킨스 Job으로 생성해서 관리합니다. Shell Script로 충분히 관리할 수 있지만 요즘같이 재택근무를 병행하는 환경에서는 사무실 PC에서는 스크립트가 있는데 재택근무 때 사용하는 PC에는 스크립트 파일이 없어서 난감한 경우가 생기고 제가 주기적으로 하는 업무를 자동화해서 업무 시간을 확보하고 제가 아니더라도 다른 사람이 손쉽게 해당 업무를 할 수 있도록 젠킨스를 구성해서 관리하는 편입니다.

 

그래서 귀찮은 업무를 해결한 JOB 1개와 제가 안드로이드, 아이폰 배포를 담당하고 있기에 각 환경별로 빌드, 배포, 알림까지 자동화한 JOB을 소개하려고 합니다.

 

GCP AppEngine Clear Versions

현재 저희 팀에서는 GCP 내 AppEngine 플랫폼을 사용해서 백엔드, 프론트엔드, 크론과 같은 서비스의 다양한 프로젝트를 구동하고 있습니다. 앱 엔진의 특징은 버전을 통해서 롤백이 가능하고 버전별로 접속이 가능해 동일한 환경에서 동시에 여러 버전을 테스트 및 구동할 수 있는 장점이 있습니다. 다만, 앱 엔진의 서비스에는 프로젝트 당 최대 210개의 버전을 사용할 수 있는 제한이 있는데요.

운영환경은 문제가 없지만 저희는 운영, 개발 사이에 정기배포 전 테스트 환경을 위해서 중간에 스테이징 환경이 존재합니다. 스테이징 환경은 DEV를 통해서 테스트된 Feature들이 Staging에 올라가고 Staging에서 최종 테스트를 거친 후 운영환경에 반영되는 프로세스입니다.

 

Staging은 Branch에 Mergee되는 시점에 항상 빌드를 진행하는데 스프린트에 업무에 많거나 혹은 작은 단위의 기능들이 배포될 때는 210개의 제한이 금방 꽉 찰 만큼 배포가 많이 이루어지고 있습니다.

Jenkins 관리를 제가 하고있기 때문에 주기적으로 Jenkins의 상태를 확인하고 있는데 가끔 스테이징 환경에서 배포가 에러 나는 케이스를 확인할 수 있습니다. 거의 다 210개의 버전 제한에 걸려 발생하는 에러인데요. 이걸 제가 주기적으로 확인하고 매번 버전을 지우다 보니 이것 역시 제가 업무를 하는 시간의 입무를 차지하게 되었습니다.

 

그렇기에 다음과 같은 앱엔진 버전을 최근 10개를 제외한 Version을 제외하고 삭제하는 스크립트를 작성하고 삭제를 원하는 프로젝트, 서비스를 파라미터 형태로 전달해서 동작하는 JOB을 생성했습니다.

실제 자동배포 JOB에서는 배포가 완료된 후 해당 JOB을 API Call로 실행시켜 버전을 개수를 최근 10개로 제한하는 형태로 구성했습니다.

이렇게 매개변수를 구성해서 필요한 파라미터를 받고 해당 파라미터와 같이 스크립트가 동작하는 형태입니다.

 

 

Android / IOS 빌드 및 테스트 배포

지금 제가 속한 팀에서 안드로이드, 아이폰 프로젝트를 관리하다보니 저에게는 주기적으로 아주 시간이 많이 소요되는 작업이 있습니다. 그건 바로 테스트 앱 배포와 전달인데요. 저희는 QA팀에서 QA를 진행해주시기에 개발자가 단위 테스트를 진행하고 운영에 배포되기 전 QA를 진행하고 배포됩니다. 그렇기에 안드로이드, 아이폰 소스가 변경되면 TestFlight에 빌드를 업로드하고 APK의 경우 테스트 앱이 필요한 담당자에게 매번 DM을 통해서 배포 소식을 알렸습니다. 문제는 정신이 없을 때는 배포를 걸어놓고 작업을 진행하다 보면 필요한 시점에 제대로 전달이 안되었거나 혹은 각 담당자가 배포 사실은 인지하지 못하거나 혹은 저에게 매번 APK를 요구하는 일이 빈번했습니다.

 

저희는 운영환경을 제외하고 개발, 스테이징 환경이 존재하다보니 앱 역시 운영, 개발, 스테이징 각 환경에 맞게 빌드를 해야 하고 배포하는 상황으로 안드로이드, 아이폰을 빌드하고 배포, 공유까지 진행하다 보면 기본 1시간을 훌쩍 넘어가고 배포 에러라도 발생하거나 중간에 바쁜 업무가 있다 보면 어떤 환경은 빠지고 배포되는 이슈가 있어 이 역시 JOB을 통해서 관리, Slack에 알림과 파일 업로드를 구현해서 관리하고 있습니다. 그 덕분에 앱의 배포가 필요하더라도 제가 없더라도 테스트 환경 배포에 문제가 없어지고 젠킨스를 통해서 배포 알림이 오기 때문에 제가 일일이 담당자에게 DM을 하거나 파일을 보내는 일이 없어져 아주 만족하고 있는 작업 중 하나입니다.

 

 

다음과 같이 특정 환경의 브랜치에 머지를 하게되면 빌드를 진행하고 IOS 프로젝트는 TestFlight에 업로드를 하고, 안드로이드는 테스트 APK를 배포 채널에 업로드하는 것까지가 JOB의 내용입니다.

 

기존에는 컨플루언스 문서에 매번 버전을 최신화하고 APK를 업로드하거나 각 담당자들에게 DM을 통해서 배포했는데 이렇게 배포 자동화 및 알림을 스크립트로 구성해서 사용한다면 배포 자동화뿐 아니라 제가 시간을 많이 사용하고 있는 단순한 반복 업무를 줄일 수 있습니다.

 

이 외에도 많은 팀에서는 특정 인원만 할 수 있거나 특정 인원만 알고있는 내용의 반복 업무들이 있는데요. 이런 업무들의 문제는 시간이 많이 소요되지만 원활하게 진행할 때는 티가나지 않지만 원활하게 진행되지 않는 경우 특정 담당자의 시간을 많이 소모하거나 전체적인 업무 프로세스에 영향을 주는 케이스가 있습니다.

 

제가 Jenkins를 사용하는 이유는 자동화도 있지만 제가 하고있는 지속적인 업무가 제가 휴가 혹은 퇴사를 하게 되더라도 지속적으로 유지될 수 있고 JOB에 생성된 스크립트를 보고 누구나 해당 JOB의 패치를 통해서 좀 더 나은 업무로 만들 수 있다는 점이 매력적으로 느껴집니다.

물론 Jenkins 뿐 아니라 CI/CD 툴이 아니더라도 Shell Script를 통해서도 할 수 있는 업무지만 이력이 남고 URL을 통해서 손쉽게 접근, 그리고 강력한 플러그인과 많은 레퍼런스야 말로 사용하게 되는 이유가 아닐까 싶습니다.