Build 자동화 방법에 앞서 PollSCM이라는 단어부터 알고 가자.
PollSCM이란 Git Polling 작업을 주기적으로 수행할 수 있게 하는 방법을 의미한다.
그렇다면 Git Polling은 무엇일까?
Git Pooling이란 일정 시간마다 Git 변경 사항을 확인하고 만약 지정한 Branch에 Push 상태가 발생했을 경우 Push 된 코드를 가지고 와 Build 시켜 재배포하는 것을 의미한다.
즉, Poll SCM을 통해 Git Branch에서 Push 과정이 발생했을 경우 일정 시간마다(Scheduling) 이를 확인하고 Push된 코드로 SW를 자동으로 빌드하여 재배포하도록 설정하는 것을 의미한다.
Poll SCM은 cron job을 통해 Scheduling을 수행한다.
Push가 발생했든 아니든 지정한 Cron Scheduling에 따라 Build를 수행하는 것을 의미한다.
확인을 빠르게 하기 위하여 1분마다 Build 작업을 수행하도록 Scheduling 하였다.
이후 Apply & 저장 버튼을 클릭하자
"지금 빌드"를 클릭하거나 Git Branch에 파일을 푸시하는 등의 이벤트를 발생시키지 않았음에도 불구하고 자동으로 #3 Build History가 새로 생성되었음을 확인할 수 있다.
Build periodically의 가장 큰 단점은 아무런 이벤트가 발생하지 않아도 빌드를 다시 수행한다는 것이다.
이 경우 너무나 많은 Build가 쌓여 오히려 서비스 제공에 불편함을 가져다 줄 수도 있다.
따라서 Poll SCM을 통해 Push 이벤트는 계속해서 확인하고, Build Periodically를 특정 시간(새벽 시간 등)마다 수행하여 자동화를 시키는 것이 좋은 것 같다.
그렇다면 Push 이벤트를 감지하는 Poll SCM 설정을 수행해보자.
개인적인 생각으로는 Push가 일어날 때만 Build과정이 수행되기 때문에 매 분으로 Sceduling 해도 괜찮을 것 같은데 Jenkins 측에서는 매분마다 Push가 수행되었는지를 확인하는 것이 자원 낭비라고 생각하는 듯싶다.
이렇게 설정해 놓고 Apply & 저장 버튼을 클릭하면 시간이 지나도 Build History가 쌓이지 않음을 볼 수 있다.
그렇다면 Build History를 증가시키기 위해 한 번 main 브랜치에 Push를 발생시켜보자.
이 과정은 사람마다 다양할 것이다.
IntelliJ 측에 Git과 연동시킨 Code가 있어서 IntelliJ를 통해 Application을 볼 수도 있을 것이며, Eclipse를 통해 Application에 대한 코드를 볼 수도 있을 것이다.
하지만 이 과정은 Web Application 구현에 관련된 주제가 아닌 Jenkins를 통한 CI/CD 자동화에 관련된 주제이므로 코드 변경을 최대한 간단히 수행할 것이므로 필자는 간편하게 Visual Studio Code로 코드를 수정하겠다.
용이한 확인을 위해 이왕이면 코드 변화를 쉽게 확인할 수 있는 jsp 파일이나 HTML 파일에 수정을 하고 Push를 수행하는 것을 추천한다.
"새로운 Update" 문을 통해 Push 이벤트가 생성되었음을 확인할 수 있다.