Freestyle Job
- 빠른 시작에 적합
- 설정 이력 추적이 약함
- 복잡한 조건과 단계 관리가 어려움
이 파트에서 다루는 내용
Freestyle Job과 PipelineBuild TriggerParameterArtifact와 Test Report
01
Freestyle은 시작점, Pipeline은 운영 기준입니다
Freestyle Job은 UI에서 단계별 명령을 입력해 빠르게 시작하기 좋습니다. 하지만 설정이 UI에 흩어져 코드 리뷰와 이력 관리가 어렵습니다.
Pipeline은 Jenkinsfile로 빌드 절차를 코드화합니다. Git에 함께 저장되므로 변경 리뷰와 복구가 쉽고, 브랜치마다 다른 흐름을 관리하기 좋습니다.
Pipeline
- 빌드 절차를 코드로 관리
- PR 리뷰 가능
- 공유 라이브러리와 멀티브랜치 확장 가능
02
트리거는 언제 빌드할지를 결정합니다
- 수동 실행은 긴급 재빌드나 확인용으로 적합합니다.
- Git push 또는 PR 이벤트 기반 실행은 CI의 기본 흐름입니다.
- 정기 실행은 배치 검증, 의존성 점검, 야간 테스트에 사용할 수 있습니다.
- 배포 Job은 자동 실행만으로 끝내지 않고 승인 단계나 브랜치 제한을 둡니다.
03
결과물은 로그보다 구조화된 산출물로 남깁니다
Jenkins 로그는 문제를 추적하는 데 중요하지만, 성공 여부를 로그로만 판단하면 재사용성이 떨어집니다. 테스트 리포트와 빌드 산출물을 구조화해서 남겨야 합니다.
Artifact
jar, zip, 정적 빌드 결과처럼 다음 단계에서 사용할 산출물을 보관합니다.
JUnit Report
테스트 결과를 Jenkins UI에서 성공/실패와 추세로 확인할 수 있게 합니다.
Build Log
문제 원인 추적용입니다. 비밀정보가 찍히지 않게 주의해야 합니다.
04
프로젝트 팀원은 Job 화면에서 먼저 판단합니다
팀원이 Jenkins를 사용할 때는 빌드 버튼만 누르는 것이 아니라 어느 브랜치와 커밋을 대상으로 어떤 stage가 실패했는지 읽어야 합니다. 실패 원인을 모른 채 재실행하면 같은 실패를 반복하거나 배포 Job을 잘못 실행할 수 있습니다.
일반 팀원은 Stage View, Console Log 첫 에러, Test Result, Artifacts, 파라미터 값을 확인한 뒤 재실행 여부를 판단합니다. Credentials, Agent offline, 플러그인 오류처럼 권한이나 운영 설정이 필요한 문제는 담당자에게 넘깁니다.
Stage View
Checkout, Install, Test, Build, Deploy 중 어느 단계가 실패했는지 먼저 봅니다.
Console Log
전체 로그를 끝까지 훑기보다 첫 에러와 실패 직전 명령을 확인합니다. 토큰 값이 출력됐으면 즉시 공유하지 말고 담당자에게 알립니다.
Test Result
테스트 실패는 빌드 환경 문제와 분리해서 봅니다. 실패 테스트 이름과 최근 변경 파일을 함께 확인합니다.
Parameters
수동 실행 Job은 브랜치, 배포 환경, 스킵 옵션 값을 확인한 뒤 실행합니다. 운영 배포 파라미터는 특히 재확인합니다.
사용자 기준
팀원은 Jenkins 실패를 '빨간 빌드'로만 보지 말고 stage, 대상 커밋, 파라미터, 산출물 기준으로 재현 가능한 보고를 남겨야 합니다.
체크