Jenkins Blue Ocean 소개 및 주관적인 단점 3가지

Jenkins Blue Ocean은 Jenkins Pipeline을 구성하는 데에 있어 더 편리하게 도와주는 도구다.

그래서 Blue Ocean을 소개하기 전에 Pipeline에 대해 잠깐 얘기하고 넘어가 보자.

 

Pipeline이란?

 

전통적인 젠킨스 구현 방법은 아래처럼 Freestyle project를 만들어서 각각의 설정 값들을 하나하나 기입해서 CI & CD(통합 및 배포)를 구축하는 방법이었다.

Freestyle로 CI & CD를 구축했을 때의 단점은 개발자가 직접 CI를 위한 설정 값과 CD를 위한 설정 값들을 이곳저곳에 넣어줘야 했었다.

 

이러한 행위는 결과적으로 환경이 분산되어 있다는 문제점을 직면할 수 밖에 없다.

환경의 분산은 추후에 똑같은 설정을 다시 하더라도 마치 새로 학습하는 것처럼 어려움을 겪을 수도 있다는 큰 단점이 존재했다.

 

이 문제를 해결해준 것이 Pipeline인데, Pipeline을 쓴다면 CI & CD를 소스코드로 관리할 수 있다.

지속적 통합(CI)과 지속적 배포(CD)를 하나의 소스코드 내에 설정을 할 수가 있어서 소스코드 자체만으로도 어떠한 방식으로 흐름이 이어지는지 이해하기가 쉽고 그로인해 통합 배포 환경을 구축하기가 더 쉬워졌다.

 

Blue Ocean의 등장 그리고 장점

 

소스코드로 CI & CD를 관리하던 Pipeline을 더 간편하게 쓸 수 있도록 만든 것이 Blue Ocean이다.

그럼 Blue Ocean에서 소개하는 대표적인 장점들을 몇 가지만 알아보자.

 

쉽게 이용할 수 있는 Pipeline

 

기존 Pipeline만을 이용했을 때는 아래처럼 소스코드로 CI & CD를 관리하였다.

이러한 소스코드를 JenkinsFile이라고 한다. 

Pipeline을 이용한 Github Clone

하지만 Blue Ocean으로 첫 작업을 시작한다면 아래와 같이 사용자 친화적인 UI로 시작을 하게 된다.

Blue Ocean을 이용한 Github Clone

참고 - Pipeline을 이용하면 JenkinsFile을 외부에 만들지 않아도 젠킨스 페이지 내에 설정 값에 넣고 사용할 수 있다. 반면 Blue Ocean은 JenkinsFile이 형상 관리에 Commit 되어 관리된다.

 

Pipeline 시각화

 

Pipeline 기존의 투박한 단계적 표현이 Blue Ocean으로 넘어가면서 보기가 쉬워졌다.

Github의 Branch를 멀티 환경으로 구성할 때 더 뛰어난 시각적 이미지를 제공해준다.

Pipeline을 이용한 시각화

Blue Ocean을 이용한 시각화

문제 진단 및 로그 가독성

 

Blue Ocean에서는 각 단계마다 로그 확인할 때 더 깔끔해서 문제를 진단하는 데 더 수월하다.

Pipeline을 이용한 로그 출력

Blue Ocean을 이용한 로그 출력(각 Pipeline 단계마다 재시작도 할 수 있다)

 

주관적으로 느끼는 3가지 단점

사실 이 글에서 개인적으로 얘기하고 싶었던 것은 이 부분이다.

너무 주관적이라 옳지 않은 내용일 수도 있다.

 

아이러니하게도 친화적이지 않다

위의 내용에선 Blue Ocean에서 친화성을 장점으로 내세웠다.

하지만 개인적으로 느끼기에 전혀 친화적이지 않았다.

기존 Pipeline에서는 소스 코드의 생성을 도와주는 Pipeline Syntax 기능이 존재했다.

Pipeline Syntax는 사용자가 필드에 적절한 값만 입력하면 아래와 같이 소스 코드를 생성해주는 기능이다.

Pipeline의 소스 코드 자동생성

하지만 Blue Ocean에서는 Pipeline의 설정 값에 대한 가이드가 존재하지 않는다.

필요한건 알겠는데 뭐 어쩌자고..

예를 들어 ParamPublish 값이 필요하다해서 기존에 Script에서 쓰던 파라미터를 넣었는데, 아래와 같은 에러가 발생했다. 실제 쓰는 값인데도 불구하고 에러가 났다는 건 뭔가 단단히 잘못됐다.

Expecting "class jenkins.plugins.publish_over_ssh.BapSshParamPublish" for parameter "paramPublish" but got "value" of type class java.lang.String instead

열심히 삽질한 결과(Github에 있는 JenkinsFile에 수동으로 파라미터를 넣어보니 알게됨) 파라미터를 아래와 같은 형식으로 넣어줘야 인식을 했다.

하지만 그 어떠한 가이드조차(심지어 구글 검색으로도) 존재하지 않았다.

${[ 파라미터 값 ]}

심지어 저 조그만한 Input Box에 10줄짜리를 붙여넣어줘야한다.(쓰지말란건가?)
파라미터 형식이 너무 친화적이지 않기 때문에 Pipeline의 Syntax 자동 생성 기능을 이용해  JenkinsFile이 Commit 된 Github에서 수동으로 작성, 수정하는 것이 더 수월하다.(이정도면 Blue Ocean의 편의성은 박살난 수준인 듯.)

Blue Ocean의 Pipeline 소스 코드를 수정하기 위해 Github을 접속함 ㅠ_ㅠ

 

느리다

써본 결과 굉장히 느리다. 말도 안 되게 느리다. 심지어 가끔은 Process가 중단도 안된다.

JenkinsFile이 Save되면서 Github에 Commit되는 것도 페이지 자체가 죽어서 새로고침 해야한다.

이러한 원인이 어디서 어떻게 된건지 왜 느려지는지도 파악이 안 된다.

🔎 jenkins blue ocean slow to load: Google 검색

해당 관련 글이 꽤나 많은 것 같다.
몇 개 열어봤는데 왜 느린지 찾아내려는 명탐정 코난들이 넘쳐났다.
(Git에서 가져오는 게 느리다느니.. 로그가 많이 쌓여서 느리다느니.. 등등)

범인은 이 안에 있어!

하여튼 그 정도로 느리다.

참고 - 개인적으로 Pipeline을 이용해서 만든 것을 Blue Ocean으로 시각화 용도로만 확인하는 것은 느리지 않았다. 뿌리 자체를 Blue Ocean으로 바로 시작하는 경우에만 굉장히 느렸다.

레퍼런스가 없다.

관련된 참조할 문서가 턱 없이도 적다.

특정 에러가 발생해서 검색을 해도 해당 내용으로는 검색이 안될 수도 있다.

나는 몰라서 구글에 질문을 했는데..

개인적으로 느끼는 점

장점, 단점 분류했을 때 남은 장점은 시각화뿐이다. CI&CD를 Pipeline으로 구성하되 가끔 시각화를 위해 Blue Ocean을 이용하는 것 말고는 장점을 모르겠다라고 느꼈다.