작업 설정

Ignore


 

지속적인 통합 서버가 실제 하는 작업을 지극히 간단하게 정리하면 버전 관리 서버에서 소스를 가져와서 정해진 빌드 도구와 규칙에 의해 결과를 실행하고 통보해 주는 것이다.

그래서 지속적인 통합 서버와 버전 관리 서버의 연계는 가장 기본적인 부분이다. 실제 빌드 설정을 하기 전에 둘 간에 어떻게 연계 되는지 살펴 보자.

 

빌드를 시작하기 위한 가장 우선해야 할 작업은 버전 관리에서 소스의 변경 유무를 확인하는 작업이다. e

이는 젠킨스 관리자가 수동으로 

가장 기본적인 연계 방식은 지속적인 통합 서버가 버전 관리 서버의 클라이언트가 되어 버전 관리 서버에서 소스를 받아 오고 변경 사항이 있으면 소스를 업데이트 받는 것이다.

이 작업은 지속적인 통합 서버의 설정에 따라 개발자가 수동으로 빌드 메뉴를 실행시 이뤄질 수 있고 스케줄러에 의해 일정 시간마다 자동으로 이루어 질 수 있다.

또는 반대로 버전 관리 서버에서 변경 사항이 있을 때 지속적인 통합 서버에 자동으로 빌드를 수행하도록 정보를 전송할 수 있다.


 

 

이제 사용하기 위한 설정을 마쳤으니 젠킨스를 사용하여 소프트웨어 빌드를 수행해 보자.

 

젠킨스는 실행 가능한 업무 단위를 작업(Job) 이라고 표현한다. 하지만 이 작업을 만드는 메뉴의 이름은 "새로운 Item" 이며 메뉴의 링크 이름은 "New Job" 이고 생성이 완료된 작업은 "프로젝트"이다.

이로 인해 젠킨스를 처음 접할 경우 약간 혼란스러울 수 있지만 작업과 프로젝트는 젠킨스에서는 거의 동의어라고 생각하면 된다.

작업 또는 프로젝트를 실행하는 것은 "빌드"라고 하며 개별 빌드는 구분을 위해 유일한 일련 번호가 부여된다.

 

이 책에서는 혼란을 줄이기 위해 작업이라는 용어로 통일하여 사용하도록 하겠다.

 

https://wiki.jenkins-ci.org/display/JENKINS/Terminology

https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project

http://jenkins-ci.361315.n4.nabble.com/Is-it-called-quot-Project-quot-or-is-it-called-quot-Job-quot-td4628610.html

 Click here to expand...

Hi bl0ck3r, 

this puzzled me as well at the beginning, but there's actually quite 
some logic to it ;O): 

A project is a special case of a job, i.e. all projects are jobs, but 
not all jobs are projects. 

Cheers, 
Simon. 


The long story: 

Perhaps it helps to extend to mentally the names to "*general purpose* 
jobs" and "*software building* projects" (although the latter don't need 
build software, they are tailored to this use case). 

In the case of "new job", Jenkins can't not know yet, if the new job 
will be of the project subtype. On the other hand, once you have chosen 
to create a project, this is reflected as specific as possible in the UI 
("Project Foo"). If you look at the precise wording on the "New Job" 
page, you'll realize the subtle differences (e.g. "Build a free-style 
software *project*" as opposed to "Monitor an external *job*"). 

An example of a job that is *not* a project is the lesser known 
"external job" that receives  notifications from events that happen 
outside Jenkins, but should be tracked inside Jenkins (e.g. system 
restarts etc.). See 
https://wiki.jenkins-ci.org/display/JENKINS/Monitoring+external+jobs for 
more about this job type. 

For the records, this is actual class model used by Jenkins internally 
(extending sub-classes are indented below their super-class: 

Job 
   AbstractProject 
     MatrixProject (a.k.a. "multi-configuration project") 
     Project 
       FreeStyleProject 
       MatrixConfiguration (a single configuration of a matrix project) 
   StubJob 
   ViewJob 
     ExternalJob 

Only FreeStyleProject, MatrixProject, and ExternalJob are visible on the 
"New Job" page. 

So, how could we could improve the understanding of the difference 
between "Job" and "Project" in the UI? Any suggestions?