2010-04-08 2 views
3

BizTalk 2006 응용 프로그램 서버가 여러 개 있습니다. 우리 프로젝트의 버전을 동기화하는 것이 거의 불가능합니다. MSI 패키지를 배포하고, 가져오고, GAC에서 파일을 일치시키고, 레지스트리 변경 사항을 배포하는 지루한 프로세스입니다. 한 단계를 놓친 경우 나 누군가가 DLL의 업데이트 된 복사본을 다른 서버가 아닌 다른 서버에 직접 배포 한 경우 알기 쉬운 방법.여러 BizTalk 프런트 엔드에 배포 된 코드를 동기화 된 상태로 유지하는 방법은 무엇입니까?

다른 사람들은 두 서버 간의 소프트웨어 복사본이 동일한 버전임을 어떻게 확인합니까?


일부 배경 :

우리의 환경이 클러스터되지 않은 BizTalk 프런트 엔드 서버와 별도의 데이터베이스 백엔드가 있습니다. 최근까지 프런트 엔드를 모두 구성했지만 문제 해결을 위해 두 번째 서버에서 호스트 인스턴스가 중지되었습니다. 수개월 동안 장애인이었고 그동안 업데이트 된 코드가 배포되었습니다.

오늘 아침에 배포 된 프로젝트 (두 서버의 C : \ OurProject \)에 대한 DLL의 로컬 디스크 복사본을 보유하고있는 폴더와 GAC의 폴더 비교를 수행했습니다. 파일 크기, 동일한 시간 소인. 그러나 두 번째 서비스 집합을 설정하면 Server2가 프로젝트 DLL의 이전 버전을 사용하고 있음을 알게되었습니다. 다음 세 파일은 처리되고 두 개는 정상적인 결과가 나오고 한 개는 분명히 구식입니다.

동맥류를 피하십시오.

답변

3

조사하고 싶은 한 가지는 BizTalk Deployment Framework입니다.

우리는 현재 BizTalk 2009로 새로운 환경을 구축하고 있으며 BTSTask를 사용하여 SubVersion에서 소스를 내보내고 어셈블리를 빌드하고 배포하는 일련의 MSBuild 스크립트를 시작했습니다.

물론 BTSTask에는 많은 기능 (시작/중지 응용 프로그램)이 없지만 적어도 BizTalk 2006에는 BTSControl이 있습니다.

2

우리는 궁극적 인 끝이 Dev/Stage/Prod에 대한 바인딩 파일이있는 MSI 인 자동화 된 빌드 스크립트를 사용합니다. 릴리스 된 모든 바인딩 파일은 공유에 저장되며 BizTalk Server를 수동으로로드하는 데 사용됩니다. 먼저 App이 중지되고 MSI가 두 서버에서 실행 된 다음 MSI가 가져옵니다. 가져 오기 중에 바인딩 및 환경에 대한 환경을 지정합니다. 우리는 동기화 손실과 관련하여 문제가 없었습니다.

그래서 모든 최신 MSI를 가져 와서 차이점이있는 서버에서 다시 실행하는 것이 좋습니다. 그렇지 않으면 손으로 반복 가능한로드 프로세스를 만들기 위해 프로세스를 제자리에 두십시오.