Jenkins PipeLine 적용기

오늘은 주말마다 조금씩 학습하여,
회사의 배포를 Jenkins PipeLine으로 개선한 히스토리를 적어보려 합니다.

JenkinsPipeLine을 공부하게 계기 (코드화의 중요성)

제가 JenkinsPipeLine을 공부하여 개선에 사용하게 된 계기는 "히스토리 체크"를 위해서입니다. 개선되기 이전에는 배포 과정에 필요한 코드나 옵션을 추가하기 위해서는 Jenkins 페이지에 직접 접속하고 수정한 후 저장하는 방식이었습니다. 해당 방식의 문제점은 개선한 당사자가 문서나 Jira Ticket 등 부가적인 작업을 통해 흔적을 남기지 않으면, 어떤 점이 개선되었는지 "다른 개발자들은 알 수 없다"는 점입니다.
"다른 개발자들은 알 수 없다"라는 것은 히스토리 체크가 이루어지지 않는다는 것을 뜻하며, 이는 개선된 기능이 각 사람에 고립(ISOLATION)되어 나중에는 관리할 수 없을 만큼 흩어질 수 있습니다.
이를 개선하기 위해 저는 Jenkins를 히스토리 체크가 가능한 형태로 개선해야겠다 생각하였고, Jenkins의 Job(각 배포 과정)을 코드화 할 수 있는 JenkinsPipeLine을 발견하게 되었습니다.
JenkinsPipeLine의 최대 장점은 "배포하고자 하는 프로젝트의 VCS[Git]에 코드로 포함시킬 수 있고, 배포 직전 코드를 분석하여 Job을 생성한 후 배포를 진행한다"였습니다.

회사의 배포를 개선하기 위한 부분적인 JenkinsPipeLine 도메인 학습

저는 회사에서 가장 중요하게 사용되는 Release QA용 빌드를 배포하는 Jenkins Job을 코드화하는 것을 목표로 JenkinsPipeLine을 학습하였습니다. 효율적으로 목표를 달성하기 위해서 Release QA용 빌드에서 사용되는 옵션과 코드를 분석하기 시작했습니다.

종류	현황
사용되는 명령어	Git, CocoaPod, Git Submodule, fastlane
Plug-in	Build User, MacOSX KeyChain Unlock
Option	Build 후 WorkSpace Clear

PipeLine의 가장 기본이 되는 문법들(Sections, Directives)을 학습하고 이후에 Plug-in, Option들을 차례로 적용해나갔습니다.
#Document에 설명이 매우 쉽게 잘 되어있어 설명은 생략합니다.

개선 후의 효과

개선으로 인해 가져온 효과는 ("코드화" == "히스트로 체크 가능한 형태") + 빌드 진행도의 가시성 확보가 부가적으로 있었습니다.

후기

개선할 점을 찾고 목표 있게 학습하여 개선하는 것은 개인적인 성장을 많이 일궈주는 것 같습니다.
이러한 패턴을 계속해서 가져간다면 "성장"이라는 어려운 단어가 어느 순간 쉽게 다가올 수 있지 않을까라고 생각합니다.
다른 개선 건들도 하나씩 정복하면서 좋은 정보도 제공할 수 있도록 노력하겠습니다.
감사합니다.