ASP.NET 애플리케이션을 실시간 서버에 어떻게 배포합니까?

ASP.NET 애플리케이션을 실시간 서버에 어떻게 배포합니까?

프로덕션에 ASP.NET 웹 응용 프로그램 프로젝트(ASP.NET 웹 사이트가 아님)를 배포하는 데 사용하는 다른 기술/도구를 찾고 있습니다.

특히 Continuous Integration Build 서버가 바이너리를 특정 위치에 삭제할 때부터 첫 번째 사용자 요청이 바이너리에 도달할 때까지의 워크플로우에 관심이 있습니다.

1. 특정 툴을 사용하고 계십니까, 아니면 XCOPY만 사용하고 계십니까?애플리케이션 패키지 방식(ZIP, MSI, ...)

2. 애플리케이션을 처음 구축할 때 애플리케이션 풀 및 가상 디렉터리를 어떻게 설정합니까(수동으로 생성합니까, 아니면 도구를 사용하여 생성합니까)?

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

4. 특정 애플리케이션에 대해 배포된 모든 버전을 추적하고 문제가 발생할 경우 애플리케이션을 이전에 알려진 작동 상태로 복원하는 절차가 있습니까?

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

---

ASP.NET 애플리케이션을 구축하는 데 사용되는 기능은 다음과 같습니다.

1. 솔루션에 웹 배포 프로젝트를 추가하고 ASP.NET 웹 응용 프로그램을 구축하도록 설정합니다.
2. 솔루션에 설치 프로젝트(웹 설치 프로젝트 아님)를 추가하고 웹 배포 프로젝트의 출력을 가져오도록 설정합니다.
3. 사용자 지정 설치 작업을 추가하고 OnInstall 이벤트에서 시스템을 사용하여 IIS에 App Pool 및 Virtual Directory를 생성하는 사용자 지정 빌드 .NET 어셈블리를 실행합니다.디렉터리 서비스.디렉토리 항목(이 작업은 응용프로그램이 처음 배포될 때만 수행됩니다.)IIS의 여러 웹 사이트, 가상 디렉터리에 대한 인증 및 앱 풀에 대한 ID 설정을 지원합니다.
4. TFS에 사용자 지정 작업을 추가하여 설치 프로젝트를 구축합니다(TFS는 설치 프로젝트를 지원하지 않으므로 MSI를 구축하기 위해 devenv.exe를 사용해야 했습니다).
5. MSI가 라이브 서버에 설치되어 있습니다(이전 버전의 MSI가 있는 경우 먼저 제거됨).

모든 코드는 설치 공장을 사용하여 MSI에 배포됩니다.무언가 변경해야 할 경우 전체 솔루션을 다시 구축합니다.이는 CSS 파일에 대한 오버킬처럼 들리지만 모든 환경을 동기화하고 운영 환경을 정확히 파악합니다(모든 테스트 및 uat 환경에 동일한 방식으로 구축).

라이브 서버에 롤링 배포를 수행하므로 설치 프로그램 프로젝트를 사용하지 않고 CI와 유사한 기능을 제공합니다.

• 승인된 소스에서 "실시간" 빌드 서버 빌드(repo의 "HEAD"가 아님)
• (백업을 수행한 후 ;-p)
• 로보카피가 스테이징 서버에 게시("라이브"이지만 F5 클러스터에는 게시되지 않음)
• 스테이징 서버에서 수행된 최종 유효성 검사(가능한 한 전체를 에뮬레이트하기 위해 "하드웨어" 해킹을 사용하는 경우
• 로보카피 /L은 다음 번 "푸시"에서 변경된 사항의 목록을 배포하는 데 자동으로 사용됩니다.
• 스케줄링된 프로세스의 일부로, 클러스터가 순환되어 로보카피를 통해 클러스터의 노드에 배포됩니다(클러스터 외부에 있는 동안).

로보카피를 사용하면 변경 사항만 자동으로 배포됩니다.

App Pool 등을 참조하십시오. 자동화했으면 합니다(이 질문 참조). 현재는 수동입니다.하지만 저는 그것을 정말 바꾸고 싶습니다.

(자체 데이터 센터와 서버 팜 "현장"이 있으므로 많은 장애물을 극복할 필요가 없습니다.)

웹사이트

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

웹 사이트를 로컬 폴더에 게시하고 압축한 다음 FTP를 통해 업로드합니다.그런 다음 서버의 배포자가 zip을 추출하고 구성 값을 대체합니다(웹).구성 및 기타 파일), 이상입니다.

물론 처음 실행할 때는 서버에 연결하고 IIS 웹 사이트, 데이터베이스를 설정해야 하지만, 그 이후에는 업데이트를 게시하는 것이 식은 죽 먹기입니다.

데이터베이스

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

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

저는 대부분의 ASP.NET 앱을 리눅스 서버에 배포하고 사소한 변경에도 모든 것을 다시 배포합니다.표준 워크플로우는 다음과 같습니다.

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

체크아웃은 Subversion의 명령줄 버전으로 수행되고 빌드는 xbuild(Mono 프로젝트의 msbuild work-like)로 수행됩니다.대부분의 마법은 ReleaseIt에서 수행됩니다.

개발 서버에서는 기본적으로 지속적인 통합이 가능하지만, 운영 측에서는 실제로 서버에 SSH를 설치하고 스크립트를 실행하여 배포를 수동으로 시작합니다.내 스크립트는 교묘하게 'deploy'라고 불리므로 bash 프롬프트에서 그렇게 입력합니다.저는 매우 창의적입니다.것은 아니다.

운영 환경에서 'deploy'를 두 번 입력해야 합니다. 한 번은 체크아웃, 빌드 및 날짜가 지정된 디렉토리에 배포하고 한 번은 해당 디렉토리를 기본 인스턴스로 만들어야 합니다.디렉토리가 날짜가 지정되어 있으므로 관련 디렉토리 내에서 'deploy'를 입력하기만 하면 이전 배포로 되돌릴 수 있습니다.

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

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

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 에서 자세히 설명합니다.

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

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

• 소스 제어에서 코드 가져오기, 빌드, 응용 프로그램 풀 만들기, IIS 설정 등 많은 표준 작업을 수행한다는 점에서 "기본" 동작이 좋습니다.
• 소스 제어 기능을 기반으로 한 릴리스
• 작업 후크가 있어 기본 동작을 쉽게 확장하거나 변경할 수 있습니다.
• 롤백이 있습니다.
• 모두 파워셸이기 때문에 외부 의존성은 없습니다.
• 원격 시스템에 액세스하기 위해 파워셸 원격을 사용합니다.

여기 소개와 다른 블로그 게시물이 있습니다.

위의 질문에 답하려면 다음과 같이 하십시오.

• 애플리케이션 패키지 방식(ZIP, MSI, ...)

  Git(또는 다른 scm)는 대상 시스템에서 응용 프로그램을 가져오는 기본 방법입니다.또는 로컬 빌드를 수행하고 Powerreshell 원격 연결을 통해 결과를 복사할 수 있습니다.

• 애플리케이션을 처음 구축할 때 애플리케이션 풀 및 가상 디렉터리를 어떻게 설정합니까(수동으로 생성합니까, 아니면 도구를 사용하여 생성합니까)?

  전개는 Powershell의 웹 관리 모듈을 사용하여 응용 프로그램 풀 및 웹 사이트 응용 프로그램을 구성합니다.애플리케이션 풀 또는 웹 사이트의 모든 측면을 수정할 수 있습니다.

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

  예, 펼치면 이렇게 됩니다. 모든 배포가 다른 배포 옆에 설치됩니다.그렇게 하면 무언가 잘못되었을 때 쉽게 롤백할 수 있습니다.또한 배포된 버전을 소스 제어 버전으로 쉽게 추적할 수 있습니다.

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

  예, 펼치기는 오래된 버전을 유지합니다.모든 버전은 아니지만 여러 버전이 있습니다.롤백을 거의 사소한 것으로 만듭니다.

우리는 지난 1년 동안 출시 과정을 개선해 왔고 이제 그것을 잘 알고 있습니다.Jenkins를 사용하여 자동 빌드 및 릴리스를 모두 관리하고 있지만, TeamCity 또는 CruiseControl을 사용할 수 있습니다.

체크인 시 "정상" 빌드는 다음 작업을 수행합니다.

• 젠킨스가 SVN 업데이트를 수행하여 코드의 최신 버전을 가져옵니다.
• 자체 로컬 NuGet 저장소에 대해 NuGet 패키지 복원이 완료되었습니다.
• 응용프로그램은 MsBuild를 사용하여 컴파일됩니다.에 ASP 및 dll을 로, "MsBuild"를했을 때 ASP.NET "MVC dll"을 설치했을 때)<MvcBuildViews>true</MvcBuildViews>내 .해야 했습니다.
• 코드가 컴파일되면 유닛 테스트가 실행됩니다(나는 이것에 대해 nunit를 사용하고 있지만, 당신은 원하는 것을 사용할 수 있습니다).
• 모든 장치 테스트가 통과되면 IIS 앱 풀을 중지하고 앱을 로컬로 배포한 다음(필요한 파일에 복사할 몇 가지 기본 XCOPY 명령만 있음) IIS를 다시 시작합니다(IIS 잠금 파일에 문제가 발생하여 이로 인해 해결됨).
• 각 환경에 대해 별도의 web.config 파일이 있습니다. dev, uat, prod. (웹 변환 작업을 시도했지만 거의 성공하지 못했습니다.)따라서 올바른 web.config 파일도 복사됩니다.
• 그런 다음 팬텀을 사용합니다.여러 UI 테스트를 실행하는 JS입니다.또한 다양한 해상도(모바일, 데스크톱)의 스크린샷을 여러 개 촬영하고 각 스크린샷에 일부 정보(페이지 제목, 해상도)를 스탬프로 표시합니다.Jenkins는 이러한 스크린샷을 처리하는 데 큰 지원을 받고 있으며 이러한 스크린샷은 빌드의 일부로 저장됩니다.
• 통합 UI 테스트를 통과하면 빌드가 성공합니다.

누군가 "UAT에 배포"를 클릭하는 경우:

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

"Prod로 배포"를 클릭하면 다음이 수행됩니다.

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

전체 빌드에서 프로덕션까지 걸리는 시간은 약 30초 정도로 매우 만족스럽습니다.

이 솔루션의 단점:

• 빠릅니다
• 장치 테스트에서 논리 오류가 발견되어야 합니다.
• UI 버그가 생산에 들어가면 스크린샷이 어떤 개정판 #이 그것을 야기했는지 보여주기를 바랍니다.
• UAT와 Prod의 동기화 상태
• Jenkins는 모든 커밋 메시지와 함께 UAT 및 Prod에 대한 훌륭한 릴리스 기록을 보여줍니다.
• UAT 및 Prod 릴리스는 모두 자동으로 태그 지정됩니다.
• 릴리스가 발생한 시기와 누가 릴리스했는지 확인할 수 있습니다.

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

• Prod에 릴리스를 수행할 때마다 UAT에 릴리스를 수행해야 합니다.이는 UAT가 항상 Prod와 최신 상태를 유지하도록 보장하기 위해 내린 의식적인 결정이었습니다.그래도, 그건 고통입니다.
• 많은 구성 파일이 떠돌고 있습니다.Jenkins에서 모든 것을 시도해 봤지만, 프로세스의 일부로 지원 배치 파일이 필요합니다.(또한 체크인됩니다.)
• DB 업그레이드 및 다운그레이드 스크립트는 앱의 일부이며 앱 시작 시 실행됩니다.(대부분) 효과가 있지만, 고통스럽습니다.

저는 다른 가능한 개선 사항에 대해 듣고 싶습니다!

2009년에 이러한 답변이 있었던 시점에서 당사는 Continuous Integration 빌드에 CruiseControl.net 을 사용했으며 릴리스 미디어도 출력했습니다.

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

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

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

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

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

이 외에도 라이브 서버에서 파일 차이를 확인하는 두 번째 배치 파일이 있습니다.이렇게 하면 다른 사용자가 SVN에 변경 사항을 적용하지 않고 업로드하는 일반적인 문제를 강조할 수 있습니다.위에 언급된 동기화 로그와 결합하여, 우리는 가능한 범인이 누구인지 알아낼 수 있었고 그들에게 그들의 일을 하도록 요청할 수 있었습니다.

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

그 후 업로드 방법이 훨씬 덜 우아하거나 쉬운 환경(예: 원격 데스크톱, 전체 사이트를 복사하여 붙여넣기)에서 작업할 때 솔루션이 다소 투박하게 느껴졌습니다.

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

• 필요한 경우 신속하게 복구
• 잠금 문제를 방지하기 위해 IIS 또는 앱 풀을 중지할 필요 없음
• 오래된 파일로 인해 문제가 발생할 위험 없음
• 다운타임이 거의 없음(일반적으로 새 애플리케이션 도메인 초기화 시 일시 중지)

앱 풀을 다시 시작하지 않고 자동 앱 도메인 스위치를 사용할 경우 리소스가 캐시되는 문제가 발생했습니다.

언급URL : https://stackoverflow.com/questions/1143274/how-do-you-deploy-your-asp-net-applications-to-live-servers