2012-04-11 5 views
0

웹 응용 프로그램의 연속 통합 시스템에 대한 배포 옵션을 찾고 있습니다. 우리는 하나의 .war 파일을 만들고 있습니다. 여러 다른 환경 (예 : DEV, QA, STAGE 등)에 배포해야합니다. AFAIK의 ENV 특정 속성을 전달하는 두 가지 방법이 있습니다 : Tomcat을 시작할 때env 특정 속성을 웹 응용 프로그램으로 전달

먼저, -D 옵션을 사용

-Denv=DEV 

이 모든 ENV의 catalina.sh 스크립트를 사용자 정의 우리를 필요로한다.

둘째, Tomcat을 실행하기 전에 환경 변수를 사용

export env=DEV; 

이 각 ENV에 대한 배포 스크립트를 조정할 우리를 필요로한다. 플랫폼에 따라 달라집니다 (예 : Windows에서 set env=DEV해야 함).

아무도이 두 가지 옵션 중 어느 것이 더 낫다고 말할 수 있습니까? 아니면 다른 좋은 것들이 있습니까?

답변

0

Google은 14 개의 서로 다른 환경에 배포되는 웹 앱을 보유하고 있습니다. 이를 관리하기 위해 각 환경에 맞는 고유 한 빌드를 만듭니다.

우리는 빌드 시스템으로 maven을 사용하므로 각 환경마다 고유 한 프로파일이 있습니다. 프로파일은 환경에 따라 다른 구성을 포함하는 필터링을위한 특성 파일을 참조합니다. 이 정보는 Spring 컨텍스트 파일 인 web.xml, weblogic.xml 등으로 토큰 화됩니다. (우리는 소스 파일을 추악 해지기 때문에 필터링하지 않습니다.)

두 번째 부분은 Jenkins CI 서버입니다. 해당 프로필을 참조하는 각 환경에 대한 작업이 있습니다. 이것은 Subversion repo의 잘 알려진 태그 이름을 가리 킵니다. 따라서 흐름은 다음과 같이 진행됩니다.

  1. 개발이 진행되고 코드가 트렁크에 적용됩니다.
  2. 일부 env를 빌드해야하므로 "latest"라는 태그를 만듭니다 (존재하는 경우 오래된 복사본을 제거). 동시에 날짜 - 시간 스탬프가있는 태그도 만들지 만 선택 사항입니다.
  3. 적절한 허드슨 빌드를 시작합니다. 이는 우리가 일부 개발자 워크 스테이션을 구축하지 않고 빌드가 이미 구성되어있어 기억할 것이 없다는 것을 의미합니다.
  4. 젠킨스에서 바로 배포 할 이슈를 당깁니다.

나는 응용 프로그램 서버 자체 내에서 유지 응용 프로그램 구성을 본 적이 있지만 당신이 일을 관리 할 수 ​​glu 같은 것을하지 않는 한, 신속하게 유지하기 악몽이된다. 개발 및 운영팀마다 다른 팀이있는 경우 특히 그렇습니다.

+0

우리는 Maven을 구축하고 있습니다. 그러나 우리는 모든 환경에 대해 하나의 빌드를 유지하고자합니다. 우리는 모든 app 설정 파일이 war 파일 외부에 상주하는 방식으로 프로젝트를 설계했습니다 (구성 변경으로 인해 Maven 빌드가 트리거되지 않음). 배포하는 동안 해당 속성 파일을로드 할 수 있도록 env 이름 (DEV, QA 등)을 응용 프로그램에 전달해야합니다. – scabbage

+0

커플 생각 : –

+0

1) 외부에서 설정을 준비 중이라면 왜 env 식별자가 필요합니까? 해당 env에 대한 적절한 config 파일이 배포되지 않았습니까? 2) 전에 env를 식별하기 위해 로컬 호스트 이름을 사용했습니다. 이것은 어딘가에 매핑 테이블을 가지고 있음을 의미합니다. –

관련 문제