개발 환경과 프로덕션 환경의 일반적인 구성 차이(VB)

  • 아티클

작성자 : Scott Mitchell

PDF 다운로드

이전 자습서에서는 개발 환경에서 프로덕션 환경으로 관련 파일을 모두 복사하여 웹 사이트를 배포했습니다. 그러나 각 환경에 고유한 Web.config 파일이 있어야 하는 환경 간에 구성 차이가 있는 것은 드문 일이 아닙니다. 이 자습서에서는 일반적인 구성 차이점을 살펴보고 별도의 구성 정보를 유지 관리하기 위한 전략을 살펴봅니다.

소개

마지막 두 자습서에서는 간단한 웹 애플리케이션 배포를 안내했습니다. FTP 클라이언트를 사용하여 사이트 배포 자습서에서는 독립 실행형 FTP 클라이언트를 사용하여 개발 환경에서 프로덕션까지 필요한 파일을 복사하는 방법을 보여 줬습니다. 위의 자습서인 Visual Studio를 사용하여 사이트 배포에서는 Visual Studio의 웹 사이트 복사 도구 및 게시 옵션을 사용하여 배포를 살펴보았습니다. 두 자습서에서 프로덕션 환경의 모든 파일은 개발 환경에 있는 파일의 복사본이었습니다. 그러나 프로덕션 환경의 구성 파일이 개발 환경의 구성 파일과 다른 것은 드문 일이 아닙니다. 웹 애플리케이션의 구성은 파일에 저장 Web.config 되며 일반적으로 데이터베이스, 웹 및 전자 메일 서버와 같은 외부 리소스에 대한 정보를 포함합니다. 또한 처리되지 않은 예외가 발생할 때 수행할 작업 과정과 같은 특정 상황에서 애플리케이션의 동작을 설명합니다.

웹 애플리케이션을 배포할 때 올바른 구성 정보가 프로덕션 환경에서 끝나는 것이 중요합니다. 대부분의 경우 Web.config 개발 환경의 파일을 프로덕션 환경에 있는 그대로 복사할 수 없습니다. 대신 사용자 지정된 버전의 Web.config 를 프로덕션에 업로드해야 합니다. 이 자습서에서는 몇 가지 일반적인 구성 차이점을 간략하게 검토합니다. 또한 환경 간에 서로 다른 구성 정보를 유지 관리하기 위한 몇 가지 기술을 요약합니다.

개발 환경과 프로덕션 환경 간의 일반적인 구성 차이점

파일에는 Web.config ASP.NET 애플리케이션에 대한 구성 정보의 구색이 포함되어 있습니다. 이 구성 정보 중 일부는 환경에 관계없이 동일합니다. instance 경우 파일 <authentication> 및 요소에 Web.config 설명된 인증 설정 및 <authorization> URL 권한 부여 규칙은 일반적으로 환경에 관계없이 동일합니다. 그러나 외부 리소스에 대한 정보와 같은 다른 구성 정보는 일반적으로 환경에 따라 다릅니다.

데이터베이스 연결 문자열은 환경에 따라 다른 구성 정보의 대표적인 예입니다. 웹 애플리케이션이 데이터베이스 서버와 통신하는 경우 먼저 연결을 설정해야 하며, 이는 연결 문자열 통해 이루어집니다. 데이터베이스를 웹 페이지 또는 데이터베이스에 연결하는 코드에서 직접 연결 문자열 하드 코딩할 수 있지만 연결 문자열 정보가 중앙 집중식 단일 위치에 있도록 요소를 배치 Web.config<connectionStrings> 하는 것이 가장 좋습니다. 개발 중에 프로덕션 환경에서 사용되는 데이터베이스와 다른 데이터베이스가 사용되는 경우가 많습니다. 따라서 연결 문자열 정보는 각 환경에 대해 고유해야 합니다.

참고

이후 자습서에서는 데이터 기반 애플리케이션 배포를 살펴봅니다. 이 시점에서 데이터베이스 연결 문자열이 구성 파일에 저장되는 방법에 대한 세부 정보를 살펴봅니다.

개발 및 프로덕션 환경의 의도된 동작은 크게 다릅니다. 개발 환경의 웹 애플리케이션은 소규모 개발자 그룹에 의해 생성, 테스트 및 디버그되고 있습니다. 프로덕션 환경에서는 여러 다른 동시 사용자가 동일한 애플리케이션을 방문합니다. ASP.NET 애플리케이션을 테스트하고 디버깅하는 개발자에게 도움이 되는 여러 기능이 포함되어 있지만 프로덕션 환경에서 성능 및 보안상의 이유로 이러한 기능을 사용하지 않도록 설정해야 합니다. 몇 가지 구성 설정을 살펴보겠습니다.

성능에 영향을 주는 구성 설정

ASP.NET 페이지를 처음 방문하거나 변경한 후 처음으로 방문하는 경우 선언적 태그를 클래스로 변환해야 하며 이 클래스를 컴파일해야 합니다. 웹 애플리케이션에서 자동 컴파일을 사용하는 경우 페이지의 코드 숨김 클래스도 컴파일해야 합니다. 파일 <compilation> 의 요소를 통해 Web.config 다양한 컴파일 옵션을 구성할 수 있습니다.

디버그 특성은 요소에서 <compilation> 가장 중요한 특성 중 하나입니다. 특성이 debug "true"로 설정된 경우 컴파일된 어셈블리에는 Visual Studio에서 애플리케이션을 디버깅할 때 필요한 디버그 기호가 포함됩니다. 그러나 디버그 기호는 어셈블리의 크기를 늘리고 코드를 실행할 때 추가 메모리 요구 사항을 적용합니다. 또한 특성이 debug "true"로 설정된 경우 에서 반환된 WebResource.axd 모든 콘텐츠는 캐시되지 않습니다. 즉, 사용자가 페이지를 방문할 때마다 에서 반환된 WebResource.axd정적 콘텐츠를 다시 다운로드해야 합니다.

참고

WebResource.axd 는 서버 컨트롤이 스크립트 파일, 이미지, CSS 파일 및 기타 콘텐츠와 같은 포함된 리소스를 검색하는 데 사용하는 ASP.NET 2.0에 도입된 기본 제공 HTTP 처리기입니다. 작동 방식 WebResource.axd 및 이를 사용하여 사용자 지정 서버 컨트롤에서 포함된 리소스에 액세스하는 방법에 대한 자세한 내용은 를 사용하여 WebResource.axdURL을 통해 포함된 리소스 액세스를 참조하세요.

<compilation> 요소의 debug 특성은 일반적으로 개발 환경에서 "true"로 설정됩니다. 실제로 웹 애플리케이션을 디버그하려면 이 특성을 "true"로 설정해야 합니다. Visual Studio debug 에서 ASP.NET 애플리케이션을 디버그하려고 하고 특성이 "false"로 설정된 경우 Visual Studio는 특성이 "true"로 설정될 때까지 debug 애플리케이션을 디버깅할 수 없음을 설명하는 메시지를 표시합니다.

성능에 debug 미치는 영향 때문에 프로덕션 환경에서 특성이 "true"로 설정되어서는 안 됩니다. 이 항목에 대한 자세한 내용은 Scott Guthrie의 블로그 게시물인 Don't Run Production ASP.NET Applications with debug="true" Enabled를 참조하세요.

사용자 지정 오류 및 추적

ASP.NET 애플리케이션에서 처리되지 않은 예외가 발생하면 다음 세 가지 중 하나가 발생하는 런타임까지 버블링됩니다.

  • 일반 런타임 오류 메시지가 표시됩니다. 이 페이지에서는 런타임 오류가 발생했음을 사용자에게 알릴 수 있지만 오류에 대한 세부 정보는 제공하지 않습니다.
  • 방금 throw된 예외에 대한 정보를 포함하는 예외 세부 정보 메시지가 표시됩니다.
  • 원하는 메시지를 표시하는 ASP.NET 페이지인 사용자 지정 오류 페이지가 표시됩니다.

처리되지 않은 예외가 발생할 경우 발생하는 작업은 파일의 <customErrors> 섹션에 Web.config 따라 달라집니다.

애플리케이션을 개발하고 테스트할 때 브라우저에서 예외에 대한 세부 정보를 확인하는 데 도움이 됩니다. 그러나 프로덕션 시 애플리케이션에서 예외 세부 정보를 표시하는 것은 잠재적인 보안 위험입니다. 또한 웹 사이트가 전문적이지 않은 것처럼 보입니다. 처리되지 않은 예외의 경우 개발 환경의 웹 애플리케이션은 예외의 세부 정보를 표시하는 반면 프로덕션의 동일한 애플리케이션에는 사용자 지정 오류 페이지가 표시됩니다.

참고

기본 <customErrors> 섹션 설정은 localhost를 통해 페이지를 방문하는 경우에만 예외 세부 정보 메시지를 표시하고, 그렇지 않으면 제네릭 런타임 오류 페이지를 표시합니다. 이상적이지는 않지만 기본 동작이 로컬이 아닌 방문자에게 예외 세부 정보를 표시하지 않는다는 것을 알 수 있습니다. 이후 자습서에서는 섹션을 <customErrors> 자세히 살펴보고 프로덕션 환경에서 오류가 발생할 때 사용자 지정 오류 페이지를 표시하는 방법을 보여 줍니다.

개발 중에 유용한 또 다른 ASP.NET 기능은 추적입니다. 추적은 사용하도록 설정된 경우 들어오는 각 요청에 대한 정보를 기록하고 최근 요청 세부 정보를 보기 위한 특별한 웹 페이지 Trace.axd를 제공합니다. 의 요소를 통해 <trace> 추적을 켜고 구성할 수 있습니다Web.config.

추적을 사용하도록 설정하면 프로덕션 환경에서 사용하지 않도록 설정되어 있는지 확인합니다. 추적 정보에는 쿠키, 세션 데이터 및 기타 잠재적으로 중요한 정보가 포함되므로 프로덕션 환경에서 추적을 사용하지 않도록 설정하는 것이 중요합니다. 좋은 소식은 기본적으로 추적이 사용하지 않도록 설정되고 localhost를 Trace.axd 통해서만 파일에 액세스할 수 있다는 것입니다. 개발에서 이러한 기본 설정을 변경하는 경우 프로덕션 환경에서 다시 꺼져 있는지 확인합니다.

별도의 구성 정보를 유지 관리하기 위한 기술

개발 및 프로덕션 환경에서 구성 설정이 다르면 배포 프로세스가 복잡해질 수 있습니다. 이전 두 자습서에서 배포 프로세스에는 개발에서 프로덕션으로 필요한 모든 파일을 복사하는 작업이 포함되었지만, 이 방법은 구성 정보가 두 환경 모두에서 동일한 경우에만 작동합니다. 다양한 구성 정보를 사용하여 애플리케이션을 배포하는 다양한 기술이 있습니다. 호스트된 웹 애플리케이션에 대한 이러한 옵션 중 일부를 카탈로그로 지정해 보겠습니다.

수동으로 프로덕션 환경 구성 파일 배포

가장 간단한 방법은 두 가지 Web.config 버전의 파일을 유지하는 것입니다. 하나는 개발 환경용이고 다른 하나는 프로덕션 환경용입니다. 프로덕션에 사이트를 배포하려면 파일을 제외한Web.config 개발 환경의 프로덕션 서버에 모든 파일을 복사해야 합니다. 대신 프로덕션 환경별 Web.config 파일이 프로덕션에 복사됩니다.

이 방법은 매우 정교하지는 않지만 구성 정보가 자주 변경되지 않으므로 구현하기가 쉽습니다. 단일 웹 서버에서 호스트되고 구성 정보가 자주 변경되지 않는 소규모 개발 팀이 있는 애플리케이션에 가장 적합합니다. 독립 실행형 FTP 클라이언트를 사용하여 애플리케이션 파일을 수동으로 배포할 때 가장 적합합니다. Visual Studio의 웹 사이트 복사 도구 또는 게시 옵션을 사용하는 경우 배포하기 전에 먼저 배포 관련 Web.config 파일을 프로덕션 관련 파일로 교환한 다음 배포가 완료된 후 다시 교체해야 합니다.

빌드 또는 배포 프로세스 중 구성 변경

지금까지 논의는 임시 빌드 및 배포 프로세스를 가정했습니다. 많은 대규모 소프트웨어 프로젝트에는 오픈 소스, 집에서 재배한 도구 또는 타사 도구를 사용하는 보다 공식화된 프로세스가 있습니다. 이러한 프로젝트의 경우 프로덕션으로 푸시되기 전에 구성 정보를 적절하게 수정하도록 빌드 또는 배포 프로세스를 사용자 지정할 수 있습니다. MSBuild, NAnt 또는 기타 빌드 도구를 사용하여 웹 애플리케이션을 빌드하는 경우 빌드 단계를 추가하여 프로덕션별 설정을 포함하도록 파일을 수정 Web.config 할 수 있습니다. 또는 배포 워크플로가 프로그래밍 방식으로 소스 제어 서버에 연결하고 적절한 Web.config 파일을 검색할 수 있습니다.

프로덕션에 적절한 구성 정보를 가져오는 실제 방법은 도구 및 워크플로에 따라 크게 달라집니다. 따라서 이 항목에 대해 자세히 알아보지 않습니다. MSBuild 또는 NAnt와 같은 인기 있는 빌드 도구를 사용하는 경우 웹 검색을 통해 이러한 도구와 관련된 배포 문서 및 자습서를 찾을 수 있습니다.

웹 배포 프로젝트 Add-In 통해 구성 차이점 관리

2006년 Microsoft는 Visual Studio 2005용 웹 개발 프로젝트 Add-In 릴리스했습니다. Visual Studio 2008용 Add-In 2008년에 릴리스되었습니다. 이 Add-In 통해 ASP.NET 개발자는 빌드할 때 웹 애플리케이션을 명시적으로 컴파일하고 로컬 출력 디렉터리에 배포할 파일을 복사하는 웹 애플리케이션 프로젝트와 함께 별도의 웹 배포 프로젝트를 만들 수 있습니다. 웹 애플리케이션 프로젝트는 백그라운드에서 MSBuild를 사용합니다.

기본적으로 개발 환경의 Web.config 파일은 출력 디렉터리에 복사되지만 웹 배포 프로젝트를 설정하여 를 사용자 지정할 수 있습니다.

다음과 같은 방법으로 이 디렉터리에 복사되는 구성 정보입니다.

  • 바꿀 섹션과 대체 텍스트가 포함된 XML 파일을 지정하는 파일 섹션 바꾸기를 통해 Web.config
  • 외부 구성 원본 파일에 대한 경로를 제공합니다. 이 옵션을 선택하면 웹 배포 프로젝트는 특정 Web.config 파일을 개발 환경에서 사용되는 파일이 아닌 Web.config 출력 디렉터리에 복사합니다.
  • 웹 배포 프로젝트에서 사용하는 MSBuild 파일에 사용자 지정 규칙을 추가합니다.

웹 애플리케이션을 배포하려면 웹 배포 프로젝트를 빌드한 다음 프로젝트의 출력 폴더에서 프로덕션 환경으로 파일을 복사합니다.

웹 배포 프로젝트 사용에 대한 자세한 내용은 MSDN Magazine의 2007년 4월호에서 이 웹 배포 프로젝트 문서를 검사 이 자습서의 끝에 있는 추가 읽기 섹션의 링크를 참조하세요.

참고

웹 배포 프로젝트는 Visual Studio Add-In 구현되고 Visual Studio Express 버전(Visual Web Developer 포함)은 추가 기능을 지원하지 않으므로 Visual Web Developer에서 웹 배포 프로젝트를 사용할 수 없습니다.

요약

개발 중인 웹 애플리케이션의 외부 리소스 및 동작은 일반적으로 동일한 애플리케이션이 프로덕션 상태일 때와 다릅니다. instance 경우 데이터베이스 연결 문자열, 컴파일 옵션 및 처리되지 않은 예외가 발생할 때의 동작은 일반적으로 환경 간에 다릅니다. 배포 프로세스는 이러한 차이점을 수용해야 합니다. 이 자습서에서 설명한 것처럼 가장 간단한 방법은 대체 구성 파일을 프로덕션 환경에 수동으로 복사하는 것입니다. 웹 배포 프로젝트 Add-In 사용하거나 이러한 사용자 지정을 수용할 수 있는 보다 공식화된 빌드 또는 배포 프로세스에서 더 세련된 솔루션을 사용할 수 있습니다.

행복한 프로그래밍!

추가 정보

이 자습서에서 설명하는 topics 대한 자세한 내용은 다음 리소스를 참조하세요.

이전다음