CI 환경 구축 및 체크인 테스트 환경 구성

[aiceru]

지금까지 수동으로 수행하는 mvn test 에 의존하고 있었는데, 효율적인 개발 진행을 위해서 CI 환경 구축이 도움이 많이 될 것 같습니다. 도입에 들어가는 코스트나 러닝커브는 조금 있겠지만, 장기적으로 보았을 때 실보다는 득이 많으리라 판단됩니다. 저도 CI 에 대해서 이론적으로나 실무적으로나 아는 것이 거의 없는 터라 조금씩이라도 내용 찾아보고 공유하도록 하겠습니다. 코드 보다가 다른 일 하고 싶을때 한번씩 의견 달아주세요 😄

• 아래는 네이버 이기열 책임님 건의입니다.
• CI 환경은 염두해 두신게 없으시면 travis ci 는 어떤지 검토해 주세요. github 에 올라있는 프로젝트는 무료이고, 외부 커미터도 검증할 수 있고, 무엇보다 체크인 테스트가 여기 들어있으면 커밋 이후 별도로 시험할 필요가 없어 좋을것 같습니다. 다만, 이건 건의 수준입니다.

[aiceru]

개인 리포지토리에 travis CI 를 잠깐 테스트해보았습니다. 일단 젠킨스 등의 유료(아마도) CI 서비스들과는 어떤 차이가 있는지까지는 알아보지 않았습니다만, 지금 우리 상황에서는 충분히 light 하게 쓸만하다고 보입니다. (이런거 도입하는걸 좋아하는 성격 탓도 있습니다;;ㅋ)

장점

• 각 개인마다 다른 개발환경(JDK / Maven 버전, Maven 환경변수, 시스템 환경변수 등등...) 에 신경쓸 필요없이 표준화된 test 환경을 가질 수 있다.
• Github 과 연동되어 push 만 하면 알아서 지정한 build 절차를 수행해준다.
• Web UI 기반으로, 개별 push 및 PR 마다의 build 결과를 history 로 볼 수 있다.
• Github repository 에 icon 으로 현재 commit 의 build 결과를 한눈에 표시해준다.

단점

• travis CI 가 별도의 virtual 환경을 생성하여 빌드를 수행하기 때문에, (VM 생성 과정 때문에) 단일 build, test 시간은 수동으로 직접 하는 것보다 느리다.
• 우리의 경우, arcus-memcached 와 zookeeper 가 어딘가에 떠 있어야 mvn test 수행이 가능하기 때문에, travis build 용으로 상시 arcus-memcached + zookeeper 를 띄워 놓을 서버가 필요하다.
• 위의 상시 서버를 띄워 둘 경우, m001 이나 m002 정도가 적당하다고 생각이 되는데... mvn test 의 환경변수 (-D...) 로 서버주소, 서비스코드를 지정해야 하기 때문에 이 내용이 외부로 노출된다.
• (이런 경우가 있을지는 모르겠지만) 동시에 2개 이상의 mvn test 가 같은 서버로 connect 할 경우 cache 의 내용이 꼬여 build fail 이 발생할 가능성이 있어 보인다.

정도입니다. 틈틈이 계속 써보고 내용 추가하겠습니다.

[whchoi83]

아래 링크에 들어가실 수 있을지 모르겠지만 travis 를 도입하려고 테스트 하다가 몇 가지 문제로 delay 했었습니다. https://travis-ci.org/whchoi83/arcus-java-client

먼저 arcus-java-client 를 CI 를 통해 지속적으로 테스트 하려면 반드시 arcus-memcached 가 구동되어 있어야 합니다. 문제는 ci 가 동작할 때 마다 travis-ci 에 arcus-memcached 가 "build 되고 구동되거나", "구동되거나" 해야 합니다. 아마도... arcus-memcached 를 clone 받은 뒤, build 하고, 구동해야 할 것 같습니다. 또한 이중화용 테스트를 위해서는 이중화 구성도 해야되고 ZooKeeper 도 구성해야 되고 등등등 이 있습니다.

이를 위해서는 자체적으로 Jenkins 같은 CI를 구성해야 하는데 @jhpark816 님과 상의 후 비용적인 측면이 맞지 않다고 판단하고 delay 했었습니다. 아니면 우리가 arcus-java-client 의 ci 를 위해서 별도의 ARCUS 를 구축해 두고 -D 옵션을 이용해 구축해놓은 ARCUS 를 사용하도록 해야 하는데, 이왕 CI 를 적용한다면 arcus-java-client 외에 다른 것들도 함께 구축하는 것이 좋을 것 같은데 그렇다면 ARCUS 만 별도 서버로 구축해서 travis 를 사용하는 것은 좀 맞지 않을 듯 합니다.

어쨌든 각설하고, 이번 문제도 그렇고, 실수로 mvn test 를 빼먹거나, 환경이나 branch 문제로 누락되게 되면 동일한 문제가 발생할 것 같습니다. 이번 기회에 CI 를 구축하는게 좋을 것 같습니다.

(결론... 서버가 필요합니다. 시간이 필요합니다. 😢)

[jhpark816]

CI 환경 구축에 필요한 장비 사양을 고민해 주세요.

[aiceru]

링크 들어가집니다. ^^ 해본것과 똑같네요. 일단 급한 이슈가 아니니, 천천히 여유를 갖고 이것저것 테스트해 보았으면 합니다.

별도의 독립 서버를 구축한다고 해도, 사무실 내부는 공유기를 통한 private network 으로 구성되어 있는 점도 그렇고, 위 단점 4번째에서 언급한 - 동시에 2개 이상의 travis VM 이 하나의 cache cloud 로 동일한 key-value set 으로 테스트를 시도하는 - 경우 테스트 결과의 신뢰성에 문제가 있는 점 등도 해결해야 합니다.

그렇다고 너무 신경을 안써도 안되니... 3분기 (~9월) 내로 결정을 하는 것으로 생각하고 진행해 보아요 ^^;; 독립 서버 환경을 구축하는 것도 우선 사무실에 남는 PC 한대로 trial 환경 정도는 갖춰볼 수 있을 것이라 생각됩니다.

[aiceru]

travis CI 빌드에 걸리는 시간입니다.

	로컬 맥	travis CI
USE_ZK=false	03:30	03:30 (04:46)
USE_ZK=true	27:56	27:57 (29:24)

travis CI 에서나, 로컬 맥에서나 mvn test 에 걸리는 시간은 같았고, 전체 시간 (괄호 안 : travis 에서 mvn test 를 위한 환경을 준비하는 데 걸리는 시간까지 포함한 시간) 은 약 1분 20~30초 정도가 더 걸리는 정도네요.

• 참고 : 이 결과는 travis CI 의 cache 기능을 이용해 arcus-memcached 의 소스/빌드결과물 을 캐싱해 두었다가 꺼내서 사용한 결과입니다. arcus-memcached 의 버전이 바뀌어 새로 빌드해야 할 경우는 시간이 훨씬 더 늘어날 수 있습니다.

이만하면 충분히 써볼 만 하겠다 생각됩니다.

지금까지는 제 개인 repo 에서 테스트해봤는데, github organization 의 repository 에 대해서 어떻게 적용이 가능한지 더 알아보고 결과 남기겠습니다.