회사에서 여러가지 문제로 기존에 사용하던 Plastic SCM에서 Git Enterprise로 이관하는 작업을 진행하였다.
나는 이 작업에 참여하여 Git Repository Rule에 맞게 변경 된 Module / Repository를 특정 Repository Branch에 Integration 제작, xlibrary 분류, ini file 편집 등 수작업으로 진행 할 수 있지만, 이와 같은 작업을 대신 수행하는 Tool을 개발하여 작업을 조금 더 효율적으로 수행 할 수 있도록 하였다.
그렇담 GitHub에 이관 작업을 마친 Module / Repository들은 어떻게 관리되어 Build 되고, 그 Build된 산출물들이 압축되어 배포될까?
Github Action
Github Action은 Repository에서 바로 소프트웨어 workflow를 자동화 할 수 있도록 도와주는 도구이다.
작업을 검색, 생성 및 공유하여 CI / CD를 포함하여 원하는 모든 작업을 수행하고, 소프트웨어 workflow를 자동화 할 수 있도록 도와주는 도구이다.
이러한 Github Action은 Workflow, Event, Runner, Job, Step, Action으로 이루어져 있다.
Workflow
하나 이상의 Job으로 구성되고, Event에 의해 실행 된다.
Event
workflow를 Trigger하는 특정 활동이나 규칙이다.
특정 브렌치로 Push 하거나 PR, 혹은 특정 시간대에 반복, 외부에서 발생하는 활동으로 이벤트를 발생시킬 수 있다.
Runner
Gitbub Action Runner 어플리케이션이 설치된 서버이다. Workflow가 실행될 인스턴스라고 보면 된다.
Job
workflow의 기본 단위라고 보면 되며, Job은 더 작은 단위인 Step으로 이루어져 있다.
Step
작업에서 커맨드를 실행하는 독립적인 단위이다. 한 작업(Job)의 각 스텝들은 동일한 러너에서 실행되므로 해당 작업의 액션들은 서로 데이터를 공유한다.
Action
Workflow의 가장 작은 블럭이다.
이러한 Git Action, Workflow를 내가 생성하고 작성하는 경험을 해봤으면 좋았겠지만, Github Action 경험도 없고, yml 작성법도 모르는 내가 하기엔 많이 버겁고, 오래 걸리는 작업이며, 타 파트 직원분께서 미리 다 작업을 해두었기 때문에, Action이 어떻게 돌아가는지만 이해하면 됐다.
내가 이해한 프로세스는 이렇다, 각 Module에서 개발자가 PR / Push를 진행하면 해당 Module Repository에서 Github Action이 실행 되고, 이렇게 실행된 Action으로 Runner PC에 Module의 변경 된 소스 코드의 산출물이 통합되게 된다. 이렇게 만들어진 산출물들을 Runner PC 뿐만이 아니라 Artifactory라는 JFrog 파일 서버에도 업로드 하게 된다. 그럼 이러한 산출물들을 가지고 특정 시간에 배포를 하면 되는데, 이 과정은 Jenkins를 통해 이루어지게 된다.
Jenkins
Jenkins는 앞선 [업무 이해] Jenkins에서 언급했듯이, Build 자동화를 통해 Build 산출물들을 공유 저장소 한 곳에 떨궈주는 역할을 한다.
이러한 Jenkins를 통해서 특정 시간마다 모여진 산출물들을 압축하여, ISO파일로 배포하게 된다.
SQA
Software Quality Assurance의 약자로 소프트웨어 품질 보증을 뜻한다.
앞선 과정들을 거친 후 배포된 버전을 갖고, 다양한 테스트를 진행하여 이것에 대한 오류 관리 및 통계 관리 같은 일련의 작업을 통해 소프트웨어의 품질을 보증하고, 향상 시키는 것에 목적이 있다.
현재 Git으로 형상 관리 이관 작업이 마쳐졌고, 이러한 SQA를 진행하고 있다.
마치며
이번 형상 관리 이관 작업에 참여하며 매우 생소한 부분이 많았다. 처음 접하는 Plastic SCM이라는 형상 관리 Tool과 Jenkins, 그리고 Github Action, JFrog, SQA 등등,,, 거의 모든 것이 내겐 생소했다…이러한 작업을 통해 회사에서는 어떻게 소스 관리가 되고 있고, 이것들이 통합되어 빌드되고, 빌드 된 산출물이 압축되어 배포 되는지, 또 이러한 배포된 소프트웨어를 SQA라는 과정을 통해 검증하고, 보증하는지 등의 프로세스를 알 게 될 수 있었던 것 같다. 또, 이관 작업에 참여하며 여러 Tool을 제작하는 과정에서 Github 명령어에 친숙해질 수 있었던 것 같다. 실제로 이 작업을 통해 형상 관리가 전혀 되지 않던 내 몇몇 소스 코드를 형상 관리 할 수 있게 되었다. 나는 현재 SQA 과정을 진행하면서 타 파트에 전달 해야하는 문서들이 있는데 이러한 문서를 작성하여 배포하는(파일 서버에 업로드하는) Tool을 만들고 있다.
