[BackEnd] CI/CD, Jenkins란?

?

개발자는 개발만 잘하면 되는 거 아니였나?
개발자를 방해하는 개발 외적인 문제가 여러가지 있겠지만, 여기선 2가지 문제를 살펴보자.

 

문제 1. 코드를 하나로 통합하는 과정이 너무 스트레스야

하나의 프로젝트에서 10명의 개발자가 파트를 나눠 개발하는 모습을 상상해보자. 각자 개발한 코드를 하나로 통합하기 위해, 기능이 추가될 때 마다 개발자들은 코드 베이스에 커밋을 넣을 것이다. 착하게 합쳐지면 참 좋겠지만 커밋들을 머지하기 시작하면  "마지막 커밋 누구야, 내 꺼 안 되잖아! "와 같은 아우성이 터져나오기 마련이다. 이를 'Merge hell'이라고 부르기도 한다. 

 

위와 같은 사태를 막을 방법이 하나 있다. 커밋을 할 때 마다 코드에 대해 테스트와 빌드를 실행해보는 것이다. 당연히 개발자 입장에서는 귀찮고 달갑지 않은 일이지만 협업해 개발한 코드는 통합하는 작업이 필요하기 때문에 어쩔 수가 없다.

 

문제 2. 자꾸 다른 부서에서 새 버전을 배포해달라고 해

개발하던 중, 해당 기능에 대한 업데이트가 됐다면 새로 배포해달라는 다른 부서의 요청이 들어온다. 압축파일로 뚝딱 보내주는 것은 내가 해당 부분의 담당자라면 있을 수 없는 일이다. 마땅히 업데이트된 코드를 빌드해 약속된 형태로 공유해줘야 할 것이다. 이를 위해 배포 스크립트를 작성하고, AWS 콘솔을 만지고, ... 배포 역시 보통 작업이 아니다. 하지만 이 역시 협업을 위해서 꼭 필요한 작업이기 때문에 어쩔 수가 없다. 

 

0. CI/CD

문제 1은 CI와 관련한 문제이다. CI는 Continuous Integration의 약자로 '지속적인 통합'을 의미한다. 정확히는 '여러 개발자의 코드를 지속적으로 통합하는 과정'을 의미한다. 문제 2는 CD와 관련한 문제이다. Continous Delivery의 약자로 '지속적인 배포'를 의미한다. 정확히는 '최신의 코드를 지속적으로 배포하는 과정'을 의미한다. 

CI(Continous Integration)는 '여러 개발자의 코드를 지속적으로 통합하는 과정'
CD(Continous Delivery)는 '최신의 코드를 지속적으로 배포하는 과정'

 

1. Jenkins

집사 : "제가 귀찮은 일은 다 알아서 할테니 개발자님은 개발만 하세요"

사실 문제 1, 문제 2는 손이 많이 갈 뿐 해결책이 없는 문제는 아니었다. 그리고 이 손이 많이 가는 과정을 일련의 파이프라인으로 만들어 자동화해주는 소프트웨어들이 있으니, 그 중 대표적인 녀석이 Jenkins다. CI를 위해 커밋이 들어오면, 자동으로 테스트하고 빌드를 해준다. 과정에 문제가 없었다면 하나의 코드 베이스에 통합해준다. 이 최신의 코드들을 당장 사용할 수 있는 상태로 공유하며 CD까지 해결해준다. 이제 내가 해야할 일은 열심히 개발하고 커밋해서 코드 베이스에 내 코드를 안착시키는 것만 생각하는 것이다. Jenkins가 모든 것을 처리해 검증, 통합, 배포를 모두 해줄 것이다!

Jenkins Pipeline

Jenkins는 자동화 작업이기 때문에, 프로젝트 별로 유동적으로 설정해야하는 부분이 많다. 예를 들어, Gitlab 리포지토리를 소스 폴더로 두려고 한다면 Gitlab 리포지토리를 Jenkins가 사용할 수 있도록 해야 한다. 이것을 위해 Jenkins는 매우 다양한 플러그인을 제공하고 있다.  일련의 CI/CD 과정을 처리할 수 있도록, 프로젝트에 맞게 플러그인들을 다운 받는다.

 

이 플러그인들은 Jenkins Pipeline이라는 곳에 꽂힌다. 말 그대로 Jenkins의 테스트, 빌드, 배포 등의 상세 과정을 정의하는 파이프라인이다. Jenkins Pipeline을 정의하는 문법에는 Declatrative, Scripted 두 가지 방식이 존재한다. 이 중 Declarative 방식의 뼈대를 살펴보자.

Jenkinsfile (Declarative Pipeline)
pipeline {
    agent any 
    stages {
        stage('Build') { 
            steps {
                // 
            }
        }
        stage('Test') { 
            steps {
                // 
            }
        }
        stage('Deploy') { 
            steps {
                // 
            }
        }
    }
}

Jenkins Pipeline은 크게 4개의 Section으로 구성된다.

• Agent Section : Jenkins가 여러 노드가 떠있을 수도 있는데, 노드 단위의 업무를 지시한다.
• Stages Section : 기본적으로 수행해야 하는 업무별 단위(stage)를 정의한다.
• Steps Section : 각 업무(stage)의 상세 작업을 플러그인의 기능(step)들을 활용해 정의한다.
• Post Section : 각 업무(stage)가 끝난 후의 루틴을 정의한다.

 

2. 요약

1. CI/CD는 협업을 위해서 꼭 필요하지만 번거롭고, 개발 외적인 소모가 크다.
2. Jenkins는 코드의 통합과 배포를 자동화해서, 개발자가 코드에만 집중할 수 있도록 해준다.
3. 플러그인을 조합하고 4개의 Section을 작성해 Jenkins Pipeline을 만들어 자동화 과정을 정의한다.

 

---

[참고]

https://www.youtube.com/watch?v=JPDKLgX5bRg 

https://www.jenkins.io/doc/book/pipeline/