[프로세스/관리]개인프로젝트를 위한 개발환경 구축 – 1

전부터 개인적으로 만들어보고 싶은 프로그램들이 있었지만 차일피일 미루고 있던 것을

이제서야 “천리길도 한걸음부터..!“인것처럼 본격적으로 시작하기 전에

개발환경구축을 먼저 진행했다.

(1) IDE(Integrated Development Environment) 

통합개발환경은 STS(Spring Tool Suite) 3.2.0.RELEASE 버전을 사용했다.

스프링 프레임워크 기반의 웹 프로젝트로 진행할 것이기 때문에 프로젝트를 만들기 위해

[Spring Template Project => Spring MVC Project => Project name, 기본 패키지

세팅] 을 진행해 간단하게 웹기반의 MVC 프로젝트를 만들었다.

sample6 sample7 sample8

프로젝트가 생성되면 Maven이 자동으로 빌드도구로 선택된다.

난 이번에 Maven대신 Gradle을 사용할 것이기 때문에 .project 파일에 Maven관련

설정을 모두 제거했다. 그러면 프로젝트에서 Maven관련 아이콘이 사라진다.

sample12

(2) JDK/TOMCAT(Servlet/JSP container) 버전

사실 IDE선정에 앞서 JDK버전 명시를 해야 하는데 순서가 뒤바뀌었다.

JDK는 1.6(1.7을 공부하지 않아서인지 아직까진 딱히 필요성을 느끼지 못함),

Tomcat은 7.0.34를 사용했다. 그리고 STS에 Tomcat을 추가했다.

sample9

(3) 빌드도구 선정

작년에 오픈소스 프로젝트를 하면서, 이클립스를 사용할 수 없는 우분투OS를 사용하는

리눅스환경에서 빌드환경을 구축해놓지 않아 무척 고생한 기억이 있다.

같은 실수를 반복하지 않기 위해 이번엔 시작부터 빌드도구로 회사에서 사용하고 있는

Gradle 1.6버전을 사용했다.(압축파일을 풀고 시스템변수 Path에 Gradle bin경로를 입력함)

Gradle로 빌드뿐만 아니라 Test, 배포까지 모두 커버할 수 있다.

sample10

(4) build.gradle 기본설정하기

다음은 Gradle로 프로젝트를 빌드하기 위한 build.gradle파일에 기본설정을 추가했다.

우선, 단일 프로젝트로 프로젝트를 생성했기 때문에 멀티프로젝트 빌드의 경우는 제외하고

Gradle이 빌드 실행시 인식할 수 있게 프로젝트루트에 build.gradle 파일을 만들었다.

아래 목록은 프로젝트에 사용할 기술에 대한 의존성 설정에 대한 내용이다

  • Spring버전은 3.1.1.RELEASE
  • 프로젝트에서 데이터접근계층을 구현하기 위한 API로는 JPA(Java Persistence API)
  • JPA 구현체는 Hibernate
  • Spring Data를 사용해서 데이터접근계층의 구현에 대한 노력을 덜게끔 함
  • DataBase는 Mysql
  • DBCP(DataBase Connection Pooling)는 BoneCP 사용
  • 유닛테스트를 작성하기 위해 Junit과 Mockito 사용

사실, Gradle을 공부하는 중에 처음 빌드파일을 작성하면서 가장 고생한 것은

바로 “의존성(dependencies)“추가였다.

각 라이브러리가 의존해서 쓰고 있는 동일 라이브러리의 버전이 충돌하면서 계속

컴파일을 해가며 이 버전을 맞추는데 시간을 보냈다.

sample5

버전충돌을 모두 해결하고, 빌드파일 설정이 끝나면 eclipse 태스크를 실행시켜

이클립스에서 해당 프로젝트를 import 할 수 있게 한다.

sample4

(5) 간단한 유닛테스트 작성 : 트랜잭션 롤백 테스트

빌드파일 작성이 힘들긴 했지만, 예전에 WEB-INF/lib 폴더에 하나씩 jar파일을 넣어가며

세팅했을 때와 비교해서, 자동으로 의존성관리를 해주니 편하게 프로젝트 세팅을 마쳤다.

그럼 이제 세팅한 프로젝트가 잘 돌아가는지 간단하게 트랜잭션 롤백에 대해 간단한

유닛테스트를 작성했다.


package com.sameple.test.service;

import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.annotation.Rollback;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.util.ReflectionTestUtils;
import org.springframework.transaction.annotation.Transactional;

import com.sample.test.domain.Member;
import com.sample.test.repository.MemberRepository;
import com.sample.test.service.MemberService;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("classpath:test-root-context.xml")
public class MemberServiceTest {
    @Autowired
    private MemberRepository memberRepository;

    private MemberService service = new MemberService();

    private Member member = new Member();

    @Before
    public void setup() {
        member.setNo(1L);
        member.setUserId("bluepoet12");
        member.setPassword("test1234");
        member.setNickName("파란시인");

        ReflectionTestUtils.setField(service, "memberRepository", memberRepository);
    }

    @Transactional
    @Rollback(false)
    @Test
    public void modifyMember() {
        service.modifyMember(member);
    }
}

소스는 간단하다. Member 도메인 클래스에 대한 CRUD중 transaction이 들어가는

수정에 대한 테스트케이스를 추가해서 실행했다.

iBatis같은 Sql Mapping 프레임워크를 사용하였다면 저렇게 간단한 Member수정도

별도의 sql문을 작성하고 데이터접근계층에 대한 구현도 복잡했겠지만,

JPA와 Spring Data를 사용하고 나선 아래 한줄로 Member 수정이 끝난다.

 service.modifyMember(member);

더군다나, 데이터접근계층 구현을 위해 별도의 클래스가 필요하지 않고 오직 필요한건

JpaRepository를 상속한 MemberRepository 인터페이스를 정의해주는건만으로 충분하다.

런타임시 해당 인터페이스를 구현한 객체를 Spring Data가 동적으로 만들어주기 때문이다.

그리고 테스트시 @Transactional 어노테이션을 붙이면 테스트 실행시 자동으로

트랜잭션 관리를 해준다.

다만, 실제코드와 차이는 트랜잭션이 끝나는 시점에 자동으로 롤백된다는 점이다.

강제로 DB에 반영시키기 위해선 위의 예제코드처럼 @Rollback(false)를 넣어주면 된다.

sample11

(5) 마치며..

앞서 얘기한대로, 빌드파일의 의존성관리 부분을 제외하곤 비교적 순조롭게 세팅이

진행되었다.

앞으로 개인프로젝트를 진행하면서 쓰게될 포스팅은 아래 내용이 들어갈 것이다.

  • 추가될 다양한 라이브러리들, 그리고 그에 맞춰 수정될 빌드파일(의존성관리)
  • 의존성관리외 빌드와 배포에 필요한 Gradle Task 정의, 필요시 멀티프로젝트 고려
  • 서비스 설계시 작성한 UML과 지속적인 리팩토링, 이를 뒷받침하는 테스트코드 작성
  • 단, 테스트코드 작성은 위험성이 크고 꼭 체크가 필요한 지점에 한함
  • 개인서버에 배포시 필요한 배포관련툴(http://gant.codehaus.org/)
  • CI연동, 코드품질관리/테스트커버리지/단위테스트결과 리포팅

이제 내가 만들고 싶은 프로그램에 대한 어려운 첫 발자국을 내딛게 되었다^^

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

w

%s에 연결하는 중