다음을 통해 공유

애플리케이션 수명 주기 관리: 개발부터 프로덕션까지

작성자 : Jason Lee

이 항목에서는 가상의 회사가 지속적인 개발 프로세스의 일부로 테스트, 스테이징 및 프로덕션 환경을 통해 ASP.NET 웹 애플리케이션의 배포를 관리하는 방법을 보여 줍니다. 항목 전체에서 특정 작업을 수행하는 방법에 대한 추가 정보 및 연습에 대한 링크가 제공됩니다.

이 항목은 엔터프라이즈의 웹 배포에 대한 일련의 자습서 에 대한 개략적인 개요를 제공하도록 설계되었습니다. 여기에 설명된 몇 가지 개념에 익숙하지 않은 경우 걱정하지 마세요. 다음 자습서는 이러한 모든 작업 및 기술에 대한 자세한 정보를 제공합니다.

참고

간단히 하기 위해 이 항목에서는 배포 프로세스의 일부로 데이터베이스 업데이트에 대해 설명하지 않습니다. 그러나 데이터베이스 기능을 증분 업데이트하는 것은 많은 엔터프라이즈 배포 시나리오의 요구 사항이며 이 자습서 시리즈의 뒷부분에서 이 작업을 수행하는 방법에 대한 지침을 찾을 수 있습니다. 자세한 내용은 데이터베이스 프로젝트 배포를 참조하세요.

개요

여기에 설명된 배포 프로세스는 Enterprise 웹 배포: 시나리오 개요에 설명된 Fabrikam, Inc. 배포 시나리오를 기반으로 합니다. 이 항목을 연구하기 전에 시나리오 개요를 읽어야 합니다. 기본적으로 이 시나리오에서는 organization 일반적인 엔터프라이즈 환경의 다양한 단계를 통해 합리적으로 복잡한 웹 애플리케이션인 Contact Manager 솔루션의 배포를 관리하는 방법을 살펴봅니다.

높은 수준에서 Contact Manager 솔루션은 개발 및 배포 프로세스의 일부로 다음 단계를 진행합니다.

  1. 개발자가 TFS(Team Foundation Server) 2010에 대한 일부 코드를 확인합니다.
  2. TFS는 코드를 빌드하고 팀 프로젝트와 연결된 모든 단위 테스트를 실행합니다.
  3. TFS는 솔루션을 테스트 환경에 배포합니다.
  4. 개발자 팀은 테스트 환경에서 솔루션을 확인하고 유효성을 검사합니다.
  5. 스테이징 환경 관리자는 스테이징 환경에 "what if" 배포를 수행하여 배포로 인해 문제가 발생하는지 여부를 설정합니다.
  6. 스테이징 환경 관리자는 스테이징 환경에 라이브 배포를 수행합니다.
  7. 솔루션은 스테이징 환경에서 사용자 승인 테스트를 거칩니다.
  8. 웹 배포 패키지는 프로덕션 환경으로 수동으로 가져옵니다.

이러한 단계는 지속적인 개발 주기의 일부를 구성합니다.

이러한 단계는 지속적인 개발 주기의 일부를 구성합니다.

실제로 각 단계를 자세히 살펴볼 때 볼 수 있듯이 프로세스는 이보다 약간 더 복잡합니다. Fabrikam, Inc.는 각 대상 환경에 대해 배포에 다른 접근 방식을 사용합니다.

Fabrikam, Inc.는 각 대상 환경에 대해 배포에 다른 접근 방식을 사용합니다.

이 항목의 나머지 단계에서는 이 배포 수명 주기의 주요 단계를 살펴봅니다.

  • 필수 구성 요소: 배포 논리를 적용하기 전에 서버 인프라를 구성해야 하는 방법입니다.
  • 초기 개발 및 배포: 솔루션을 처음으로 배포하기 전에 수행해야 하는 작업입니다.
  • 테스트할 배포: 개발자가 새 코드를 확인할 때 자동으로 테스트 환경에 콘텐츠를 패키지하고 배포하는 방법입니다.
  • 스테이징에 배포: 스테이징 환경에 특정 빌드를 배포하는 방법 및 "what if" 배포를 수행하여 배포에 문제가 발생하지 않도록 하는 방법입니다.
  • 프로덕션에 배포: 네트워크 인프라가 원격 배포를 방해하는 경우 웹 패키지를 프로덕션 환경으로 가져오는 방법입니다.

사전 요구 사항

모든 배포 시나리오의 첫 번째 작업은 서버 인프라가 배포 도구 및 기술의 요구 사항을 충족하는지 확인하는 것입니다. 이 경우 Fabrikam, Inc.는 다음과 같이 서버 인프라를 구성했습니다.

초기 개발 및 배포

Fabrikam, Inc. 개발 팀이 처음으로 Contact Manager 솔루션을 배포하기 전에 다음 작업을 수행해야 합니다.

  • TFS에서 새 팀 프로젝트를 만듭니다.
  • 배포 논리를 포함하는 Microsoft Build Engine(MSBuild) 프로젝트 파일을 만듭니다.
  • 배포 프로세스를 트리거하는 TFS 빌드 정의를 만듭니다.

새 팀 프로젝트 만들기

  • TFS 관리자인 Rob Walters는 TFS에서 팀 프로젝트 만들기에 설명된 대로 애플리케이션에 대한 새 팀 프로젝트를 만듭니다. 다음으로, 수석 개발자인 Matt Hink가 스켈레톤 솔루션을 만듭니다. 소스 제어에 콘텐츠 추가에 설명된 대로 TFS의 새 팀 프로젝트에 파일을 확인합니다.

배포 논리 만들기

Matt Hink는 프로젝트 파일 이해에 설명된 분할 프로젝트 파일 접근 방식을 사용하여 다양한 사용자 지정 MSBuild 프로젝트 파일을 만듭니다. Matt는 다음을 만듭니다.

  • 배포 프로세스를 실행하는 Publish.proj 라는 프로젝트 파일입니다. 이 파일에는 솔루션에서 프로젝트를 빌드하고, 웹 패키지를 만들고, 패키지를 대상 서버 환경에 배포하는 MSBuild 대상이 포함되어 있습니다.
  • Env-Dev.proj 및 Env-Stage.proj라는 환경별 프로젝트 파일입니다. 여기에는 연결 문자열, 서비스 엔드포인트 및 웹 패키지를 받을 원격 서비스의 세부 정보와 같이 각각 테스트 환경 및 스테이징 환경과 관련된 설정이 포함됩니다. 특정 대상 환경에 적합한 설정을 선택하는 방법에 대한 지침은 대상 환경에 대한 배포 속성 구성을 참조하세요.

배포를 실행하기 위해 사용자는 MSBuild 또는 팀 빌드를 사용하여 Publish.proj 파일을 실행하고 관련 환경별 프로젝트 파일(Env-Dev.proj 또는 Env-Stage.proj)의 위치를 명령줄 인수로 지정합니다. 그런 다음 Publish.proj 파일은 환경별 프로젝트 파일을 가져와 각 대상 환경에 대한 전체 게시 지침 집합을 만듭니다.

참고

이러한 사용자 지정 프로젝트 파일의 작동 방식은 MSBuild를 호출하는 데 사용하는 메커니즘과 독립적입니다. 예를 들어 프로젝트 파일 이해에 설명된 대로 MSBuild 명령줄을 직접 사용할 수 있습니다. 배포 명령 파일 만들기 및 실행에 설명된 대로 명령 파일에서 프로젝트 파일을 실행할 수 있습니다. 또는 배포를 지원하는 빌드 정의 만들기에 설명된 대로 TFS의 빌드 정의에서 프로젝트 파일을 실행할 수 있습니다.
각각의 경우 최종 결과는 동일합니다. MSBuild는 병합된 프로젝트 파일을 실행하고 솔루션을 대상 환경에 배포합니다. 이렇게 하면 게시 프로세스를 트리거하는 방법에 많은 유연성이 제공됩니다.

사용자 지정 프로젝트 파일을 만든 후 Matt는 이를 솔루션 폴더에 추가하고 소스 제어로 확인합니다.

빌드 정의 만들기

최종 준비 작업으로 Matt와 Rob은 함께 작업하여 새 팀 프로젝트에 대한 세 가지 빌드 정의를 만듭니다.

  • DeployToTest. 그러면 Contact Manager 솔루션이 빌드되고 검사 발생할 때마다 테스트 환경에 배포됩니다.
  • DeployToStaging. 이렇게 하면 개발자가 빌드를 큐에 대기할 때 지정된 이전 빌드의 리소스를 스테이징 환경으로 배포합니다.
  • DeployToStaging-WhatIf. 개발자가 빌드를 큐에 대기할 때 스테이징 환경에 "what if" 배포를 수행합니다.

다음 섹션에서는 이러한 각 빌드 정의에 대해 자세히 설명합니다.

테스트할 배포

Fabrikam, Inc.의 개발 팀은 검증 및 유효성 검사, 유용성 테스트, 호환성 테스트, 임시 또는 예비 테스트와 같은 다양한 소프트웨어 테스트 작업을 수행하기 위한 테스트 환경을 유지 관리합니다.

개발 팀은 DeployToTest라는 TFS에서 빌드 정의를 만들었습니다. 이 빌드 정의는 연속 통합 트리거를 사용합니다. 즉, Fabrikam, Inc. 개발 팀의 구성원이 검사 수행할 때마다 빌드 프로세스가 실행됩니다. 빌드가 트리거되면 빌드 정의는 다음을 수행합니다.

  • ContactManager.sln 솔루션을 빌드합니다. 그러면 솔루션 내의 모든 프로젝트가 빌드됩니다.
  • 솔루션 폴더 구조에서 단위 테스트를 실행합니다(솔루션이 성공적으로 빌드되는 경우).
  • 배포 프로세스를 제어하는 사용자 지정 프로젝트 파일을 실행합니다(솔루션이 성공적으로 빌드되고 단위 테스트를 통과하는 경우).

최종 결과는 솔루션이 성공적으로 빌드되고 단위 테스트를 통과하면 웹 패키지 및 기타 배포 리소스가 테스트 환경에 배포됩니다.

최종 결과는 솔루션이 성공적으로 빌드되고 단위 테스트를 통과하면 웹 패키지 및 기타 배포 리소스가 테스트 환경에 배포됩니다.

배포 프로세스는 어떻게 작동하나요?

DeployToTest 빌드 정의는 MSBuild에 다음 인수를 제공합니다.

/p:DeployOnBuild=true;DeployTarget=package;TargetEnvPropsFile=[path]\Env-Dev.proj

DeployOnBuild=true 및 DeployTarget=package 속성은 팀 빌드가 솔루션 내에서 프로젝트를 빌드할 때 사용됩니다. 프로젝트가 웹 애플리케이션 프로젝트인 경우 이러한 속성은 MSBuild에 프로젝트에 대한 웹 배포 패키지를 만들도록 지시합니다. TargetEnvPropsFile 속성은 Publish.proj 파일에 가져올 환경별 프로젝트 파일을 찾을 위치를 알려줍니다.

참고

이와 같은 빌드 정의를 만드는 방법에 대한 자세한 연습은 배포를 지원하는 빌드 정의 만들기를 참조하세요.

Publish.proj 파일에는 솔루션의 각 프로젝트를 빌드하는 대상이 포함되어 있습니다. 그러나 팀 빌드에서 파일을 실행하는 경우 이러한 빌드 대상을 건너뛰는 조건부 논리도 포함됩니다. 이렇게 하면 단위 테스트를 실행하는 기능과 같이 Team Build에서 제공하는 추가 빌드 기능을 활용할 수 있습니다. 솔루션 빌드 또는 단위 테스트가 실패하면 Publish.proj 파일이 실행되지 않고 애플리케이션이 배포되지 않습니다.

조건부 논리는 BuildingInTeamBuild 속성을 평가하여 수행됩니다. 팀 빌드를 사용하여 프로젝트를 빌드할 때 자동으로 true 로 설정되는 MSBuild 속성입니다.

스테이징에 배포

빌드가 테스트 환경에서 개발자 팀의 모든 요구 사항을 충족하는 경우 팀은 동일한 빌드를 스테이징 환경에 배포할 수 있습니다. 스테이징 환경은 일반적으로 서버 사양, 운영 체제 및 소프트웨어 및 네트워크 구성과 같이 프로덕션 또는 "라이브" 환경의 특성과 최대한 가깝게 일치하도록 구성됩니다. 스테이징 환경은 부하 테스트, 사용자 승인 테스트 및 광범위한 내부 검토에 자주 사용됩니다. 빌드는 빌드 서버에서 직접 스테이징 환경에 배포됩니다.

빌드는 빌드 서버에서 직접 스테이징 환경에 배포됩니다.

솔루션을 스테이징 환경인 DeployToStaging-WhatIf 및 DeployToStaging에 배포하는 데 사용되는 빌드 정의는 다음과 같은 특성을 공유합니다.

  • 그들은 실제로 아무것도 구축하지 않습니다. Rob이 스테이징 환경에 솔루션을 배포할 때 테스트 환경에서 이미 확인되고 유효성을 검사한 특정 기존 빌드를 배포하려고 합니다. 빌드 정의는 배포 프로세스를 제어하는 사용자 지정 프로젝트 파일을 실행하기만 하면 됩니다.
  • Rob이 빌드를 트리거할 때 빌드 매개 변수를 사용하여 빌드 서버에서 배포하려는 리소스를 포함하는 빌드를 지정합니다.
  • 빌드 정의는 자동으로 트리거되지 않습니다. Rob은 솔루션을 스테이징 환경에 배포하려는 경우 빌드를 수동으로 큐에 대기합니다.

이는 스테이징 환경에 배포하기 위한 대략적인 프로세스입니다.

  1. 스테이징 환경 관리자인 Rob Walters는 DeployToStaging-WhatIf 빌드 정의를 사용하여 빌드를 큐에 대기합니다. Rob은 빌드 정의 매개 변수를 사용하여 배포할 빌드를 지정합니다.
  2. DeployToStaging-WhatIf 빌드 정의는 사용자 지정 프로젝트 파일을 "what if" 모드에서 실행합니다. 그러면 Rob이 라이브 배포를 수행하는 것처럼 로그 파일이 생성되지만 실제로 대상 환경을 변경하지는 않습니다.
  3. Rob은 로그 파일을 검토하여 배포가 스테이징 환경에 미치는 영향을 확인합니다. 특히 Rob은 추가될 항목, 업데이트할 항목 및 삭제 대상을 검사 합니다.
  4. Rob이 배포에서 기존 리소스 또는 데이터를 바람직하지 않은 변경을 하지 않을 경우 DeployToStaging 빌드 정의를 사용하여 빌드를 큐에 대기합니다.
  5. DeployToStaging 빌드 정의는 사용자 지정 프로젝트 파일을 실행합니다. 이러한 리소스는 스테이징 환경의 기본 웹 서버에 배포 리소스를 게시합니다.
  6. WFF(Web Farm Framework) 컨트롤러는 스테이징 환경의 웹 서버를 동기화합니다. 이렇게 하면 서버 팜의 모든 웹 서버에서 애플리케이션을 사용할 수 있습니다.

배포 프로세스는 어떻게 작동하나요?

DeployToStaging 빌드 정의는 MSBuild에 이러한 인수를 제공합니다.

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;OutputRoot=[path to build folder]

TargetEnvPropsFile 속성은 Publish.proj 파일에 가져올 환경별 프로젝트 파일을 찾을 위치를 알려줍니다. OutputRoot 속성은 기본 제공 값을 재정의하고 배포하려는 리소스가 포함된 빌드 폴더의 위치를 나타냅니다. Rob은 빌드를 큐에 대기할 때 매개 변수 탭을 사용하여 OutputRoot 속성에 대한 업데이트된 값을 제공합니다.

Rob은 빌드를 큐에 대기할 때 매개 변수 탭을 사용하여 OutputRoot 속성에 대한 업데이트된 값을 제공합니다.

참고

이와 같은 빌드 정의를 만드는 방법에 대한 자세한 내용은 특정 빌드 배포를 참조하세요.

DeployToStaging-WhatIf 빌드 정의에는 DeployToStaging 빌드 정의와 동일한 배포 논리가 포함되어 있습니다. 그러나 추가 인수 WhatIf=true가 포함됩니다.

/p:TargetEnvPropsFile=[path]\Env-Stage.proj;
   OutputRoot=[path to build folder];
   WhatIf=true

Publish.proj 파일 내에서 WhatIf 속성은 모든 배포 리소스를 "what if" 모드로 게시해야 했음을 나타냅니다. 즉, 로그 파일은 배포가 진행된 것처럼 생성되지만 실제로 대상 환경에서는 아무것도 변경되지 않습니다. 이렇게 하면 실제로 변경하기 전에 제안된 배포의 영향, 특히 추가되는 항목, 업데이트되는 항목 및 삭제할 항목을 평가할 수 있습니다.

참고

"what if" 배포를 구성하는 방법에 대한 자세한 내용은 "What If" 배포 수행을 참조하세요.

스테이징 환경의 기본 웹 서버에 애플리케이션을 배포하면 WFF는 서버 팜의 모든 서버에서 애플리케이션을 자동으로 동기화합니다.

참고

웹 서버를 동기화하도록 WFF를 구성하는 방법에 대한 자세한 내용은 웹 팜 프레임워크를 사용하여 서버 팜 만들기를 참조하세요.

프로덕션에 배포

빌드가 스테이징 환경에서 승인되면 Fabrikam, Inc. 팀은 애플리케이션을 프로덕션 환경에 게시할 수 있습니다. 프로덕션 환경은 애플리케이션이 "라이브"되고 최종 사용자의 대상 그룹에 도달하는 곳입니다.

프로덕션 환경은 인터넷 연결 경계 네트워크에 있습니다. 이는 빌드 서버를 포함하는 내부 네트워크에서 격리됩니다. 프로덕션 환경 관리자인 Lisa Andrews는 빌드 서버에서 웹 배포 패키지를 수동으로 복사하여 기본 프로덕션 웹 서버의 IIS로 가져와야 합니다.

프로덕션 환경 관리자는 빌드 서버에서 웹 배포 패키지를 수동으로 복사하여 기본 프로덕션 웹 서버의 I S로 가져와야 합니다.

프로덕션 환경에 배포하기 위한 대략적인 프로세스입니다.

  1. 개발자 팀은 빌드가 프로덕션에 배포할 준비가 되었다고 Lisa에게 조언합니다. 팀은 빌드 서버의 drop 폴더 내에 있는 웹 배포 패키지의 위치를 Lisa에게 조언합니다.
  2. Lisa는 빌드 서버에서 웹 패키지를 수집하고 프로덕션 환경의 기본 웹 서버에 복사합니다.
  3. Lisa는 IIS 관리자를 사용하여 기본 웹 서버에 웹 패키지를 가져오고 게시합니다.
  4. WFF 컨트롤러는 프로덕션 환경의 웹 서버를 동기화합니다. 이렇게 하면 서버 팜의 모든 웹 서버에서 애플리케이션을 사용할 수 있습니다.

배포 프로세스는 어떻게 작동하나요?

IIS 관리자에는 웹 패키지를 IIS 웹 사이트에 쉽게 게시할 수 있는 애플리케이션 패키지 가져오기 마법사가 포함되어 있습니다. 이 절차를 수행하는 방법에 대한 연습은 수동으로 웹 패키지 설치를 참조하세요.

결론

이 항목에서는 일반적인 엔터프라이즈 규모 웹 애플리케이션에 대한 배포 수명 주기에 대한 설명을 제공했습니다.

이 항목은 웹 애플리케이션 배포의 다양한 측면에 대한 지침을 제공하는 일련의 자습서의 일부를 구성합니다. 실제로 배포 프로세스의 각 단계에서 많은 추가 작업과 고려 사항이 있으며 단일 연습에서 이러한 작업을 모두 처리할 수 없습니다. 자세한 내용은 다음 자습서를 참조하세요.

이전