사람을 위한 자동화: 전개 자동화 패턴, Part 2

문서 옵션 PDF - Fits A4 and Letter 149KB (16 pages) Get Adobe® Reader® JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 영어원문  제안 및 의견 피드백

난이도 : 초급

Paul Duvall, CTO, Stelligent

원문 게재일 : 2009 년 2 월 10 일
번역 게재일 : 2009 년 5 월 19 일

Java™ 전개는 복잡하고, 오류가 발생하기 쉬우며, 수작업으로 진행되기 때문에 소프트웨어를 사용자에게 제공하기 전까지 많은 시간이 지연되기도 합니다. 2편의 기사 중 Part 2에서는 자동화 전문가인 필자가 Java 애플리케이션에 대한 원클릭 전개 기능을 제공하는 신뢰할 수 있고, 반복 가능하며 일관된 전개 프로세스를 개발하는 데 도움이 되는 추가 주요 패턴들에 대해 설명합니다.

전개는 자동화에 적합한 소프트웨어 작성 과정의 한 부분이다. 전개를 자동화하면 신뢰할 수 있고 반복 가능한 프로세스의 장점 즉, 정확도, 속도 및 제어를 향상시킬 수 있다. 2편의 기사 중 Part 1에서는 8가지 전개 자동화 패턴에 대해 살펴보았으며 이번 기사에서는 동등한 수준의 장점을 가지고 있는 7가지 전개 방법에 대해 추가로 설명한다.

이 시리즈의 정보 개발자는 사용자를 위해 프로세스를 자동화하는 작업을 수행하지만 정작 자신의 개발 프로세스를 자동화할 수 있는 기회를 간과하는 개발자도 많다. 이러한 개발자를 위해 사람을 위한 자동화 시리즈에서는 소프트웨어 개발 프로세스 자동화의 실제 사례를 살펴보고 자동화를 성공적으로 적용할 수 있는 시기와 방법에 대해 설명한다.

• 바이너리 무결성: 모든 대상 환경에 동일한 아티팩트가 적용되도록 보장한다.
  
  
• 처분 가능한 컨테이너: 전개 오류를 줄이기 위해 대상 환경을 알려진 상태로 유지한다.
  
  
• 원격 전개: 집중식 시스템 또는 클러스터에서 여러 시스템과 통신하여 전개를 수행한다.
  
  
• 데이터베이스 업그레이드: 집중식으로 관리하는 스크립트를 이용한 프로세스를 통해 증분 변경 사항을 데이터베이스에 적용한다.
  
  
• 전개 테스트: 사전 및 사후 전개 검사를 통해 최신 전개를 기반으로 애플리케이션이 예상대로 작동하는지 확인한다.
  
  
• 환경 롤백: 전개에 실패할 경우 애플리케이션 및 데이터베이스 변경 사항을 롤백한다.
  
  
• 보호된 파일: 빌드 시스템에 사용되는 특정 파일에 대한 액세스를 제어한다.

그림 1에서는 이 기사에서 다루는 전개 패턴 간의 관계를 보여 준다. (음영 처리되지 않은 패턴은 Part 1에서 살펴보았다.)

이 기사에서 추가된 7가지 전개 자동화 패턴은 처음 8가지 패턴을 기반으로 하며 원클릭 전개를 작성하는 데 도움이 된다.

한 번의 컴파일만으로 여러 환경에 전개

이름: 바이너리 무결성

패턴: 동일한 태그가 지정된 전개의 경우, 각 대상 환경에서 동일한 아카이브(WAR 또는 EAR)를 사용한다.

안티 패턴: 동일한 태그의 각 대상 환경에 대해 별도의 컴파일을 수행한다.

이 주제에 대해 동료들과 수많은 논의를 해 본 결과, 필자는 모든 대상 환경에서 컴파일 및 패키징을 수행하는 방법보다는 한 번의 컴파일만으로 여러 환경에 전개하는 방법이 보다 효과적이라는 확신을 갖게 되었다. 예를 들어, Java 웹 전개에서는 WAR(Web archive) 또는 EAR(Enterprise archive) 파일이 전개 아티팩트로 생성된다. 이 아카이브는 DEV 환경에서와 같이 버전 제어 저장소에 체크인되어야 하고 하나의 태그가 지정되어야 한다.

그림 2에서는 한 번의 컴파일만으로 여러 환경에 전개 철학에 따라 빌드 시스템에서 생성된 동일한 brewery.war가 각 대상 환경에 전개되는 모습을 보여 준다.

Ant는 빌드 시스템에서 컴파일 및 패키징된 파일이 각 대상 환경에 전개된 파일과 동일하도록 보장하기 위해 MD5(Message-Digest algorithm 5) 해시 알고리즘을 사용하는 checksum 태스크를 제공한다.

아티팩트가 같더라도 대상 환경마다 전개 구성이 다르다는 점에 관한 논쟁이 있다. 즉, 스크립트를 이용한 단일 명령 전개의 경우 여러 자동화된 프로세스가 아카이브의 동일성 여부와 상관 없이 애플리케이션의 출력을 변경할 수 있다. 이러한 문제점이 있다는 것은 사실이지만 소프트웨어가 QA 환경에서 실행된 것과는 다른 버전의 JDK를 사용하여 STAGE 환경에서 컴파일 및 패키징되었기 때문에 문제 해결을 위해 많은 시간을 낭비하게 되는 상황이 발생할 수 있다. 또한 DEV에서 사용된 집중식 종속성 관리 저장소(예: Ivy 또는 Maven)의 JAR이 스테이징 환경의 JAR과 다를 경우에도 오류가 발생할 수 있다. 이러한 위험을 감안하면 바이너리 무결성을 보장하기 위해 컴파일 및 패키징 작업을 한 번만 수행하고 여러 환경에 전개하는 방법이 최선의 방법이 될 것이다.

위로

처분 가능한 컨테이너를 사용하여 전개 비용 절감

이름: 처분 가능한 컨테이너

패턴: 설치와 구성을 분리하여 웹 및 데이터베이스 컨테이너의 설치와 구성을 자동화한다.

안티 패턴: 컨테이너를 각 대상 환경에 수동으로 설치 및 구성한다.

사람을 위한 자동화 기획 기사로 실린 "지속적인 통합 안티 패턴, Part 2"에서는 "오염된" 환경을 정리하는 작업이 오류가 있는 양성 또는 음성 빌드를 방지하는 데 도움이 되는 이유를 살펴보았다. 처분 가능한 컨테이너는 영구적 컨테이너를 사용할 때 발생할 수 있는 수많은 문제점을 줄여 준다. 처분 가능한 컨테이너 패턴은 모든 컨테이너 구성 요소를 완전히 제거하고 컨테이너의 설치와 구성을 분리한다는 두 가지 원칙을 기반으로 한다. 이 패턴은 더 이상 별도의 팀에서 컨테이너를 관리하는 것으로 가정하지 않을 뿐 아니라 개발자나 다른 작업자가 컨테이너를 처리하지 않기 때문에 일부 작업자 특히, 시스템 엔지니어에게는 급진적인 개념으로 보일 수 있다. 하지만 전개 중에 일반적으로 발생하고 비용을 유발하는 문제점을 고려하면 이 패턴은 모든 팀 구성원이 최대로 만족할 수 있는 방법이 될 수 있다.

원클릭 전개 필자는 "당연히 자동화된 전개를 수행하고 있다"고 말하는 팀을 자주 만나보았다. "단일 명령(예: ant)을 입력하여 작업 소프트웨어 애플리케이션을 생성할 수 있습니까?"라는 등의 몇 가지 간단한 질문에 대한 일반적인 답변은 "예, 웹 컨테이너를 설치 및 구성한 후..." 또는 "데이터베이스를 설정한 후에 할 수 있다"는 것이었다. 필자가 정의하는 실질적으로 자동화된 전개는 깨끗한 시스템에 Java 플랫폼 및 Ant를 설치(이 단계를 제외할 수 있는 방법도 있음)한 다음 단일 명령을 통해 작업 소프트웨어 애플리케이션을 전개하는 것이다. 이러한 조건이 충족되지 않아서 "원클릭"으로 전개되지 않는다면 전개 프로세스에서 많은 비용을 초래하는 인적 자원으로 인한 지연 문제가 발생하게 된다.

그림 3에서는 보여 주는 처분 가능한 컨테이너 패턴의 기본 철학은 모든 것이 작업자의 생각이 아닌 시스템에 있어야 한다는 것이다(Part 1에서 설명한 저장소 패턴 사용).

Listing 1의 Ant 스크립트는 인터넷을 통해 Tomcat ZIP 파일을 다운로드하여 남아 있는 이전 전개의 모든 컨테이너를 제거한 후 Tomcat을 추출, 설치 및 시작한다.

<!-- Check to see if Tomcat is running prior to this -->
...
<exec executable="sh" osfamily="unix" dir="${tomcat.home}/bin" spawn="true">
  <env key="NOPAUSE" value="true" />
  <arg line="shutdown.sh" />
</exec>
<delete dir="${tomcat.home}" />
<get src="${tomcat.binary.uri}/${tomcat.binary.file}" 
  dest="${download.dir}/${tomcat.binary.file}" usetimestamp="true"/>
<unzip dest="${target.dir}" src="${download.dir}/${tomcat.binary.file}" />
<exec osfamily="unix" executable="chmod" spawn="true">
  <arg value="+x" />
  <arg file="${tomcat.home}/bin/startup.sh" />
  <arg file="${tomcat.home}/bin/shutdown.sh" />
</exec>
<xmltask source="${appserver.server-xml.file}"
  dest="${appserver.server-xml.file}">
  <attr path="/Server/Service[@name='${s.name}']/Connector[${port='${c.port}']" 
    attr="proxyPort" 
	value="${appserver.external.port}"/>
    <attr path="/Server/Service[${name='${s.name}']/Connector[${port='${c.port}']" 
	attr="proxyName"
	value="${appserver.external.host}"/>
</xmltask>
<!-- Perform other container configuration -->
...
<echo message="Starting tomcat instance at ${tomcat.home} with startup.sh" />
<exec executable="sh" osfamily="unix" dir="${tomcat.home}/bin" spawn="true">
  <env key="NOPAUSE" value="true" />
  <arg line="startup.sh" />
</exec>

환경을 알려진 상태로 유지하고 컨테이너를 제어 가능한 방식으로 전개하게 되면 대부분의 전개 문제의 원인이 되는 여러 가지 일반적인 전개 오류가 줄어든다.

위로

여러 외부 환경에서 명령 실행하기

이름: 원격 전개

패턴: 집중식 시스템 또는 클러스터를 사용하여 여러 대상 환경에 소프트웨어를 전개한다.

안티 패턴: 각 대상 환경의 로컬에서 전개를 수동으로 적용한다.

데이터베이스 및 웹 컨테이너를 설치한 이후에는 일반적으로 개발자의 워크스테이션에서 전개를 실행하게 된다. 하지만 개발 환경과 프로덕션 환경 간에는 큰 차이가 있다. 조직에 여러 프로젝트와 다양한 대상 환경(예: 테스트 또는 스테이지 환경)이 있는 경우에는 단일 환경(단일 시스템 또는 클러스터)에서 중앙 집중식으로 전개를 관리해야 하는 경우도 있다. 또한 팀에서 빌드 서버를 사용하여 이러한 각 대상 환경 간의 전개를 관리하는 경우도 많다. Part 1에서 설명한 헤드리스 실행 패턴은 공용 및 개인용 키를 사용하기 때문에 각 시스템에 수동으로 로그인할 필요가 없다. 그림 4에서 보여 주는 원격 전개는 헤드리스 실행, 단일 명령 및 스크립트를 이용한 전개 패턴을 기반으로 원격 시스템에 전개하는 작업을 쉽게 수행할 수 있도록 지원한다.

집중식 빌드 서버에서 원격으로 소프트웨어를 전개하려면 원격으로 안전하게 명령을 복사 및 실행할 수 있는 메커니즘을 사용해야 한다. 앞으로 설명할 두 메커니즘에서는 SCP(Secure Copy)와 SSH(Secure Shell)를 사용한다. Listing 2에서 보여 주는 스크립트를 이용한 전개에서는 집중식 빌드 시스템에서 생성된 웹 아카이브가 대상 환경에 원격으로 복사된다.

<target name="copy-tomcat-dist">
  <scp file="${basedir}/target/brewery.war" 
  trust="true" 
  keyfile="${basedir}/config/id_dsa"
  username="bobama"
  passphrase=""
  todir="pduvall:G0theD!stance@myhostname:/usr/local/jakarta-tomcat-5.5.20/webapps" />
</target>

WAR 파일을 원격 대상 환경에 안전하게 복사한 후에는 Java Secure Channel의 SSHExec 태스크와 같은 기능을 사용하여 중앙 빌드 시스템에서 원격으로 SSH 명령을 실행할 수 있다. 이에 대한 대안으로 ssh를 통해 원격 환경에 연결하여 명령을 로컬로 실행할 수도 있다. 이 방법을 사용하면 송수신되는 원격 트래픽이 줄어들기 때문에 전개 시간을 단축할 수 있다.

위로

데이터베이스 및 데이터를 알려진 상태로 유지하기

이름: 데이터베이스 업그레이드

패턴: 스크립트와 데이터베이스를 사용하여 증분 변경 사항을 각 대상 환경에 적용한다.

안티 패턴: 데이터베이스 및 데이터 변경 사항을 각 대상 환경에서 수동으로 적용한다.

그림 5에서는 스크립트를 이용한 전개의 일부로서 자동화된 스크립트를 사용하여 데이터베이스를 업데이트하는 예제를 보여 준다.

사람을 위한 자동화 기획 기사로 실린 "손 쉬운 데이터베이스 마이그레이션"에서는 증분 데이터베이스 변경 사항을 자동화된 방식으로 적용해야 하는 필요성을 살펴보았다. 스크립트를 이용한 전개의 다른 부분과 마찬가지로 데이터베이스 업그레이드 스크립트가 저장소에 체크인된다.

LiquiBase(참고자료 참조)는 스크립트를 이용한 전개의 일부로서 동일한 변경 사항이 각 대상 환경에 적용되도록 증분 변경 사항을 데이터베이스에 적용하는 도구이다. Listing 3에서는 LiquiBase 변경 로그의 일부로서 SQL 스크립트가 호출된다. 그런 다음 이 변경 로그(XML로 정의됨)는 스크립트를 이용한 전개(Ant와 같은 빌드 스크립트 도구에서 구현됨)에서 호출된다.

<changeSet id="1" author="jbiden">
  <sqlFile path="insert-distributor-data.sql"/>
</changeSet>

자동화된 데이터베이스 업그레이드를 익히고 적용하기 위해서는 더 많은 내용이 필요하지만 여기에서 중요한 점은 스크립트를 이용한 전개의 일부로서 업그레이드를 수행함으로써 모든 데이터베이스 변경 사항이 작성된 프로시저나 작업자의 생각에만 머무르지 않고 시스템에 반영된다는 점이다.

위로

전개에 대한 스모크 테스트 수행하기

이름: 전개 테스트

패턴: 스크립트를 이용한 전개에 자체 테스트 기능을 스크립트로 작성하여 삽입한다.

안티 패턴: 전개 관련 특성을 고려하지 않은 수동 기능 테스트를 실행하여 전개를 확인한다.

그림 6에서는 전개 전후에 전개 테스트를 실행하는 예제를 보여 준다.

Listing 4에서는 Ant를 사용하여 올바른 버전의 도구를 사용하고 있는지 확인하는 사전 전개 테스트를 수행한다. 스크립트를 이용한 전개에서 스크립트를 다른 내부 전개 테스트와 함께 사용하여 사용 중인 기존 포트(웹 컨테이너 전개의 실패 원인이 될 수 있음)를 검사하고, 데이터베이스 연결을 확인하고, 컨테이너의 시작 여부를 확인할 수 있다.

<condition property="ant.version.success">
  <antversion atleast="${ant.check.version}" />
</condition>
<antunit:assertPropertyEquals name="ant.version.success" value="true" />
<echo message="Ant version is correct." />
<echo message="Validating Java version..."/>
<condition property="java.major.version.correct">
  <equals arg1="${ant.java.version}" arg2="${java.check.version.major}" />
</condition>
<antunit:assertTrue message="Your Java SDK version must be 1.5+. \
  You must install correct version.">
  <isset property="java.major.version.correct"/>
</antunit:assertTrue>

보다 강력한 전개 테스트를 사용하여 애플리케이션의 기능이 올바른지도 확인할 수 있다. Selenium(웹 애플리케이션의 경우) 또는 Abbot(클라이언트 애플리케이션의 경우)과 같은 도구에서 전개 관련 자동화된 기능 테스트를 작성하여 전개 변경 사항이 올바르게 적용되었는지 확인할 수 있다. 일종의 스모크 테스트라고 할 수 있는 이들 테스트를 수행할 경우에는 전개의 영향을 받는 기능만 테스트하면 된다. 예를 들어, 표 1에서는 Selenium 및 기타 도구를 웹 애플리케이션에 사용하는 방법을 보여 준다.

자동화된 테스트는 사용자 기능만을 테스트하기 위한 것이 아니다. 전개 테스트에 중점을 둔 자동화된 테스트를 작성하여 전개의 효과를 확인하고 다운스트림 오류 및 개발 비용을 줄일 수 있다.

위로

모든 전개 변경 사항 롤백하기

이름: 환경 롤백

패턴: 전개 실패 후 변경 사항을 롤백하는 자동화된 단일 명령을 제공한다.

안티 패턴: 애플리케이션 및 데이터베이스 변경 사항을 수동으로 롤백한다.

그림 7에서는 데이터베이스 업그레이드와 웹 전개를 롤백하는 자동화 프로세스를 함께 사용하여 데이터베이스 변경 사항을 롤백하는 방법을 보여 준다.

전개의 자동화 여부와 상관 없이 전개에 문제가 있을 경우 변경 사항을 롤백할 수 있는 방법을 가지고 있어야 한다. 변경 사항의 오류로 인해 시스템이 중단되어 수백만 달러의 비용 손실이 발생할 수도 있다. 환경 롤백을 수행하려면 대상 환경을 전개 이전의 상태로 되돌려 놓아야 한다. 이를 위해서는 모든 변경 사항에 대한 롤백 스크립트가 있어야 한다. 웹 전개의 경우에는 종종 더 많은 변경 사항을 롤백해야 한다. 환경 롤백의 한 예로 전개 전에 아카이브(예: WAR 파일)를 복사한 후 각 변경 사항에 대한 롤백 데이터베이스 스크립트를 제공하는 방법이 있다. 또한 이 경우에는 웹 컨테이너에 적용된 구성 변경 사항을 다시 적용해야 한다.

Listing 6에서는 LiquiBase를 사용하여 각 롤포워드 명령문에 대한 롤백 명령문을 제공하는 예제를 보여 준다. 이 Listing에서는 brewery라는 새 테이블을 추가하고 해당 dropTable 롤백 명령문을 제공한다.

<changeSet id="rollback-database-changes" author="bobama">
  <createTable tableName="brewery">
    <column name="id" type="int"/>
  </createTable>
  <rollback>
    <dropTable tableName="brewery"/>
  </rollback>
</changeSet>

이 간단한 예제는 롤백을 자세히 설명하기 위한 것이 아니라 롤백에 대한 개요를 보여 주기 위한 것이다. 이전 전개로 되돌리기 위해서는 종종 복잡하고 많은 시간이 소요되는 프로세스를 수행(및 자동화)해야 한다. 롤백 스크립트를 작성하는 데 투자한 시간은 전개 실패로 인한 비용 손실과 비례해야 한다.

위로

악의적 사용자로부터 정보 보호

이름: 보호된 파일

패턴: 저장소를 사용하면서 권한이 있는 팀 구성원 간에만 파일을 공유한다.

안티 패턴: 팀 구성원의 시스템에서 파일을 관리하거나 권한이 있는 팀 구성원이 액세스할 수 있는 공유 드라이브에 파일을 저장한다.

그림 8에서는 권한이 있는 사용자 또는 시스템만 액세스할 수 있는 파일을 호스트하는 데 사용되는 보호된 버전 제어 저장소를 보여 준다.

일부 팀 구성원의 경우에는 환경 관련 데이터에 액세스할 필요가 없는 경우도 있다. 하지만 이 정보를 전개 스크립트와 분리해 놓으면 스크립트가 실행되는 것을 방지할 수 있다. 이 기사에서는 헤드리스 실행 패턴을 설명할 때 SSH 키를 Java Secure Channel 도구와 함께 사용함으로써 사용자가 명령을 입력하지 않고도 안전하게 파일을 복사하고 원격 명령을 실행하는 방법을 살펴보았다. 외부화된 구성에 사용되는 특성에는 일부 팀 구성원만 볼 수 있으면 되는 데이터가 들어 있을 수 있다. 악의적 사용자로부터 .properties 파일의 데이터를 보호하면서 헤드리스 실행을 보장하기 위해 이 기사에서는 이러한 파일을 보호된 저장소에 체크인하는 방법을 사용하였다.

Listing 7에서는 특정 디렉토리에 대한 모든 사용자의 액세스를 거부하도록 Apache에서 호스트되는 Subversion 저장소를 구성한 후 특정 사용자를 명시적으로 추가하는 방법을 보여 준다.

<DirectoryMatch "^/.*/(\.svn)/">
  Order deny,allow
  Deny from all 
  Allow bobama,jbiden,hclinton
</DirectoryMatch>

Subversion 저장소에 대한 액세스를 보호하게 되면 스크립트를 이용한 전개에서 암호 요청을 받지 않고 허용된 사용자 중 하나로서 특성에 액세스하여 SSH 키에 정의된 방식으로 헤드리스 실행을 제공할 수 있다.

위로

원클릭 전개

필자는 이 두 편의 기사에서 설명한 15가지 패턴 외에도 여러 가지 전개 자동화 패턴을 추가로 분류하고 있기는 하지만 이러한 15가지 패턴은 필자가 경험한 전개 상황의 80%를 차지한다. 이들 각각의 패턴은 문자 그대로 각각의 모든 대상 환경에 대한 원클릭/단일 명령 전개를 수행하는 데 필요한 도움을 주기 위한 것이다. 이 기사가 전개 작업의 수고를 덜어줄 수 있기를 바란다.

시리즈를 마치면서

이 기사는 사람을 위한 자동화 시리즈의 마지막 기사이다. 필자의 경험을 나누었던 지난 2년여의 시간은 필자에게 매우 흥미진진한 모험의 시간이었다. 이 시리즈는 언제나 반복적이고 오류 가능성이 높은 활동에 얽매이지 않고 흥미로운 문제에 집중할 수 있도록 여러 가지 소프트웨어 개발 프로세스를 자동화하는 방법과 그 이유를 설명하는 데 목적을 두고 있었다. 이 시리즈에서는 적절한 리팩터링을 수행하기 위해 코드 검토를 자동화하는 방법, 애플리케이션 데이터베이스를 증분 방식으로 업그레이드하는 방법, Continuous Integration 사례 및 도구를 적용하는 방법, 모든 변경 사항을 사용하여 자동화된 테스트를 실행하는 방법, GUI 설치 프로그램을 생성하는 방법, 원클릭 전개를 작성하는 방법, 개발자 문서 생성을 자동화하는 방법, 종속성 관리를 수행하는 방법, 버전 제어 저장소를 활용하는 방법 및 다양한 빌드 스크립트 및 도구를 효과적으로 활용하는 방법을 살펴보았다. 필자가 이 시리즈를 쓰면서 느꼈던 즐거움을 여러분도 이 시리즈를 읽으면서 느낄 수 있기를 바란다.

참고자료

• "전개 자동화 패턴, Part 1"(Paul Duvall 저, developerWorks, 2009년 1월): 원클릭 전개 패턴에 대한 설명을 볼 수 있다.
  
  
• Software Configuration Management Patterns(Stephen Bercuzk 및 Brad Appleton 저, Addison-Wesley Professional, 2003년): 저장소 패턴 및 기타 여러 가지 소프트웨어 구성 관리 패턴에 대한 설명을 볼 수 있다.
  
  
• Patterns of Deployment: HP Lab의 SmartFrog wiki에서 여러 가지 전개 패턴의 카탈로그를 볼 수 있다.
  
  
• Continuous Integration: Improving Software Quality and Reducing Risk(Paul Duvall, Steve Matyas 및 Andrew Glover 저, Addison-Wesley Signature Series, 2007년): 8장 Continuous Deployment에서는 전개를 자동화된 프로세스로 통합하는 예제를 볼 수 있다.
  
  
• Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Apps(Mike Clark 저, The Pragmatic Programmers, 2004년): 항상 신뢰할 수 있고 정확한 프로그래밍 방식의 자동화된 자동 소프트웨어 프로덕션을 즐기자.
  
  
• Release It!: Design and Deploy Production-Ready Software(Michael T. Nygard 저, The Pragmatic Programmers, 2007년): 이 책은 새벽 3시에 호출되는 것을 원하지 않는 개발자에게 많은 도움을 줄 것이다.
  
  
• "자동화를 통한 신속한 전개"(Paul Duvall 저, IBM developerWorks, 2008년 1월): 자동화를 활용하여 다른 환경에 소프트웨어를 빠르게 이동시키는 방법을 설명한다.
  
  
• "지속적인 통합 안티 패턴, Part 2"(Paul Duvall 저, IBM developerWorks, 2008년 3월): 손쉬운 CI 작업을 위해 피해야 할 패턴에 대해 설명한다.
  
  
• "손 쉬운 데이터베이스 마이그레이션"(Paul Duvall 저, IBM developerWorks, 2008년 8월): LiquiBase를 사용하여 데이터베이스 변경을 관리하는 방법에 대해 설명한다.
  
  
• 기술 서점에서 다양한 기술 주제와 관련된 서적을 살펴보자.
  
  
• developerWorks Java 기술 영역: Java 프로그래밍과 관련된 모든 주제를 다루는 여러 편의 기사를 찾아보자.
  
  

• Ant: Ant를 다운로드하여 예측 가능하고 반복 가능한 방식으로 소프트웨어 빌드를 시작하자.
  
  
• JSch: Java Secure Channel을 다운로드하여 보안 통신에 활용할 수 있다.
  
  
• Selenium: Selenium을 다운로드하여 전개 관련 기능 테스트를 수행할 수 있다.
  
  
• LiquiBase: LiquiBase를 다운로드하여 자동화된 데이터베이스 마이그레이션을 수행할 수 있다.
  
  
• Abbot: Abbot을 다운로드하여 전개 중심적 기능 테스트를 수행할 수 있다.
  
  

• Improve Your Code Quality 토론 포럼: 이 토론 포럼에서는 코드 품질 향상과 관련된 질문에 대한 developerWorks의 정기 기고자인 Andrew Glover의 전문성 높은 답변을 볼 수 있다.
  
  
• Accelerate development space: developerWorks의 정기 기고자인 Andrew Glover가 개발자 테스트, 지속적인 통합, 코드 메트릭 및 리팩토링에 관한 모든 사항을 다루는 원스톱 포털을 호스트한다.
  
  
• developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.

필자소개

		Paul Duball은 Stelligent Incorporated의 CTO로, 개발팀이 배포 준비가 된 소프트웨어를 도출할 수 있도록 돕는 애자일 컨설팅을 하고 있다. Paul Duball은 Addison-Wesley 시그너처 시리즈 책인, Continuous Integration: Improving Software Quality and Reducing Risk(Addison-Wesley Professional, 2007년, 2008 졸트 상 수상작)의 공동 저자이기도 하다. 또 UML 2 Toolkit(Wiley, 2003년)과 No Fluff Just Stuff Anthology(Programatic Programmers, 2007년)에도 기여했다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로