everydayminder
주로 Hudson을 썼는데, 이번에는 TeamCity를 설치하고 사용해 보고자 한다. 다운로드 사이트 : http://www.jetbrains.com/teamcity/ 2011/10/11 현재 최신 버전은 6.5이며, 만들 수 있는 설정 및 사용자 수에 제약이 있지만, Professional Edition 만으로도 테스트는 충분할 것이다. 플랫폼에 따라 또는 연동 방식에 따라 설치본이 나뉜다. 즉, 윈도우즈 서비스로 실행시킬 수도 있고, core만 설치하여 별도로 실행시킬 수도 있는 것 같다. 나열된 여러가지 플랫폼과 설치 방법중, 내가 택한 옵션은 "윈도우즈 플랫폼에, 기존의 J2EE 컨테이너에 설치하기"이다. 그러면, 나의 다운로드는 "JavaEE Container 탭"의 다운로드를 선택하면서 시작된..
moreunit은 작성중인 클래스에 테스트 코드가 작성되어 있는지를 시각적으로 보여주는 플러그인이다. 해당 플러그인에 대한 자세한 설명은 http://moreunit.sourceforge.net/index.html 에서 확인할 수 있다. 설치는, 직접 다운로드하여 플러그인 디렉토리에 풀어주거나, 이클립스 플러그인 설치 메뉴로부터, http://moreunit.sourceforge.net/update-site/ 를 등록하여 다른 플러그인 설치 과정과 동일하게 설치하면 된다. 본인의 경우, 별다른 기본 설정없이도 작성중인 클래스에 대해 테스트 클래스를 찾아 보여주었는데, 설정이 동작하지 않는다면 properties context menu로부터 세부 설정이 가능하다. 동작시의 화면은 moreunit의 공식사이..
"내가 작성한 코드는 잘 작성한 것일까?" 내가 작성한 코드가 이상없이 동작하는지 검사하기 위해, JUnit 등을 사용하여 테스트를 수행해 왔다면, 이제 이런 질문을 던져볼 만도 하다. 프로그래머가 작성한 코드는 "논리"의 집합이다. 그렇다면, 테스트케이스는 "그 논리가 적합한가?" 혹은 "그 논리에 헛점이 있는가?"를 검증하기 위한 것이라고 할 수 있을 것이다. 그러면, 그 "논리를 세우는 방법이 잘 되어 있는가?"를 검증하는 방법도 있을 법하다. 그래서, "코드검사"를 수행한다!! 코드 검사는 내가 작성하는 코드가 표준에 맞는지, 어떤 잠재적인 오류 패턴을 내포하고 있는지 등을 검사해 준다. CheckStyle, PMD, FindBugs 등 여러 가지가 있으나, FindBugs를 hudson에 연동하..
사실, 개발하면서 주석을 다는 것은 무척이나 흥미로운 귀찮은 일이다. 게다가 포맷을 지키고, 어떤 파라미터가 넘겨지고, 리턴 값은 어떻고, 어떤 상황에서 어떤 exception이 던져진다는 것까지 써야 한다면 더더욱 그렇다. 보통 프로그램부터 작성한 후, 주석을 달라고 한다면, 주석을 다는 것이 아주 하기 싫은 일이 될 가능성이 크다고 생각한다. 주석을 달면서, 코드 리뷰도 하고, 분석도 하고, 수정도 하는 선순환이 되기 보다는 상당히 형식적인 주석 작업이 될 확률이 더 높아진다. 오히려, 보다 양질의 주석을 달기에 좋은 시기는 해당 부분을 프로그램화 할 때라고 생각한다. 모든 프로젝트를 완료한 후, javadoc을 사용하는 대신에 초기부터 javadoc을 사용해 보자. 자신이 작성하는 코드와 비슷한 시..
지난 글에 설정한 바대로 ant task를 정상적으로 진행했다면, ant task로 emma.report 태스크를 수행했을 때, coverage.html과 coverage.xml이 생성되었을 것이다. 참고로, 생성된 coverage.html을 살펴보자. 해당 패키지의 구성중, 클래스/메소드/블럭/라인 기준으로 어느 정도가 test로 커버 되고 있는지를 보여준다. 패키지 이름을 클릭하면, 패키지에 포함된 클래스들이 나타나고, 이 클래스들이 어느 정도 test로 커버되고 있는지 보여준다. 이 중, 아무 클래스나 또 클릭하게 되면, 클래스내의 메소드들이 test로 어떻게 커버되고 있는지 현황을 자세하게 보여주게 된다. 이 결과물은, 별도의 ant task를 수동으로 실행시켜 얻은 결과물이므로, 이제 hudso..
지난 글t에서 hudson에 JUnit 테스트를 수행하는 방법에 대해 소개하였다. 물론, 코드의 품질은 어떤 테스트 코드를 어떻게 작성하느냐에 코드의 신뢰도가 달라진다. 그렇다면, 좋은 테스트는 테스트 케이스의 수에 단순히 비례할까? 두 말할 필요 없이 얼마나 양질의 테스트가 어떻게 수행되었는지가 중요할 것이다. 본 포스트에서 말하고자 하는 metric은 테스트의 커버리지(coverage)이다. 즉, 테스트의 커버리지가 높은 프로젝트 코드들은 검증을 거친 부분이 많으므로, 상대적으로 양질이라고 볼 수 있다. Emma는 프로젝트 코드와, 프로젝트 코드를 테스트하는 테스트 코드를 조합하여 비교함으로써, 주어진 테스트 코드가 원본 소스 코드에 대해 어느 정도의 커버리지를 갖는지를 조사해 준다. Emma는 어디..
소스의 품질을 높이기 위해, Junit을 사용하여 테스트를 자동화 하자. 본 포스트에서는 hudson에 junit 테스트를 태스크로 선언하여 빌드시 테스트를 실시하고, 그 결과를 hudson으로 리포트 하도록 설정하고자 한다. hudson에 등록한 프로젝트로부터 configure를 설정하면, 하단에 와 같이 Junit 테스트 결과를 리포트하겠다는 항목이 있다. 이 기능을 사용하기 위해, 기존에 선언한 build.xml (ant script)에 Junit 테스트 컴파일/ 수행을 하도록 추가할 것이다. 물론, 본인이 작성한 코드를 기반으로 Junit 코드들이 작성되어 있어야 한다. JUnit 테스트를 수행하고 리포트를 생성하기 위해, 기존에 작성한 build.xml을 다음과 같이 task를 추가한다. tes..
지금까지는 수동으로 Build Now를 클릭하여, build를 하는 것이었다면, 이제 Continuous Integration을 위해, 소스 변경본을 감지하여 자동으로 프로젝트를 build 하도록 설정을 해야한다. 우선, SVN 설정 부분에서 다음과 같이 체크박스를 설정한다. 그리고, 주기적으로 소스에 변화가 있는지 검사하도록 다음과 같이 Trigger 옵션을 설정한다. SCM을 polling 한다는 뜻은, 소스에 변화가 있는지 보고 변화가 있을 경우 build를 수행한다는 뜻이라고 보면 된다. 위의 그림에서 보는 바와 같이, 매 5분마다 검사하기 : */5 * * * * 매일 오전 9시에 검사하기 : 00 09 * * * 두 개의 옵션을 부여하였다. 이와 같이 설정하기 전에는, 와 같았으나, polli..
프로젝트를 생성했지만, IDE를 사용해서 빌드를 진행하는 과정은 개인의 PC에서만 수행되는 작업일 뿐이다. Hudson 등의 CI를 사용하는 것은 별도의 빌드 서버를 설정하고자 함이고, 별도의 빌드 서버는 개인의 개발 환경과는 상관없이 빌드를 수행할 수 있도록 설정되어야 한다. 따라서, maven이나 ant 등을 사용하여 별도로 빌드가 이루어지도록 설정할 필요가 있으며, 본 과정에서는 ant를 사용하여, 간단하게 빌드를 할 수 있도록 한다. 당연히, ant가 미리 설치 되어 있어야 하며, (http://ant.apache.org) ant의 설치 디렉토리는 ANT_HOME으로 설정되어 있어야 한다. 지난 번에 등록한 프로젝트명을 클릭하면, 좌측 상단에 위와 같은 Hudson의 메뉴를 볼 수 있다. 별도의 ..
Hudson을 설치했으므로, 이제 프로젝트를 생성하자. 1. 작업 생성하기 "새작업"을 클릭하여, 새 프로젝트를 생성한다. 임의의 프로젝트 이름을 입력하고, "Build a free-style software project"를 선택한다. 다음과 같은 세부 설정 화면을 볼 수 있다. 필요한 정보를 모두 입력한다. 이번에 www.unfuddle.com에 생성한 무료 SVN을 연결하여 프로젝트를 생성하기로 한다. Source Code Management 메뉴로부터, Subversion을 선택하면, 다음 화면을 볼 수 있다. Repository URL 옆의 ? 버튼을 클릭하여, SVN 위치와 인증 정보를 모두 입력하자. 아래의 화면과 같이 나올텐데, "this link"를 클릭하면 인증 정보를 입력할 수 있는 ..
SCJD를 준비 하면서, 준비하는 내용을 SVN에 관리하고, 빌드 및 테스트 등은 Hudson을 통해 진행하려고 한다. 이 과정에서 SVN은 www.unfuddle.com으로 선정하였다. 그 이유는, 무료이다. 적어도 200MB 정도의 공간은 제공한다. issue 관리가 가능하다. 비공개이다. 본 포스팅에서는 www.unfuddle.com의 각 메뉴를 간단하게 소개하고자 한다. 혹시, 관심이 있는 분들은 미리 살짝 볼 수 있을 것이다. (예전에도 말했지만, 공개 프로젝트라면 www.assembla.com도 상당히 좋을 것이라 생각한다.) 1. Dashboard 대쉬보드에서는 메시지 추가, 마일스톤 추가, 티켓 추가, 프로젝트 추가, 프로젝트원 초대 등 프로젝트 전반에 대한 기능을 수행할 수 있도록 되어 ..
무료로 제공되는 SVN 중에 꽤 괜찮아 보이는 곳으로 알려진 사이트이다. 인터페이스도 예쁘고, www.unfuddle.com에 비해 빠르다. google의 SVN에 비해서도 좋다고 한다. assembla에서 제안하는 plan은 다음과 같다. 즉, 비싸다. 무료 옵션도 존재하는데, 다음의 두 가지 옵션이 있다. 다만, private 옵션을 사용하게 되면 SVN 만 사용할 수 있고, trac 등 다른 툴을 사용할 수 없다. trac 등을 포함한 다른 툴을 쓰려면, public으로 써야 한다. public 프로젝트를 한다면 이 옵션도 괜찮아 보인다. 속도도 나쁘지 않다. 출처 : http://www.assembla.com
개인이 사용할 수 있는 무료 SVN 사이트로 www.unfuddle.com을 사용해 보고자 한다. 장점은 "무료"라는 점과, 무료임에도 "비공개"로 사용할 수 있다는 점, Issue 관리를 할 수 있다는 점이다. 단점은 "느리다"는 것이다. 용량은 200MB. 계정을 만들고 로그인하면, 다음과 같은 dashboard를 접할 수 있다. 느리지만, (Assembla, google에서 제공하는 SVN에 비해) 좋은 점이라면 역시 privacy가 보장되고, issue tracking이 된다는 점이다. 출처 : http://www.unfuddle.com
이제는 일일 빌드보다 Continuous Integration(지속적인 통합)이 트렌드이다. 이와 관련하여, 수많은 종류의 tool이 존재하나, 그 중 Hudson이라는 무료 CI 툴을 설치하고, 주요 설정 방법, 사용방법에 대해 정리하고자 한다. 1. 준비물 JDK Tomcat (설치 방법에 따라 다름) Hudson 2. 설치 준비하기 (1) JDK http://java.sun.com 으로부터 JDK를 다운로드하여 설치함 JAVA_HOME을 jdk 설치 디렉토리로 지정함 (2) Tomcat http://tomcat.apache.org 로부터 tomcat을 다운로드하여 설치함 CATALINA_HOME을 tomcat의 설치 디렉토리로 지정함 (3) Hudson http://hudson-ci.org로부터 h..
linux에서 vi를 쓰다보면, 어디에 설치되었는지 모르는 웃지 못할 상황이 생기곤 한다. type/ which 명령어를 써도 명확히 알기 어렵다. 이럴 때!! vi를 실행시킨 상태에서 확인이 가능하다는 사실! :!echo $VIMRUNTIME
