2020 10 03

해당 링크(www.itworld.co.kr/news/107527)를 참고해 작성한 내용입니다.

참조문서1 - ko.wikipedia.org/wiki/%EC%A0%A0%ED%82%A8%EC%8A%A4

 

젠킨스란 무엇인가, CI서버의 이해 간략하게 맛보기.

본격적으로 젠킨스를 파기 전에 너무 어려운 내용이 나오면 뇌가 놀래니까 뇌가 놀래지않게 잔잔한 내용부터 시작해 봅시다.

젠킨스

소프트웨어 개발 시 지속적 통합 서비스를 제공하는 툴이다.

다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유 영역에 있는 Git등의 저장소에 빈번히 업로드 함으로써 지속적 통합이 가능하도록 해준다.

 

지속적 통합(CI)이란

개발자가 기존 프로젝트의 수정 작업을 시작할때, 일반적으로 현재의 코드 베이스의 복사본을 받아서 거기서부터 작업을 시작한다. 

개발자들이 저장소에 코드를 내보내려면 먼저 자신이 코드를 받았던 때부터 현재까지 저장소 코드의 변경내용을 자신의 로컬프로젝트에 반영되도록 업데이트 한 후 자신의 코드를 내보내야 한다. 

 

지속적인 통합은 자주 통합해서 "통합의 지옥"(매순간이 코드베이스로부터 멀어짐.... 업데이트 전쟁..)의 함정을 피하는것을 내포하고 있다. 지속적인 통합은 재작업을 줄여서 비용과 시간을 줄이는데 초점이 맞추어져 있다.

 

만약 지속적인 통합을 적용하지 않으면 각각의 프로그래머가 자신이 작업한 것을 제출하기 전에 반드시 완벽한 빌드와 테스트를 해야한다. 모든 프로그래머들은 원격 저장소로부터 프로젝트를 업데이트 하는것으로 하루를 시작해야 한다.

 

젠킨스가 나오기 전에 개발자가 할 수 있는 최선의 작업은 코드를 커밋하기 전에 로컬프로젝트에서 빌드 후 테스트하는것이였다.

-> 젠킨스는 빌드가 깨질수 있는 코드가 커밋 & 빌드된다면 해당 코드를 머지리젝트 시켜주는 기능을 하는것 같다. 지금은 젠킨스가 셋팅되어있어서 그럴일이 없지만.. 젠킨스를 사용하지 않던 예전회사에서는 어떤분이 빌드가 깨지는 코드를 배포 후 다음날 연차를 써버려서 엄청난 원망을 들었던것을 목격한적이있다...'커밋전에 컴파일 테스트 하라구요!!' .. 이제야 이해가 간다.

 

허드슨과 젠킨스

썬 개발자 가와구치님도 개발작업을하면서 비슷한 경험이 있었나보다. 그래서 코드를 원격저장소에 커밋하기 전에 해당 코드의 동작여부를 알수있는 방법을 찾고 싶었다. 그리고 허드슨을 만들었다. 그후에 오픈소스 화 된것이 젠킨스이다.