stages

Implement pipeline stages by referencing the article below. https://www.jenkins.io/blog/2017/02/01/pipeline-scalability-best-practice/

파이프라인코드는 groovy로 작성되지만, 실행 모델은 컴파일 타임에 CPS(Continuation Passing Style)로 변환되어 실행된다. CPS로 변경해 실행됨에 따라 다음과 같은 장점을 얻을 수 있다.

1. 파이프라인 코드는 재시작 가능하다.
2. 파이프라인 코드는 중단되었을 때, 다시 시작할 수 있다. 이를 위해서 CPS로 변경된 코드는 다음과 같은 단점을 가진다.
3. Groovy 로직에는 객체 기반 구분/블록 트리가 메모리에 유지되기 때문에 메모리 사용량이 높다.
4. Groovy로 작성된 코드는 실행 시간이 길어질 수 있다.

Best Practice

1. Pipeline code를 접착제로 생각하고 사용한다.

• Pipeline step을 함께 연결하고 도구를 통합하는 방법으로 사용
• 도구를 별도로 관리해 사용할 수 있기 때문에 재사용성이 높아진다.
  • 별도로 실행 가능한 실행 파일을 만들거나, 스크립트를 작성해 사용할 수 있다.

2. 단순하게 유지해야 한다

   • 파이프라인에 포함된 복잡한 논리의 양을 제한하고, 이를 범용 프로그램 언어로 작성하는 것을 피한다.
     • 파이프라인의 모든 변수를 Serializable 유형으로 제한해 파이프라인 코드를 재시작 가능하게 만든다.

3. 약간 복잡한 작업에는 @NonCPS 어노테이션을 사용한다.

   • @NonCPS 어노테이션을 사용해 CPS로 변환되지 않는 코드를 작성할 수 있다.
   • CPS로 변환되지 않는 코드는 파이프라인 코드의 성능을 향상시킨다.
   • 다만, @NonCPS 어노테이션을 사용할 때는 주의해야 한다.
     • @NonCPS 어노테이션을 사용하면 파이프라인 코드가 재시작되지 않는다.
     • @NonCPS 어노테이션을 사용하면 파이프라인 코드가 중단되었을 때, 다시 시작할 수 없다.
     • @NonCPS 오노테이션을 사용하는 메소드에서 CPS로 변환되는 코드를 사용할 수 없다. (Pipeline CPS Method Mismatches - https://www.jenkins.io/doc/book/pipeline/cps-method-mismatches)

4. 복잡하거나 CPU를 많이 사용하는 처리에는 Groovy 언어보다 외부 스크립트나 별도 실행 파일을 사용한다.

   • Groovy 언어로 작성된 코드는 실행 시간이 길어질 수 있다.
   • 별도 실행 파일이나 스크립트를 사용하면 파이프라인 코드의 성능을 향상시킬 수 있다.
   • 단계별 Pipeline 내부 변수는 serializable하게 저장되기 된다. 이에 따라 별도 실행 파일이나 스크립트를 사용하면 파이프라인 코드를 재시작 가능하게 만들 수 있다. (다만, 빌드가 실행되는 resource 환경에 따라 별도 실행 파일이나 스크립트를 사용할 수 없는 경우도 있다. - ex) k8s pod에 의해 실행되는 빌드)

5. 외부 통합을 위해서는 플러그인 사용을 고려하자 - SCM, Artifacts 관리, 배포 시스템 및 시스템 자동화를 위한 플러그인을 사용해 파이프라인 코드를 간소화하고, 재사용성을 높일 수 있다.

6. Pipeline script의 재사용성을 높이려면, 매개변수화된 파이프라인과 변수를 사용하자 - Pipeline을 매개변수화하면, 파이프라인 코드 재사용성을 높일 수 있다.

7. 파이프라인에 포함된 비즈니스 로직를 제한하자. - 완전히 비즈니스 논리를 제거하는 것을 불가능하지만, 최대한 완료할 작업을 집중해 작업하자 - 비즈니스 로직을 제거할 수록 유지 관리가 용이해지고 재사용성이 가능하며 성능이 향상된 파이프라인 코드를 작성할 수 있다 - 하드 코등된 상수 값은 항상 리팩토링해 변수로 대체하자