ASP.NET 응용 프로그램을 라이브 서버에 어떻게 배포합니까?

나는 당신이 ASP.NET 웹 응용 프로그램 프로젝트 (배포하는 데 사용할 다른 기술 / 도구를 찾고 있어요 NOT ASP.NET 웹 사이트) 생산을?

특히 Continuous Integration Build 서버가 특정 위치에 바이너리를 드롭하는 시점과 첫 번째 사용자 요청이 이러한 바이너리에 도달하는 시점 사이에 발생하는 워크 플로에 관심이 있습니다.

1. 특정 도구를 사용하고 있습니까 아니면 XCOPY 만 사용하고 있습니까? 응용 프로그램은 어떻게 패키지됩니까 (ZIP, MSI, ...)?

2. 응용 프로그램을 처음 배포 할 때 응용 프로그램 풀 및 가상 디렉터리를 어떻게 설정합니까 (수동으로 또는 일부 도구를 사용하여 생성합니까)?

3. 정적 리소스가 변경되면 (CSS, JS 또는 이미지 파일) 전체 애플리케이션을 재배포합니까 아니면 수정 된 리소스 만 재배포합니까? 어셈블리 / ASPX 페이지가 변경되면 어떻습니까?

4. 주어진 응용 프로그램에 대해 배포 된 모든 버전을 추적하고 있으며 문제가 발생하는 경우 응용 프로그램을 이전에 알려진 작업 상태로 복원하는 절차가 있습니까?

이전 목록을 자유롭게 작성하십시오.

그리고 다음은 ASP.NET 응용 프로그램을 배포하는 데 사용하는 것입니다.

1. 솔루션에 웹 배포 프로젝트 를 추가 하고 ASP.NET 웹 애플리케이션을 빌드하도록 설정합니다.
2. 우리는 설치 프로젝트 (추가 하지 솔루션에 웹 설치 프로젝트)와 웹 배포 프로젝트의 출력을하도록 설정
3. 사용자 지정 설치 작업을 추가하고 OnInstall 이벤트에서 System.DirectoryServices.DirectoryEntry를 사용하여 IIS에서 앱 풀과 가상 디렉터리를 만드는 사용자 지정 빌드 .NET 어셈블리를 실행합니다 (이 작업은 응용 프로그램이 처음 배포 될 때만 수행됨). . IIS에서 여러 웹 사이트, 가상 디렉터리에 대한 인증 및 앱 풀에 대한 ID 설정을 지원합니다.
4. TFS에 사용자 지정 작업을 추가하여 설치 프로젝트를 빌드합니다 (TFS는 설치 프로젝트를 지원하지 않으므로 devenv.exe를 사용하여 MSI를 빌드해야 함).
5. MSI는 라이브 서버에 설치됩니다 (이전 버전의 MSI가있는 경우 먼저 제거됨).

Setup Factory를 사용하여 모든 코드를 MSI에 배포했습니다. 변경이 필요한 경우 전체 솔루션을 재배치합니다. 이것은 css 파일에 대해 과도하게 들리지만 모든 환경을 동기화 상태로 유지하며 프로덕션 환경에 정확히 무엇인지 알고 있습니다 (모든 테스트 및 uat 환경에 동일한 방식으로 배포).

라이브 서버에 롤링 배포를 수행하므로 설치 프로그램 프로젝트를 사용하지 않습니다. CI와 비슷한 것이 있습니다.

• 승인 된 소스 (repo의 "HEAD"가 아님) 에서 "라이브"빌드 서버 빌드
• (백업 후 ;-p)
• robocopy는 스테이징 서버에 게시합니다 ( "라이브"이지만 F5 클러스터에는 없음).
• 스테이징 서버에서 수행되는 최종 유효성 검사 (종종 "호스트"해킹으로 전체 내용을 최대한 가깝게 에뮬레이션)
• robocopy / L은 다음 "푸시"에서 변경 사항 목록을 자동으로 배포하여 실수를 경고하는 데 사용됩니다.
• 예약 된 프로세스의 일부로 클러스터가 순환되고 robocopy를 통해 클러스터의 노드에 배포됩니다 (클러스터 외부에있는 동안).

robocopy는 변경 사항 만 배포되도록 자동으로 보장합니다.

Re the App Pool 등 나는 것이다 사랑 (이 자동화 될 이 질문을 참조 )하지만,에 순간 은 수동이다. 그래도 정말 바꾸고 싶어요.

(우리가 자체 데이터 센터와 서버 팜을 "현장"에 두는 것이 도움이되므로 많은 장애물을 넘을 필요가 없습니다.)

웹 사이트

배포자 : http://www.codeproject.com/KB/install/deployer.aspx

웹 사이트를 로컬 폴더에 게시하고 압축 한 다음 FTP를 통해 업로드합니다. 그러면 서버의 Deployer가 zip을 추출하고 구성 값 (Web.Config 및 기타 파일)을 바꿉니다.

물론 처음 실행하려면 서버에 연결하고 IIS WebSite, 데이터베이스를 설정해야하지만 그 후에 업데이트를 게시하는 것은 케이크 조각입니다.

데이터 베이스

데이터베이스를 동기화 상태로 유지하기 위해 http://www.red-gate.com/products/sql-development/sql-compare/를 사용합니다 .

서버가 여러 라우터 뒤에 있고 직접 연결할 수없는 경우 (SQL 비교 요구 사항) https://secure.logmein.com/products/hamachi2/ 를 사용하여 VPN을 만듭니다.

저는 대부분 ASP.NET 앱을 Linux 서버에 배포하고 아주 작은 변경에도 모든 것을 재배포합니다. 내 표준 워크 플로는 다음과 같습니다.

• 소스 코드 저장소 (예 : Subversion)를 사용합니다.
• 서버에는 다음을 수행하는 bash 스크립트가 있습니다.
  • 최신 코드 확인
  • 빌드 수행 (DLL 생성)
  • 파일을 필수 항목으로 필터링 (예 : 코드 파일 제거)
  • 데이터베이스 백업
  • 현재 날짜로 명명 된 디렉토리의 웹 서버에 파일을 배포합니다.
  • 새 스키마가 배치에 포함 된 경우 데이터베이스를 업데이트합니다.
  • 새 설치를 기본 설치로 설정하여 다음 히트와 함께 제공됩니다.

체크 아웃은 Subversion의 명령 줄 버전으로 수행되고 빌드는 xbuild (Mono 프로젝트와 유사한 msbuild 작업)로 수행됩니다. 대부분의 마법은 ReleaseIt에서 이루어집니다.

내 dev 서버에서는 본질적으로 지속적 통합이 있지만 프로덕션 측면에서는 실제로 서버에 SSH를 사용하고 스크립트를 실행하여 수동으로 배포를 시작합니다. 내 스크립트는 영리하게 '배포'라고 불리므로 bash 프롬프트에 입력합니다. 나는 매우 창의적입니다. 아니.

프로덕션에서는 'deploy'를 두 번 입력해야합니다. 한 번은 체크 아웃, 빌드 및 날짜가 지정된 디렉토리에 배포하고 한 번은 해당 디렉토리를 기본 인스턴스로 만듭니다. 디렉토리의 날짜가 지정 되었기 때문에 관련 디렉토리에서 'deploy'를 입력하기 만하면 이전 배포로 되돌릴 수 있습니다.

초기 배포에는 몇 분이 걸리고 이전 버전으로 되 돌리는 데 몇 초가 걸립니다.

나에게 좋은 솔루션이었고 세 가지 명령 줄 유틸리티 (svn, xbuild 및 releaseit), DB 클라이언트, SSH 및 Bash에만 의존합니다.

언젠가 CodePlex에서 ReleaseIt의 복사본을 업데이트해야합니다.

http://releaseit.codeplex.com/

ASP.NET 용 간단한 XCopy. 압축하고 서버에 sftp하고 올바른 위치에 압축을 풉니 다. 첫 번째 배포의 경우 IIS 수동 설정

질문에 대한 답변 :

1. XCopy
2. 수동으로
3. 정적 리소스의 경우 변경된 리소스 만 배포합니다.
   DLL의 경우 변경된 DLL 및 ASPX 페이지를 배포합니다.
4. 예, 그렇습니다.

멋지고 단순하게 유지함으로써 지금까지 많은 두통을 덜어주었습니다.

특정 도구를 사용하고 있습니까 아니면 XCOPY 만 사용하고 있습니까? 응용 프로그램은 어떻게 패키지됩니까 (ZIP, MSI, ...)?

BuildMaster 의 개발자로서 이것은 당연히 제가 사용하는 것입니다. 모든 애플리케이션은 도구 내에서 아티팩트로 빌드되고 패키징되며 내부적으로 ZIP 파일로 저장됩니다.

응용 프로그램을 처음 배포 할 때 응용 프로그램 풀 및 가상 디렉터리를 어떻게 설정합니까 (수동으로 또는 일부 도구를 사용하여 생성합니까)?

수동-애플리케이션이 테스트 환경을 통과 할 때 향후 환경에서 수행 할 정확한 단계를 상기시키는 도구 내에서 변경 제어를 생성합니다. 간단한 PowerShell 스크립트로도이를 자동화 할 수 있지만 새 애플리케이션을 자주 추가하지 않으므로 사이트를 수동으로 만드는 데 걸리는 1 분만큼 쉽습니다.

정적 리소스가 변경되면 (CSS, JS 또는 이미지 파일) 전체 애플리케이션을 재배포합니까 아니면 수정 된 리소스 만 재배포합니까? 어셈블리 / ASPX 페이지가 변경되면 어떻습니까?

기본적으로 아티팩트 배포 프로세스는 수정 된 파일 만 대상 서버로 전송되도록 설정됩니다. 여기에는 CSS 파일, JavaScript 파일, ASPX 페이지 및 연결된 어셈블리의 모든 항목이 포함됩니다.

주어진 응용 프로그램에 대해 배포 된 모든 버전을 추적하고 있으며 문제가 발생하는 경우 응용 프로그램을 이전에 알려진 작업 상태로 복원하는 절차가 있습니까?

예, BuildMaster가이 모든 것을 처리합니다. 복원은 대부분 이전 빌드 승격을 다시 실행하는 것처럼 간단하지만 때로는 데이터베이스 변경 사항을 수동으로 복원해야하며 데이터 손실이 발생할 수 있습니다. 기본 롤백 프로세스는 http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster에 자세히 설명되어 있습니다.

웹 설정 / 설치 프로젝트-문제가 발생하면 쉽게 제거 할 수 있습니다.

Unfold 는 내가 .net 애플리케이션을 위해 작성한 카피 스트라 노와 같은 배포 솔루션입니다. 그것은 우리의 모든 프로젝트에서 사용하는 것이며 매우 유연한 솔루션입니다. Rob Conery 의이 블로그 게시물 에설명 된대로 .net 애플리케이션의 일반적인 문제 대부분을 해결합니다.

• 소스 제어에서 코드 가져 오기, 빌드, 애플리케이션 풀 생성, IIS 설정 등 많은 표준 작업을 수행한다는 점에서 좋은 "기본"동작이 제공됩니다.
• 소스 제어 에있는 내용을 기반으로 릴리스
• 그것은이 작업 후크를 기본 동작은 쉽게 확장 또는 변경 될 수 있습니다,
• 그것은이 롤백
• 그것은 모두 powershell 이므로 외부 종속성이 없습니다.
• powershell 원격을 사용하여 원격 컴퓨터에 액세스합니다.

다음은 소개 및 기타 블로그 게시물입니다.

따라서 위의 질문에 답하려면 :

• 응용 프로그램은 어떻게 패키지됩니까 (ZIP, MSI, ...)?

  Git (또는 다른 scm)은 대상 머신에서 애플리케이션을 가져 오는 기본 방법입니다. 또는 로컬 빌드를 수행하고 Powereshell 원격 연결을 통해 결과를 복사 할 수 있습니다.

• 응용 프로그램을 처음 배포 할 때 응용 프로그램 풀 및 가상 디렉터리를 어떻게 설정합니까 (수동으로 또는 일부 도구를 사용하여 생성합니까)?

  Unfold는 Powershell의 WebAdministration Module을 사용하여 응용 프로그램 풀과 웹 사이트 응용 프로그램을 구성합니다. 이를 통해 당사 (및 귀하)가 애플리케이션 풀 또는 웹 사이트의 모든 측면을 수정할 수 있습니다.

• 정적 리소스가 변경되면 (CSS, JS 또는 이미지 파일) 전체 애플리케이션을 재배포합니까 아니면 수정 된 리소스 만 재배포합니까? 어셈블리 / ASPX 페이지가 변경되면 어떻습니까?

  Yes unfold는이 작업을 수행하며 모든 배포가 다른 배포 옆에 설치됩니다. 이렇게하면 무언가 잘못되었을 때 쉽게 롤백 할 수 있습니다. 또한 배포 된 버전을 소스 제어 개정으로 쉽게 추적 할 수 있습니다.

• 특정 애플리케이션에 대해 배포 된 모든 버전을 추적합니까?

  예, 전개는 이전 버전을 유지합니다. 모든 버전이 아니라 여러 버전입니다. 롤백을 거의 사소하게 만듭니다.

우리는 지난 1 년 동안 릴리스 프로세스를 개선해 왔으며 지금은이를 확인했습니다. Jenkins를 사용하여 모든 자동화 된 빌드 및 릴리스를 관리하고 있지만 TeamCity 또는 CruiseControl을 사용할 수 있다고 확신합니다.

따라서 체크인시 "일반"빌드는 다음을 수행합니다.

• Jenkins는 최신 버전의 코드를 가져 오기 위해 SVN 업데이트를 수행합니다.
• NuGet 패키지 복원은 자체 로컬 NuGet 리포지토리에 대해 실행됩니다.
• 응용 프로그램은 MsBuild를 사용하여 컴파일됩니다. 올바른 MsBuild를 설치 한 다음 빌드 상자에 ASP.NET 및 MVC dll을 설치해야하기 때문에이 설정은 모험입니다. (부수적으로 <MvcBuildViews>true</MvcBuildViews>, 뷰를 컴파일하기 위해 .csproj 파일에 입력 했을 때 msbuild가 무작위로 충돌하므로 비활성화해야했습니다)
• 코드가 컴파일되면 단위 테스트가 실행됩니다 (이를 위해 nunit을 사용하고 있지만 원하는 것을 사용할 수 있습니다)
• 모든 단위 테스트가 통과되면 IIS 앱 풀을 중지하고 앱을 로컬로 배포 (필요한 파일을 복사하는 몇 가지 기본 XCOPY 명령) 한 다음 IIS를 다시 시작합니다 (IIS 잠금 파일에 문제가 있었는데이 문제가 해결되었습니다.) 그것)
• 각 환경에 대해 별도의 web.config 파일이 있습니다. dev, uat, prod. (저는 웹 변환을 거의 성공하지 못했습니다). 따라서 올바른 web.config 파일도
• 그런 다음 PhantomJS를 사용하여 여러 UI 테스트를 실행합니다. 또한 다양한 해상도 (모바일, 데스크톱)에서 여러 스크린 샷을 찍고 각 스크린 샷에 몇 가지 정보 (페이지 제목, 해상도)를 찍습니다. Jenkins는 이러한 스크린 샷 처리를 지원하며 빌드의 일부로 저장됩니다.
• 통합 UI 테스트를 통과하면 빌드가 성공합니다.

누군가 "Deploy to UAT"를 클릭하는 경우 :

• 마지막 빌드가 성공하면 Jenkins는 또 다른 SVN 업데이트를 수행합니다.
• 애플리케이션은 RELEASE 구성을 사용하여 컴파일됩니다.
• "www"디렉토리가 생성되고 응용 프로그램이 여기에 복사됩니다.
• 그런 다음 winscp를 사용하여 빌드 상자와 UAT 간의 파일 시스템을 동기화합니다.
• UAT 서버에 HTTP 요청을 보내고 200을 반환하는지 확인합니다.
• 이 개정판은 SVN에서 UAT-datetime으로 태그가 지정됩니다.
• 이 정도면 빌드가 성공한 것입니다!

"Deploy to Prod"를 클릭하면 :

• 사용자가 이전에 생성 된 UAT 태그를 선택합니다.
• 태그는 다음으로 "전환"됩니다.
• 코드가 컴파일되고 Prod 서버와 동기화됩니다.
• Prod 서버에 대한 HTTP 요청
• 이 개정판은 SVN에서 Prod-datetime으로 태그가 지정됩니다.
• 릴리스는 압축되어 저장됩니다.

전체 빌드를 제작하는 데는 약 30 초가 걸리며 매우 만족합니다.

이 솔루션의 장점 :

• 빠르다
• 단위 테스트는 논리 오류를 포착해야합니다.
• UI 버그가 프로덕션에 들어가면 스크린 샷에 # 어떤 수정 버전이 문제를 일으켰는지 보여줄 것입니다.
• UAT와 Prod는 동기화 상태로 유지됩니다.
• Jenkins는 모든 커밋 메시지와 함께 UAT 및 Prod에 대한 훌륭한 릴리스 내역을 보여줍니다.
• UAT 및 Prod 릴리스는 모두 자동으로 태그가 지정됩니다.
• 릴리스가 언제 발생하고 누가 그랬는지 확인할 수 있습니다.

이 솔루션의 주요 단점은 다음과 같습니다.

• Prod로 릴리스 할 때마다 UAT로 릴리스해야합니다. UAT가 항상 Prod와 함께 최신 상태인지 확인하기를 원했기 때문에 이것은 의식적인 결정이었습니다. 그래도 고통입니다.
• 꽤 많은 구성 파일이 떠 다니고 있습니다. Jenkins에 모든 것을 포함하려고 시도했지만 프로세스의 일부로 필요한 지원 배치 파일이 몇 가지 있습니다. (또한 체크인됩니다).
• DB 업그레이드 및 다운 그레이드 스크립트는 앱의 일부이며 앱 시작시 실행됩니다. (대부분) 작동하지만 고통입니다.

다른 가능한 개선 사항을 듣고 싶습니다!

이 답변의 출처 인 2009 년에 우리는 지속적 통합 빌드에 CruiseControl.net을 사용했으며 Release Media도 출력했습니다.

거기에서 우리는 Smart Sync 소프트웨어를 사용했습니다. 를 하여로드 밸런싱 된 풀에서 벗어난 프로덕션 서버와 비교하고 변경 사항을 위로 이동했습니다.

마지막으로 릴리스를 확인한 후 RoboCopy를 사용하여 코드를 라이브 서버에 동기화하고 IIS를 중지 / 시작하는 DOS 스크립트를 실행했습니다.

마지막 회사에서는 마지막 업로드 이후의 변경 사항 만 업로드하기 위해 rSync 배치 파일을 사용하여 배포했습니다. rSync의 장점은 제외 목록을 추가하여 특정 파일이나 파일 이름 패턴을 제외 할 수 있다는 것입니다. 따라서 예를 들어 모든 .cs 파일, 솔루션 및 프로젝트 파일을 제외하는 것은 정말 쉽습니다.

버전 제어를 위해 TortoiseSVN을 사용하고 있었기 때문에 다음을 수행하기 위해 여러 SVN 명령을 작성할 수있어서 좋았습니다.

• 먼저 사용자가 최신 버전인지 확인하십시오. 그렇지 않은 경우 업데이트하라는 메시지를 표시하거나 바로 업데이트를 실행하십시오.
• SVN 사용자가 누구인지, 업로드중인 개정 번호, 업로드 날짜 및 시간을 자세히 설명하는 "synclog.txt"라는 서버에서 텍스트 파일을 다운로드합니다. 현재 업로드에 대한 새 줄을 추가 한 다음 변경된 파일과 함께 서버로 다시 보냅니다. 이렇게하면 업로드로 인해 문제가 발생했을 때 롤백 할 사이트 버전을 매우 쉽게 찾을 수 있습니다.

이 외에도 라이브 서버에서 파일 차이를 확인하는 두 번째 배치 파일이 있습니다. 이것은 누군가가 SVN에 대한 변경 사항을 업로드하지만 커밋하지 않는 일반적인 문제를 강조 할 수 있습니다. 위에서 언급 한 동기화 로그와 결합하여 범인이 누구인지 알아 내고 작업을 수행하도록 요청할 수 있습니다.

마지막으로 rSync를 사용하면 업로드 중에 교체 된 파일을 백업 할 수 있습니다. 백업 폴더로 옮겼습니다. 따라서 일부 파일을 덮어 쓰지 말아야한다는 것을 갑자기 깨달았다면 해당 폴더에있는 모든 파일의 마지막 백업 버전을 찾을 수 있습니다.

그 당시 솔루션이 약간 어색하다고 느꼈지만 업로드 방법이 훨씬 덜 우아하거나 쉬운 환경 (예 : 원격 데스크톱, 전체 사이트 복사 및 붙여 넣기)에서 작업 할 때 훨씬 더 감사하게되었습니다. .

기존 응용 프로그램 파일을 덮어 쓰는 것이 아니라 버전별로 디렉터리를 만들고 IIS 응용 프로그램을 새 경로로 다시 지정하는 것이 좋습니다. 다음과 같은 몇 가지 이점이 있습니다.

• 필요한 경우 빠르게 되돌리기
• 잠금 문제를 피하기 위해 IIS 또는 앱 풀을 중지 할 필요가 없습니다.
• 오래된 파일이 문제를 일으킬 위험 없음
• 다운 타임이 거의 없거나 거의 없습니다 (일반적으로 새 앱 도메인이 초기화 될 때 일시 중지됨)

우리가 가진 유일한 문제는 앱 풀을 다시 시작하지 않고 자동 appdomain 스위치에 의존하는 경우 리소스가 캐시된다는 것입니다.