'ALM'에 해당되는 글 2건

  1. 프로젝트를 github와 빠르게 연동하기!
  2. 빌드와 테스트를 한방에! 1편 jenkins 환경구축

처음부터 github를 통해 프로젝트를 생성해서 clone 하지 않고, 

기존에 진행하던 프로젝트가 있는데 뭐 불편하게 clone 해서 파일 복사하고 ...

지지고 볶고 할 필요 없이 간단하게 remote 정보만 추가해서 하는 방법에 대해서 정리한다. 

* 매번 할 때 마다 까먹는다


1. github에서 repositories에서 new 를 해서 적당한 프로젝트명과, 설명을 넣는다.

https://github.com/FiaDot/scala-json-serialize.git


2. 디렉토리 생성 (프로젝트명 : scala-json-serialize )

mkdir scala-json-serialize


3. git bash 실행

git remote add origin https://github.com/FiaDot/scala-json-serialize.git

git pull origin master







연재 계획

1편 jenkins 환경구축

2편 native cpp(msvc) + boost test framework

3편 spring + junit + maven

4편 Troubleshooting



상황!

#1 Windows 

MS Visual Studio를 이용하여 개발하고 Native C++, C# 프로젝트가 있다. 이 프로젝트들은 Windows Server에서 운영된다. 유닛테스트 프레임워크로 boost test를 사용한다. 추가적으로 Python으로 작성된 스크립트를 이용해 몇몇 데이터를 변환해서 배포전에 수행해야 한다. 프로젝트에 따라서는 SVN에서 몇몇 리소스를 받아 DB에 저장하는 단계가 포함 된다.


#2 Linux 

Spring framework + Junit 을 이용해 개발하는 Application Server가 있으며 Cent OS(Linux)에서 운영된다. maven을 이용해서 test, deploy 를 수행한다.


#3 Unity for android, ios

유니티 프로젝트를 수행할 경우 안드로이드 빌드와 ios빌드, 빠른 테스트를 위해 PC버젼까지 빌드해야 한다.


모든 소스는 SVN을 저장소로 이용하고 있으며, 개별 빌드와 배포를 수동으로 하면 1시간 이상이 소요된다. 사람이 하기에 가끔씩 배포시 단계를 빼먹고 난감한 상황이 연출 될 때도 있다.


요약> 여러환경에서 개발되고, 다양한 환경에 배포를 해야되는 상황에서 빌드, 배포 과정에서 사람의 실수가 발생 할 수 있다.



우리에게 필요한건 CI!

일반적으로 빌드하면 컴파일, 링크만 생각하기도 하는데 좀 더 큰 범주에서 생각해보자. 우리가 하고자 하는건 어떠한 코드를 작성하고 최종적으로 본인이 사용하던지, 서비스로서 타인에게 제공되기도 한다. 이런 환경에서 빌드를 하게 되면 테스트를 진행한 후 배포를 하게 된다. 물론 사람이 손으로 일일이 하는 경우도 있을것이고, test framework을 도입해서 자동화 했을 수도 있다. 어쨌든 컴파일에러가 없다고 배포를 해도 된다는 위험한 발상을 가지지는 않을 것이다. 지금은 unit test, regression test 등 test 에 대한 내용은 아니기에 자세한 내용은 생략한다. 


여튼 요구사항의 변경, 리펙토링, 신규 투입인력의 잘못된 사용으로 인한 에러등 무수히 많은 상황에서 빌드가 깨지기도 하고, 테스트가 실패하기도 하는데 이를 자동화 해서 적정시점에 알려줄 수 있다면? 그리고 우리는 빌드를 위해 키보드에서 손놓고 커피타임과 담배타임으로 업무시간을 뺏기지 않고 칼퇴근을 이룩할 수 있다면 이보다 더 좋은것이 어디 있겠는가?! 


요약> 품질과 안정성을 위해 빌드와 테스트를 자동화하면 칼퇴근 확률을 높일 수 있다.



Jenkins?


Cruise Control.Net, Hudson, jenkins 결국 다 빌드를 자동화 하자는게 핵심이다. 근데 CC.Net은 설정이 너무 복잡하다. 6년전쯤으로 기억되는데 프로젝트 4개정도에 CC.Net을 도입하는데 1주일 정도가 소요되고 불의의 사고로 서버가 죽었는데(HW문제), 그 뒤로는 해당프로젝트에서 환경구축을 하지 않았다. 너무 귀찮다는 느낌이 강하다. Hudson 개발자들이 나와서 jenkins를 만들었다고 하니 jenkins 1표! 장점은 웹에서 모든 설정을 다 할 수 있고, 설정이 간편하다. 그리고 다양한 플러그인을 통해 왠만한건 다 할 수 있다. 



빠르게 시작하기!


http://jenkins-ci.org/


웹서버가 구축되어 있다면 war 파일 다운로드 받아서 사용하면 된다. 웹서버가 구축되어 있지 않더라도 war 파일을 독립적으로 실행 할 수 있다.

  java -jar jenkins.war --httpPort=8080

위의 방식으로 실행한 뒤 웹 브라우져에서 http://localhost:8080/jenkins 로 접속하면 바로 화면을 볼 수 있다.


각 OS에 맞게 설치패키지를 다운받아서 사용 할 수도 있다. 개발용 windows server가 한대 있어서 windows native package를 다운로드 받아서 설치 했다.

설치시 경로는 되도록 빈칸을 빼고 설치하기를 권장한다. 몇몇 플러그인이나 빌드 환경에 따라서 파일을 못 읽어오는 경우도 있다. (특히 윈도우!)

그래서, 깔끔하게 C:\Jenkins에 설치했다.


환경설정

설치가 완료되었으면 기본적으로 플러그인 몇개를 깔아줘야 한다. MSBuild, Subversion, xUnit plugin 이다. 



필터에 방금 언급한 플러그인 이름을 넣으면 잘 걸러서 보여준다. 앞에 체크 박스를 선택하고 제일 하단에 "재시작 없이 설치하기"를 누르면 설치된다.  

이제 설치된 플러그인에 맞는 정보와 각종 환경 설정을 할 차례다.


Jenkins 관리 - 시스템 설정에 들어가면 뭐가 많이 보인다. 자바를 사용한다면 Maven, JDK, Ant 등의 정보를 넣고 MSBuild에 경로 정보를 ... 이렇게 말하면 너무 귀차니즘에 차있는거 같으니, 그냥 이미지로 보자. ㅡㅡ;

JDK는 대부분 JDK_HOME 등의 정보로 자동으로 되긴 하지만, JDK를 여러개 사용하는 관계로 경로를 지정해주었다. MSBuild는 자동으로 안되고 해당 경로에 MSBuild가 있는지 확인해야 한다. 64비트 빌드시에도 Framework64를 사용하지 않고 Framework 경로를 사용한다는것에 유의한다.



Maven 경로도 수동으로 적어줘야 한다. Jenkins Location 정보는 현재 사용되는 서버 주소와 jenkins에서 빌드가 깨졌을 때 메일을 보내줄때 sender의 메일 주소를 적어주면 된다. 넣어줘야 메일 필터링 하기가 좋다. (실제 계정은 없어도 무관하다.) E-mail로 알려줌 SMTP 서버 정보를 넣어준다.  SMTP설정이 제대로 되었는지 확인하기 위해서 Test Configuration by sending test e-mail 체크를 하고 Test e-mail recipient에 메일 주소를 넣어주고 Test configuration을  선택해서 메일이 잘 오는지 확인한다. 잘온다. 그럼 된것이다. 저장하고 마무리!


보안설정

안그래도 은행권, 통신사 보안 얘기가 빵빵 터지는 지금의 상황에서, 우리도 보안에 관심을 가지자... 라고 하는것은 아니고. 최소한 외부에서 접근가능한 서버라면 해줄 필요가 있겠다.

보안설정이라고 복잡할 것이 없다. Jenkins 관리 - Configure Global Security 에 들어가보자. 보안 사용을 선택해주고 사용자 가입을 허용 해주고, 계정을 추가하고, 권한을 주면 된다. 



맺음말

글로 쓰니 길어보이지만 실제 셋팅에 걸리는 시간은 10분도 안걸린다. 실제 item 추가 방법에 대해서는 다음에... 오랜만에 포스팅을 하자니 은근 피곤하다. jenkins 설정과 관련해 검색해보면 많이 나오지만 OS에 따라서 환경변수도 다르고, 실제 사용된 값이 적혀있었다면 좀 더 쉽게 했을텐데 하는 아쉬움에 포스팅을 하게됐다.


현재 셋팅된 프로젝트를 한번 찍어봤다. 하나의 프로젝트에 비가오고 있다. 나의 마음 같구나~ ㅠㅠ