왜 jenkins를 도입했나요?

저는 java, spring을 사용해서 Web기반 관리도구 개발을 하고 있습니다. jenkins를 도입한 이유는 jenkins가 기능 개발에만 집중할 수 있게 해주기 때문이였습니다. 처음 회사에서 개발일을 시작 했을 때, 개발에만 집중할 수 없었던 제 업무 흐름은 다음과 같습니다.

기존 개발 환경에서 기능 개발시 업무 흐름

1. 개발 노트북에서 기능 개발
2. SVN에 commit
3. 개발 노트북에서 WAR 파일 빌드
4. FTP로 사내관리도구 개발서버에 WAR 복사(배포)

기존 개발 환경의 문제점

기능 수정시 프로세스의 명확한 기준이 없었기 때문에 제가 선택할 수 있었던 방법은 개발서버의 데이터를 직접 수정하는 방법과 기능개발 후 배포하는 것과 동일한 방법 두가지가 있었습니다.

기능 수정 업무 흐름 (1) - 전체 배포

“기존 개발 환경에서 기능 개발시 업무 흐름”과 동일

기능 수정 업무 흐름 (2) - 변경 파일만 배포

1. 개발노트북에서 수정
2. SVN에 commit
3. ftp로 수정한 파일을 반영

기능 수정 업무 흐름 (3) - 직접 수정 후 소스 반영

1. ssh로 사내관리도구 개발서버에 접속
2. 변경이 필요한 .jsp .js .css 파일을 직접 수정
3. 개발노트북에 수정 내역을 적용
4. SVN에 commit

.js 파일의 한두글자 고치는건데 전체를 패키징 해서 배포하는 것은 상당히 번거로운 일이였습니다. 그렇기 때문에 수정해야 할 내용이 적을때는 3번 방법을 사용하곤 했습니다. 하지만 직접 수정하고 있을 때 또다른 수정 요청이 오면 서버에는 소스를 변경 했지만 개발노트북/버전관리에 반영하는 것을 잊어서 다시 작업했던 적도 있습니다.

기존 개발 환경 개선 - jenkins 도입 후 업무 흐름

1. 개발 노트북에서 기능 개발
2. SVN에 commit
3. SVN 변경이 이루어지면 jenkins가 최신 소스를 가져와서(pull) 빌드
4. jenkins가 빌드 결과물을 사내관리도구개발서버에 배포

jenkins를 도입해서 기능 개발을 하거나 또는 긴급한 수정을 할때나 구분없이 그저 로컬개발환경에서 개발 후 SVN에 commit하기만 하면 자동으로 배포를 합니다. 그렇기 때문에 기능 개발/수정에만 집중할 수 있었고 작업의 명확한 기준이 있기 때문에 실수 발생 여지를 없앴습니다. 특히 퇴근 직전 수정 요청이 들어와도 개발 후 commit만 하면 배포는 알아서 되니 좀더 일찍 집에 갈 수 있어서 좋았습니다.

jenkins 쓰고 일찍 집에 가시길 바랍니다. :)