2011-02-02 3 views
2

저는 사업 부서와 책임을 분리하기 위해 노력하는 기업의 개발 그룹에서 일합니다. 예를 들어 저는 개발 그룹에 속해 있으며 응용 프로그램 개발과 관련된 모든 업무를 담당합니다. dbas와 같은 다른 역할 또는 그룹 외부의 운영 역할을 담당하며 배포, 서버 유지 관리 등을 담당합니다.비주얼 스튜디오 public & web.config 변형 기능

게시 웹 응용 프로그램 기능과 같은 VS의 기능을보고 있습니다. web.config에서 기능을 변환하고 블로그 및 기타 여러 장소에서 해당 기능을 읽습니다. 필자가 읽은 대부분의 내용을 기반으로 작성자는 개발자가 웹 구성 변환의 여러 환경에 대한 연결 문자열, 사용자 이름, 암호 등을 관리한다고 가정하고 있으며 일종의 생산 서버에서 서버를 게시합니다 환경 (라이브 또는 테스트 또는 준비 등). 예 : here. 우리 환경에서는 다른 사람들도 생각해 보지만 시나리오는 일반적으로 묘사되는 것보다 다소 복잡합니다. 개발 그룹은 그들이 개발 한 것이 배포 된 곳을 알 수 없습니다. 관리자는 환경의 특성에 따라 서버, 데이터베이스 등을 이동하고 구성을 업데이트 할 수 있습니다. 따라서 이러한 경우에 web.config가 어떻게 도움이됩니까? 게시는 여전히 배포 패키지의 아티팩트를 빌드하는 데 로컬로 사용될 수 있지만 대신 자동화 된 빌드 관리자를 사용하려고 할 수도 있습니다.

그래서 게시와 변환은 개발과 작업 사이의 장벽이 매우 회색 인보다 기초적인 개발 프로세스에 더 적합합니다. 또는 나는 무엇인가 놓치고 있냐? 이런 종류의 것에 대해 내가 읽었던 많은 것들이 좋은 의도를 가지고 있지만 더 정의 된 개발 과정의 맥락에서 다소 피상적 인 것처럼 보인다.

다른 사람들의 의견과 경험을 알고 싶습니다.

답변

1

다른 방법으로 구성 변환을 사용할 수 있습니다. 당신 말이 맞아요. 대부분의 샘플은 한 사람의 개발자와 관리자를 통해 일종의 즉각적인 배포를 처리합니다. 그러나보다 정교한 환경에서 MSBUILD와 함께 사용할 수도 있습니다.

보기 here

1

같은 문제가 있습니다. 내 생각에 개발 그룹은 주변의 환경에만 관심을 기울여야한다. 이는 개발, 유효성 테스트, 통합 테스트 및 일부 사전 제작 중 하나 일 수있다.

개발팀은 배포 팀에게 사용자 지정 구성을 쉽게 배포 할 수있는 적절한 응용 프로그램 설치 관리자를 제공해야한다고 생각합니다. 이 패키지의 한 가지 중요한 부분은 업데이트이며 기존 구성을 덮어 쓰지 않는 것입니다.

개발을 쉽게하기 위해 많은 제품들이 있지만, 그 중 어느 것에도 친숙하지는 않습니다. Wix에 대한 좋은 소식을 들었습니다 (무료입니다).