SQLGate Build & Deploy Automation
SQLGate는 국내 2,000곳 이상의 기업과 5,000명 이상의 개인 사용자가 사용하는 국내 최고의 데이터베이스 관리 도구 입니다.
2017년, 글로벌 시장 진출을 위해 신규 합작 법인인 (주) 체커를 설립했고 글로벌 경쟁력을 확보하기 위해 SPL(Software Product Line), ALM(Application Lifecycle Management)을 지속적으로 강화하고 있습니다.
2017년에는 첫 번째 과제로 버그 및 고객 요구사항 관리를 Zendesk 기반으로 통합했습니다. 고객들은 Zendesk Support를 통해 버그, 이슈를 제출한 후 체계적으로 보고 받을 수 있게 됐고, 반복적인 질문(FAQ)와 SQLGate 사용팁 등은 Zendesk Guide 를 통해 지식 베이스를 쌓아가고 있습니다.
오늘은 두번째 과제로 진행한 새로운 SQLGate의 빌드/배포 시스템을 소개하고자 합니다.
SQLGate는 델파이 개발됐고 윈도우 기반의 MSBuild를 통해 빌드 과정이 일부 자동화 되어 있습니다.
기존 빌드 프로그램을 통해 다음 과정으로 빌드를 할 수 있습니다.
- 제품 선택
- 버전 추가 및 배포 여부 설정 ( SQLGate Product Management System DB 에서 조회 )
- MSBuild를 위한 MSBuild XML 명세파일 생성 및 설치 파일 생성을 위한 InnoSetup 스크립트 생성
- MSBuild.exe 호출
- SVN Update
- ASProtect 파일 준비
- 컴포넌트 및 메인 프로젝트 컴파일
- SQLGate.exe / SQLGateUpdater.exe 파일에 ASProtect 및 Code Signing 적용
- 설치파일 구성에 필요한 파일 및 디렉토리를 특정 경로에 복사
- InnoSetup 스크립트로 설치파일 생성
- 설치파일에 ASProtect 및 Code Signing 적용
빌드를 과정을 통해 SQLGate 설치파일이 생성되면 이를 S3에 업로드 할 수 있도록 일부 과정이 자동화 되어 있지만 몇가지 문제가 있습니다.
- SVN을 형상관리 시스템으로 쓰고 있다는 점
- 빌드를 위해서는 원격 데스크탑으로 접속해서 버튼을 여러번 눌러야 한다는 점
- 빌드 프로세스가 MSBuild에 의존적이라는 점
- Pre-Build, Build, Post-Build 같은 빌드 Phase 구성이 어렵다보니 확장성에 제한이 있다는 점
SCM(Source Code Management)를 Git 기반으로 바꾸고 전 과정을 웹 기반으로 자동화 하기 위해 새로운 아키텍처를 설계하기로 했습니다.
1. SVN to Git (GitLab)
먼저 SCM을 SVN에서 Git으로 바꾸고 회사내 다른 소스코드와 통합적으로 관리하기위해 GitLab으로 모두 이관 하기로 했습니다.
SVN to Git 이관에는 svn2git(https://github.com/nirvdrum/svn2git)을 활용해서 간단한 쉘 스크립트를 작성했습니다.
SVN 히스토리를 그대로 유지하면서 Git으로 이관해주는 SVN2Git 덕분에 대부분 몇몇 Gitlab API 호출을 통해 리포지토리를 만드는 과정 외에는 대부분 과정이 자동화되어 있어 15분이면 기존 SVN 리포지토리에서 Gitlab으로 이관이 가능했습니다.
2. 빌드 서버 구축
빌드 서버는 내부 클라우드 리소스인 지엔클라우드에 생성했습니다. 지엔클라우드(http://www.gncloud.kr/#/home)는 Private Cloud 제품으로 기업 내부에 자체적인 클라우드를 구축해주는 서비스 입니다.
체커는 현재 지엔클라우드에서 수십대의 테스트 데이터베이스 인스턴스를 운영하고 있고 몇몇 내부 시스템 및 Linux 머신들도 지엔클라우드에서 운영하고 있습니다. (비용을 상당히 줄일수있고 원하는대로 인스턴스를 생성/삭제/수정 할 수 있어 아주 좋아요!)
3. 젠킨스(Jenkins) 설치
2CPU / 2GB / Windows Server 2012 기반으로 인스턴스를 하나 생성했고 젠킨스를 설치했습니다. 윈도우는 젠킨스를 Windows Service 혹은 Tomcat + WAR 방식으로 설치 할 수 있는데, Windows Service 방식은 설치, 구동은 간단하나 Windows Batch 실행혹은 추가적인 프로세스를 실행하는데 번거로움이 있어서 Tomcat + WAR 방식으로 설치했습니다.
4. 프로젝트 구성 (1) 버전 및 다양한 빌드 옵션 구성
기존 빌드시스템을 잘 보면 빌드전에 2가지 입력값이 필요합니다. 바로 “버전”과 “빌드전 파일 삭제 여부” 인데요
버전은 말 그대로 제품의 버저닝을 몇 버전으로 할 것인가의 의미이고, 빌드전 파일 삭제 여부는 이전 빌드에 남아있던 Dcu, Bpl, DLL과 같은 빌드 산출물들을 삭제할지 여부입니다.
따라서 빌드 버튼을 누르기 전에 버전을 선택할 수 있어야하고 빌드전 파일 삭제 여부 또한 선택할 수 있어야 하는데 이는 Dynamic Parameter Plugin(https://wiki.jenkins.io/display/JENKINS/Dynamic+Parameter+Plug-in)을 통해서 구성할 수 있습니다.
Extended Choice Parameter를 선택하면 입맛대로 매개변수를 구성할 수 있습니다. 간단한 그루비 스크립트를 작성해서 서버로 부터 버전 정보를 받아오는 매개변수를 구성했습니다.
매개변수가 추가되면 Build Now 버튼이 Build with Parameters로 바뀌고 빌드 전 버전과 빌드전 파일 지우기 옵션을 선택할 수 있습니다. 이처럼 Dynamic Parameter Plugin을 사용하면 빌드전 원하는 다양한 옵션들을 정해놓고 입맛대로 빌드 환경을 구성할 수 있습니다!.
5. 프로젝트 구성 (2) 빌드 디렉토리 및 MSBuild XML 파일 명세 개선
기존에는 MSBuild XML에 너무 많은 내용이 기술되어 있었고 그 과정또한 여러 곳에서 파일들을 복사하고 이동하게 되어 있어서 가독성이 떨어졌습니다. 새 버전에서는 빌드 워크스페이스부터 MSBuild XML 파일까지 완전히 재 구성하여 추후 빌드 설정이 변경될 경우에도 편리하게 관리할 수 있도록 했습니다.
Jobs 하위에는 제품별 젠킨스 아이템이 존재하며 각 아이템 하위에는 Work와 Target 이라는 폴더가 하나씩 있습니다.
Work는 빌드에 필요한 모든 구성품을 모아놓은 디렉토리로 기존에는 여러 곳을 참조했지만 새롭게 구성한 환경에는 Work 하위로 집중화해서 여러 곳을 볼 필요 없이 Work 아래 한 곳만 보면 빌드에 모든 구성정보를 확인할 수 있습니다.
Target은 Work에서 생성해낸 최종 빌드 산출물이 보관되는 디렉토리로 최종 산출물을 InnoSetup으로 묶으면 Setup Exe가 생성되며 Exe는 빌드 버전별로 보관됩니다. 버전별 Exe는 젠킨스의 최대 빌드 보관개수에 따라서 유지되기 때문에 누적되는 Exe들 때문에 서버 디스크가 가득찰 걱정은 안해도 됩니다.
6. 프로젝트 구성 (3) Artifact Deployer 및 S3 Uploader 구성
앞서 이야기한 Target/Setup 하위에는 버전별로 Setup Exe 파일이 저장됩니다. 이는 Artifact Deployer) 플러그인(https://wiki.jenkins.io/display/JENKINS/ArtifactDeployer+Plugin을 사용하면 쉽게 구성할 수 있습니다.
또한 최종 사용자가 다운로드 받을 수 있도록 S3에 업로드 하는 기능 또한 S3 플러그인https://wiki.jenkins.io/display/JENKINS/S3+Plugin을 사용하면 간단하게 구성할 수 있습니다.
S3 버킷은 추후 변경가능성이 있어서 ${AWS_BUCKET_NAME}으로 전역 프로퍼티로 설정했습니다.
전역 환경변수는 젠킨스 관리 -> 시스템 설정 -> 전역 프로퍼티에서 할 수 있습니다.
7. 프로젝트 구성 (4) Slack 알람 구성
마지막으로 슬랙 알람 구성입니다. 슬랙 알람은 Slack 플러그인 (https://wiki.jenkins.io/display/JENKINS/Slack+Plugin)을 사용하면 쉽게 구성할 수 있습니다.
나는 빌드 성공 시, 실패 시, 불안정 시에 알람이 가도록 했고 알람시에 해당 제품 이름과 버전정보가 표시되도록 했습니다.
이렇게 해서 MSBuild XML 내에 모두 기술되어 있던 큰 한덩어리의 SQLGate 빌드 과정이 젠킨스를 통해 Pre-Build, Build, Post-Build 단계로 구분되었고 각 단계별로 세세한 조정이 가능해졌습니다.
따라서 이제부터는 SQLGate 컴파일 옵션 변경이 필요하면 Build 영역만 수정하면 되고, 컴파일 전 후에 추가적인 옵션이 필요하다면 Pre-Build나 Post-Build 과정에 젠킨스 플러그인을 추가하는 것 만으로 빌드 과정을 관리할 수 있습니다.
8. 빌드!
최종적으로 기존 MSBuild XML 파일 구성과 여러 빌드 과정들을 분석하고 구성하는데까지 한나절 정도가 걸렸고 젠킨스에서 첫 빌드를 성공했습니다!
9. 완성
이제는 원격 데스크탑으로 서버에 들어갈 필요 없이 젠킨스에서 클릭 몇 번이면 빌드 및 S3 업로드 과정까지 자동으로 진행됩니다. 심지어 급하면 모바일에서도 빌드가 가능합니다.
저희 회사 내에는 수십개의 프로젝트가 젠킨스를 기반으로 자동화 되어 있어 언제든지 쉽고 빠르게 빌드하고 배포할 수 있습니다. 오픈 소스 프로젝트부터 내부 시스템들까지 개발자가 두번 이상 반복해야 하는 일들은 전부 자동화하고 단순화시키는데요 이제는 SQLGate까지도 더 높은 수준의 자동화가 이뤄져서 더 빠르고, 더 안정적으로 제품을 고객들에게 전달할 수 있게 됐습니다.
자동화하고, 반복적인 일을 줄이지 않으면 소프트웨어 회사는 크게 성장하기 힘들 것이라 생각합니다. 자동화하지 않고 지나가면 어느 순간부터는 컴퓨터가 해야할 일을 수많은 사람이 대신 하고 있고 이는 엄청난 생산성 손실과 버그를 낳기 때문이죠.
글로벌 소프트웨어를 만들고 싶다면 지금 당장 우리 회사에 자동화되지 않은 부분을 찾으세요. 그리고 고객의 요구사항 분석과 소프트웨어 설계에 더 많은 시간을 확보하여 더 좋은 제품을 만들고 싶다면 지금 당장 자동화를 시작해보세요!
