엔터프라이즈 웹 배포: 시나리오 개요

작성자 : Jason Lee

이 자습서 집합은 가상의 엔터프라이즈 배포 시나리오와 함께 현실적인 수준의 복잡성이 있는 샘플 솔루션을 사용하여 참조 구현을 제공하고 작업 및 연습에 공통 컨텍스트를 제공합니다. 이 항목에서는 자습서 시나리오에 대해 설명하고 샘플 솔루션을 소개합니다.

시나리오 설명

가상의 회사인 Fabrikam, Inc.는 원격 영업 팀이 웹 인터페이스에서 연락처 정보를 저장하고 검색할 수 있는 솔루션을 만들고 있습니다.

Fabrikam, Inc.의 ALM(애플리케이션 수명 주기 관리) 프로세스는 소프트웨어 개발 프로세스의 다양한 단계에서 세 개의 서버 환경에 솔루션을 배포해야 합니다.

  • 개발자 테스트 또는 "샌드박스" 환경.
  • 인트라넷 기반 스테이징 환경입니다.
  • 인터넷 연결 프로덕션 환경.

이러한 각 환경에는 서로 다른 구성 및 보안 요구 사항이 있으며 각각 고유한 배포 문제가 발생합니다.

Fabrikam, Inc. 서버 인프라

Fabrikam, Inc.의 고급 개발 및 배포 인프라입니다.

Fabrikam, Inc.의 고급 개발 및 배포 인프라

개발자 워크스테이션, 소스 제어 인프라, 개발자 테스트 환경 및 스테이징 환경은 모두 Fabrikam.net 도메인 내의 인트라넷 네트워크에 상주합니다. 프로덕션 환경은 방화벽에 의해 인트라넷 네트워크로부터 격리된 경계 네트워크(DMZ, 완역 영역 및 스크린된 서브넷이라고도 함)에 상주합니다. 일반적인 배포 시나리오입니다. 일반적으로 방화벽 또는 게이트웨이 서버를 사용하여 인터넷 연결 웹 서버를 내부 서버 인프라에서 격리합니다.

이 예제에서는 다음이 적용됩니다.

  • 별도의 빌드 서버가 있는 TFS(Team Foundation Server) 2010 서버는 소스 제어 및 CI(연속 통합) 기능을 제공합니다.
  • 개발자 테스트 환경에는 IIS(인터넷 정보 서비스) 7.5 웹 서버와 SQL Server 2008 R2 데이터베이스 서버가 포함됩니다.
  • 프로덕션 환경에는 WFF(Web Farm Framework) 컨트롤러 서버에서 동기화된 여러 IIS 7.5 웹 서버와 SQL Server 2008 R2 데이터베이스 서버가 포함되어 있습니다. 실제로 데이터베이스 서버는 클러스터링 또는 미러링을 사용하여 확장성 및 가용성을 향상시킬 수 있습니다.
  • 스테이징 환경은 프로덕션 환경의 구성을 가능한 한 밀접하게 복제하도록 설계되었습니다.
  • 방화벽 및 네트워크 격리 정책은 인트라넷에서 경계 네트워크로의 직접 자동화된 배포를 허용하지 않습니다.

이러한 각 환경의 구성은 두 번째 자습서인 웹 배포용 서버 환경 구성에서 자세히 설명합니다.

ALM에 대한 팀 역할

이러한 사용자는 Contact Manager 솔루션을 만들고, 관리하고, 빌드하고, 게시하는 데 관여합니다.

  • Matt Hink는 Fabrikam, Inc.의 웹 애플리케이션 개발자입니다. 그는 Visual Studio 2010을 사용하여 Contact Manager 솔루션을 개발한 팀의 일원입니다. Matt는 개발자 테스트 환경의 서버에 대한 전체 관리자 권한을 가지고 있으므로 요구 사항에 맞게 환경을 구성할 수 있습니다. 또한 사용자가 Visual Studio 2010 TFS instance 액세스하여 Contact Manager 솔루션에 대한 소스 코드를 저장합니다.

  • Rob Walters는 Fabrikam, Inc. 개발 팀의 서버 관리자입니다. Rob은 TFS 서버에서 관리 액세스 권한을 가지므로 TFS 및 팀 빌드의 모든 측면을 구성할 수 있습니다. Rob은 또한 테스트 및 스테이징 웹 서버에 대한 관리 액세스 권한을 가지며 테스트 및 스테이징 환경에서 데이터베이스 서버에 대한 DBA(데이터베이스 관리자) 역할을 합니다. Rob은 다음 작업을 수행하도록 TFS 서버에서 팀 빌드를 구성했습니다.

    • 사용자가 TFS에 파일을 체크 인할 때마다 애플리케이션에서 단위 테스트를 빌드하고 실행합니다. 이를 CI라고 합니다.
    • 애플리케이션이 단위 테스트를 통과하면 Contact Manager 애플리케이션을 테스트 환경에 자동으로 배포합니다. 여기에는 초기 배포 시 테스트 서버에 데이터베이스를 게시하고 초기 배포 후 데이터베이스에 대한 업데이트를 게시하는 것이 포함됩니다.
    • 단일 단계 프로세스에서 준비 환경에 Contact Manager 애플리케이션을 배포합니다.
    • 웹 서버 관리자와 DBA가 애플리케이션을 프로덕션 환경에 게시하는 데 사용할 수 있는 웹 패키지를 만듭니다.
  • Lisa Andrews는 Fabrikam, Inc. 프로덕션 서버에 애플리케이션을 배포하는 서버 관리자입니다. 연락처 관리자 애플리케이션을 빌드한 후 TFS 팀 빌드에서 웹 배포 패키지를 저장하는 공유에 대한 읽기 권한이 있습니다. 또한 프로덕션에 애플리케이션을 배포할 수 있도록 프로덕션 웹 서버에 대한 관리 액세스 권한도 있습니다. 또한 프로덕션 환경의 데이터베이스 서버에 데이터베이스 및 데이터베이스 업데이트를 배포하는 DBA 역할을 합니다.

Contact Manager 솔루션

Contact Manager 솔루션은 등록된 로그인한 사용자가 웹 인터페이스를 통해 연락처 정보를 추가하고 편집할 수 있도록 설계되었습니다. Contact Manager 솔루션은 다음 네 개의 개별 프로젝트로 구성됩니다.

Contact Manager 솔루션은 등록된 로그인한 사용자가 웹 인터페이스를 통해 연락처 정보를 추가하고 편집할 수 있도록 설계되었습니다.

  • ContactManager.Mvc. 솔루션의 진입점을 나타내는 ASP.NET MVC3 웹 애플리케이션 프로젝트입니다. 사용자에게 연락처 세부 정보를 만들고 볼 수 있는 기능을 제공하는 것과 같은 몇 가지 기본 웹 애플리케이션 기능을 제공합니다. 애플리케이션은 WCF(Windows Communication Foundation) 서비스를 사용하여 연락처 및 ASP.NET 애플리케이션 서비스 데이터베이스를 관리하여 인증 및 권한 부여를 관리합니다.
  • ContactManager.Database. Visual Studio 2010 데이터베이스 프로젝트입니다. 프로젝트는 연락처 세부 정보를 저장하는 데이터베이스에 대한 스키마를 정의합니다.
  • ContactManager.Service. WCF 웹 서비스 프로젝트입니다. WCF는 호출자가 Contact Manager 데이터베이스에서 CRUD(만들기, 검색, 업데이트 및 삭제) 작업을 수행할 수 있는 엔드포인트를 노출합니다. 서비스는 Contact Manager 데이터베이스 및 ContactManager.Common.dll 어셈블리를 사용합니다.
  • ContactManager.Common. 클래스 라이브러리 프로젝트입니다. WCF 서비스는 이 어셈블리에 정의된 형식을 사용합니다.

솔루션 및 해당 배포 요구 사항에 대한 전체 검토는 이 시리즈의 첫 번째 자습서인 엔터프라이즈의 웹 배포에서 제공됩니다.

배포 작업

대규모 organization 여러 환경에 애플리케이션을 배포하는 데는 몇 가지 고유한 작업이 있습니다. 자습서에서 다루는 주요 작업은 다음과 같습니다.

대규모 organization 여러 환경에 애플리케이션을 배포하는 데는 몇 가지 고유한 작업이 있습니다.

다음은 이 문서의 앞부분에서 설명한 사용자의 관점에서 배포 프로세스의 각 단계 목록입니다.

  1. 팀의 모든 구성원은 Visual Studio 2010의 Contact Manager 솔루션을 검토하여 주요 배포 요구 사항 및 문제를 확인합니다.
  2. Matt Hink는 배포 논리의 초기 테스트를 수행하기 위해 개발자 워크스테이션에서 개발자 테스트 환경으로 직접 Contact Manager 솔루션을 배포할 수 있습니다.
  3. Matt Hink는 TFS의 소스 제어에 애플리케이션을 추가합니다.
  4. Rob Walters는 팀 빌드에서 Contact Manager 솔루션에 대한 다양한 빌드 정의를 만듭니다. 한 빌드 정의는 CI를 사용하여 사용자가 새 코드를 검사할 때마다 개발자 테스트 환경에 솔루션을 배포합니다. 또 다른 빌드 정의를 사용하면 필요에 따라 스테이징 환경에 대한 배포를 트리거할 수 있습니다.
  5. 사용자가 새 코드를 체크 인할 때마다 Team Build는 솔루션 구성 요소를 자동으로 빌드하고, 단위 테스트를 실행하고, 빌드가 성공하고 단위 테스트가 통과된 경우 개발자 테스트 환경에 솔루션을 배포합니다.
  6. 사용자가 스테이징 환경에 대한 배포를 트리거하면 솔루션이 패키지되고 단일 단계 프로세스로 배포됩니다. 또한 이 프로세스는 프로덕션 환경에 수동 배포를 위한 패키지를 생성합니다.
  7. Lisa Andrews는 6단계에서 만든 웹 패키지를 수동으로 가져와서 애플리케이션을 프로덕션 환경에 배포합니다.

주요 배포 문제

Contact Manager 솔루션 및 Fabrikam, Inc. 시나리오는 복잡한 엔터프라이즈 규모 솔루션을 배포할 때 발생할 수 있는 다양한 일반적인 문제 및 문제를 강조 표시합니다. 예:

  • 개발자 또는 테스트 환경, 스테이징 플랫폼 및 프로덕션 서버와 같은 여러 환경에 프로젝트를 배포할 수 있어야 합니다. 솔루션은 각 환경에 대해 서로 다른 구성 설정을 사용하여 배포해야 합니다.
  • 단일 단계 또는 자동화된 빌드 및 배포 프로세스의 일부로 여러 종속 프로젝트를 동시에 배포해야 합니다.
  • 자동화된 프로세스에서 배포를 구동할 수 있어야 합니다. 예를 들어 CI 프로세스를 사용하여 새 코드를 체크 인할 때 웹 애플리케이션을 스테이징 환경에 배포하려고 합니다.
  • 개발자가 모든 대상 환경에 대해 올바른 구성 설정 또는 필요한 자격 증명을 가질 가능성이 낮기 때문에 배포 프로세스를 제어하고 Visual Studio 외부에서 배포 변수를 설정할 수 있어야 합니다.
  • 스키마 기반 데이터베이스 프로젝트를 배포하고 후속 배포에서 기존 데이터를 보존해야 합니다.
  • 사용자 계정 데이터를 배포하지 않고 임시로 멤버 자격 데이터베이스를 배포해야 합니다. 기존 사용자 계정 데이터를 잃지 않고 배포된 멤버 자격 데이터베이스의 스키마를 업데이트해야 할 수도 있습니다.
  • 다양한 대상 환경에 콘텐츠를 배포할 때 특정 파일 또는 폴더를 제외해야 합니다.

또한 업데이트가 자주 실행되고 증분할 때 배포를 관리하면 몇 가지 추가 문제가 발생합니다. 예:

  • 개발자가 새 코드를 확인할 때마다 단위 테스트를 실행합니다. 코드가 단위 테스트를 통과하는 경우에만 솔루션을 배포하려고 합니다.
  • 스테이징 또는 프로덕션 환경에 웹 애플리케이션을 배포하는 경우 배포 프로세스 기간 동안 사용자를 app_offline.htm 파일로 리디렉션하려고 합니다.
  • 배포 활동을 기록하려고 합니다. 배포 프로세스는 성공한 배포 또는 실패한 배포의 메일 알림 지정된 받는 사람에게 보내야 합니다.
  • 자동화된 배포가 실패하면 배포 프로세스에서 현재 배포를 다시 시도하거나 이전 웹 패키지를 대신 배포해야 합니다.