.NET 웹 애플리케이션을 어떻게 배치합니까? (추천 부탁합니다!)

우리는 최근에 ASP.NET 웹 사이트 를 웹 응용 프로그램으로 업그레이드 했으며 웹 사이트 를 배포 할 때 갑작스런 도약에 충격을 받았습니다. 이것이 얼마나 일반적인 작업인지 고려할 때 사람들이 빠르게 진화하고 원격으로 저장된 프로젝트 (예 : 웹 사이트)를 배포하기 위해 사람들이 사용하는 플러그인 / 소프트웨어가 궁금합니다.

Visual Studio 에서 "게시" 한 다음 변경된 파일을 수동으로 FTP 해야하는 것보다 좋은 방법이 있습니까? 적어도 .DLL을 업로드 할 때 사이트가 다운되기 때문에.

파일이 너무 많기 때문에 실수로 업로드하지 않도록 프로세스를 최대한 자동화해야합니다.

WebSite의 기존 솔루션에서는 Dispatch for ASP 를 사용 하여 전체 프로세스를 한 번의 클릭으로 완전히 돌 렸습니다. 불행히도 (앞서 언급했듯이) DLL에는 좋지 않습니다.

그래서 어떻게 당신의 팀은합니까?

조언을 주셔서 감사합니다.

추신-Visual Studio 2010이 VS2005 / 08의 이러한 단점을 해결해야한다고 읽었지만 그때까지는 ...

Continuous Integration을 사용하는 것이 좋습니다.

우리의 조합 사용 인 TeamCity CI에 대한 레이크 와 다랑어 구이 빌드를 자동화.

TeamCity는 소스 코드 저장소에서 코드를 확인한 다음 Rake를 사용하여 애플리케이션을 빌드하고 단위 테스트를 실행하며 원하는 경우 데이터베이스 스크립트를 실행합니다. 빌드가 완료되면 소스 코드를 zip 파일로 패키지하거나 원하는 대상으로 복사 할 수 있습니다.

TeamCity는 모든 소스 제어 시스템에서 작동하지만 Git을 사용합니다.

TeamCity 및 Rake를 사용하는 것은 XML 파일을 편집하지 않고 CruiseControl 및 NANT를 사용하는 것과 유사합니다. 물론 원하는 경우 TeamCity를 NANT와 함께 사용할 수 있습니다.

빌드를 수행하는 rakefile.rb에서 가져온 짧은 샘플. IMHO, XML 파일보다 읽기 및 디버그가 더 쉽습니다.

require 'albacore'
require 'rexml/document'
require 'find'

VERSION_NO = "1.0"

OUTPUT_PATH = "output"
WEBOUTPUT_PATH = "output/web"
ADMINOUTPUT_PATH = "output/admin"

CONFIG = "Release"

WEB_PATH = "app/Company.Website.Web"
ADMIN_PATH = "app/Company.Website.Admin"
PACKAGE_PATH = "build/package"
DB_SCRIPT_PATH = "Company.Website.DB"
SOLUTION = "Company.Website.sln"

ARTIFACTS_PATH = "d:/build/artifacts/"

DEPLOY_WEB_PATH = "d:/deploy/company/website/"
DEPLOY_ADMIN_PATH = "d:/deploy/company/admin/"

task :default => ['setuptest','assemblyinfo','config','msbuild','createdb','sqlcmd','deploy']


task :setuptest do |setup|
  if ENV['BuildNumber'].nil? then ENV['BuildNumber'] = "000" end

  VERSION_NO = VERSION_NO + '.' + ENV['BuildNumber']
  puts 'Version Number : ' + VERSION_NO

  ZIPFILE_WEB = 'Company.Website.Web.' + VERSION_NO
  ZIPFILE_ADMIN = 'Company.Website.Admin.' + VERSION_NO  

  DB_SERVER = "WEB2"
  DB_DATABASE = "Website"  
  CREATEDB_SCRIPT = "app/Company.Website.DB/00CreateDatabaseTEST.sql"
end

  assemblyinfotask do |asm|
    asm.version = VERSION_NO
    asm.company_name = "Company Name"
    asm.copyright = "Copyright 2010"
    asm.output_file = "CommonAssemblyInfo.cs"
  end

  task :config do
    FileUtils.cp 'NHibernate.test.config', 'NHibernate.config'
  end

  msbuildtask do |msb|
    msb.properties = { :configuration => :Debug }
    msb.targets [:Clean, :Build]
    msb.solution = "Company.Website.sln"
  end

  sqlcmdtask :createdb do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = "master"
    sql.scripts << CREATEDB_SCRIPT
  end

  sqlcmdtask do |sql|
    puts "executing sql scripts..."
    sql.log_level = :verbose
    sql.path_to_command = "sqlcmd.exe"
    sql.server = DB_SERVER
    sql.database = DB_DATABASE
    sql.scripts << "app/Company.Website.DB/01CreateTables.sql"
    sql.scripts << "app/Company.Website.DB/02InsertReferenceData.sql"
  end

  task :deployprep do

    FileUtils.remove_dir 'app/Company.Website.Web/obj'
    FileUtils.remove_dir 'app/Company.Website.Admin/obj'

  end

  ziptask :zipweb do |zip|
    puts "creating zip package in " + ZIPFILE_WEB
    zip.directories_to_zip = ["app/Company.Website.Web"]
    zip.output_file = ZIPFILE_WEB  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end

  ziptask :zipadmin do |zip|
      puts "creating zip package in " + ZIPFILE_ADMIN
    zip.directories_to_zip = ["app/Company.Website.Admin"]
    zip.output_file = ZIPFILE_ADMIN  + '.zip'
    zip.output_path = File.dirname(__FILE__)
  end  

Albacore는 .NET 응용 프로그램 배포를 위해 특별히 구축 된 Rake 작업 모음입니다.

Linux에서는 원격 SSH 및 SCP 명령을 지원하는 자동화 도구 인 패브릭 (fabfile.org)과 capistrano (capify.org)를 사용했습니다. Cygwin을 Windows 호스트에 설치 한 경우이를 배포 도구로 재사용 할 수 있습니다.

Visual Studio에서 웹 응용 프로그램 "게시"는 명령 줄에서로 실행할 수 있습니다 msbuild "C:\proj\yourprojectpathandfilename.csproj" /deploydir:"C:\some\deploy\dir". 대상 디렉토리는 배포 가능한 웹 응용 프로그램입니다.

더 큰 질문을 다루는 다른 답변이 좋습니다. 또한 여러 오픈 소스 웹 응용 프로그램 프로젝트를보고 가장 좋아하는 빌드 프로세스를 복사해야한다고 덧붙였습니다.

나는 이것이 매우 복잡하고 쉽게 간과 될 수 있다는 Scott에 동의합니다. 배포 전략은 응용 프로그램마다 매우 다릅니다. 앱이 하나의 폴더에 완전히 포함 된 경우 GAC를 참조하는 앱보다 쉽습니다. 이는 여러 버전의 어셈블리 GAC를 참조하는 여러 버전의 앱을 유지 관리해야하는 서버보다 여전히 쉬운 방법입니다. 우리는 여기에서 정책 파일에 대해 이야기하고 싶지 않습니다 :).

Microsoft 웹 배포 도구 와 응용 프로그램 요청 라우팅 을 결합하는 것이 좋은 방법 이라고 말했습니다 . IIS7에서는 도구를 사용하여 설치 패키지를 만들 수 있습니다. 도구를 웹 응용 프로그램으로 지정하고 전체 응용 프로그램을 응용 프로그램 보관 폴더에 백업 할 수도 있습니다. 그런 다음이 보관 폴더에서 IIS6 또는 IIS7 웹 서버로 배포 할 수 있습니다 (IIS5는 지원되지 않음). Scott이 테스트 웹 사이트와 라이브를 분리하도록 제안한 것처럼 응용 프로그램 요청 라우팅을 사용합니다. 새로 게시 된 웹 사이트가 양호한 지 확인하면 ARR을 새 버전으로 라우팅하도록 설정할 수 있습니다.

PyroBatchFTP 는 이것을 위해 잘 작동합니다. 변경 사항 만 푸시하고 배치 파일을 두 번 클릭하여 푸시 할 수 있도록 스크립트를 작성할 수 있습니다.

에서 Vaasnet 우리는 설정 자신의 꿈 솔루션했지만, 그것은 매우 당신이 할 수있는 경우 일부 또는 이러한 모든 요소를 사용하여 설정하지만, 가치에 연루. 그게 뭐예요 :

• 모든 dev 시스템의 SVN
• 빌드 / 배포 서버의 SVN
• Cruisecontrol.net 은 SVN의 변경 사항을 감시하고 필요한 파일 만 준비 폴더에 준비 및 준비합니다.
• PyroBatchFTP를 사용하여 준비 사이트로 이동합니다 (Cruisecontrol에 의해 트리거되므로 자동으로 발생 함)
• IIS7과 ARR ( Application Request Routing ) 및 URL 재 작성을 사용하여 다음과 같은 준비 / 생산 설정을 갖습니다.
  • ARR 선행은 어느 것이 '실제'이고 어떤 것이 '스테이징'인지에 따라 인스턴스 01 또는 02로 트래픽을 보냅니다.
  • FTP 계정은 항상 '스테이징'에 바인딩됩니다
  • 준비를 바꾸고 한 번의 클릭으로 작동하는 또 다른 미니 관리자 사이트가 있습니다. 가동 중지 시간없이 전환하는 데 1 초가 소요되며 해당 릴리스에 문제가 있음을 알게되면 다시 전환 할 수 있습니다 (실시간 진행하기 전에 쉽게 테스트 할 수 있기 때문에 드물지만).

결과적으로 우리는 SVN에 체크인하여 수동 상호 작용없이 자동으로 생산을 진행할 수 있습니다. 준비 URL을 테스트하고 게시 할 준비가되었는지 확인한 후 간단한 사이트에 로그인하고 클릭 한 번으로 시작합니다.

제안되지 않은 다른 방법으로, 나는 '구'와 웹 설정 프로젝트를 참조합니다.

기본적으로 .NET 응용 프로그램 용 MSI 설치 관리자가 생성됩니다. 이 예제는 VS2005에 대한 것이지만 VS2010이 있고 프로젝트 유형이 여전히 있습니다. 이를 통해 필요한 경우 많은 사용자 정의를 제공하거나 필요하지 않은 경우 기본 설치 만 할 수 있습니다.

개인적으로 우리는 xcopy 스타일 배포를 수행하지만 결국 패키지를 서버 그룹에 넘겨서 배포시기와 방법을 제어하고 싶습니다. (그룹 정책과 같은 것을 사용하여 대량 배포를 더 쉽게 할 수 있다고 생각하지만 너무 익숙하지는 않습니다.)

이 고양이를 스키닝하는 방법에는 여러 가지가 있으며 실제로 서버에 얼마나 많은 액세스 권한이 있는지에 달려 있습니다. 내가 개인적으로 가장 좋아하는 방법은 모든 배포 파일을 패키지화하는 프로젝트 내에 빌드 스크립트 (일반적으로 MSBUILD 사용)를 설정 한 다음 SVN을 사용하여 프로덕션으로 연결하는 것입니다. 그리고 프로덕션 파일을 버전 화합니다.

데이터베이스 측면에서 가장 좋은 방법은 일종의 마이그레이션 프레임 워크를 사용하는 것입니다. 다시 말하지만, 많은 사람들이 달리고 있으며 명확한 대답이 없습니다.

개인적으로 나는 특정 파일 형식의 폴더를 dev 서버에 복사하기 위해 직접 작성한 vbs 스크립트를 사용합니다 (예 : cs 파일 제외).

대규모 .com 회사에서 근무했을 때 이것이 .net 배포에서 수행 한 작업입니다.

우리의 모든 소스 코드와 저장 프로시 저는 SVN에 저장되었습니다. 매일 밤, 데이터베이스 작업이 실행되고 프로덕션 저장된 procs를 가져 와서 SVN의 디렉토리로 이동시켜 소스 제어에 항상 최신 버전이있게합니다.

프로젝트 배포 당일에는 nAnt 스크립트를 사용하여 SVN에서 프로젝트를 가져오고 프로젝트를 사용자 정의 빌드하고 이러한 프로젝트에 필요한 종속성을 가져옵니다. nAnt 스크립트가 실행되면 자동 압축 풀기 zip 파일로 패키지되었습니다. 이 배포와 관련된 저장된 procs가 소스 컨트롤에 체크인되었고 Excel spreed sheet가 실행될 스크립트와 순서에 따라 업데이트되었습니다.

deploymenet이 종료되면 자동 압축 풀기 zip 파일이 시작된 서버로 전송되었습니다. 모든 파일이 올바른 디렉토리로 추출되었으며 DBA는 prodcution 데이터베이스에서 저장된 proc를 실행했습니다.

이 시스템을 사용하는 일반적인 배포에서는 5-6 시간 배포에서 1 시간 이하로 진행했습니다.

행운을 빕니다. 이것이 응용 프로그램을 배포하는 방법을 찾는 데 도움이되기를 바랍니다.

Visual Studio에서 "게시"한 다음 변경된 파일을 수동으로 FTP해야하는 것보다 더 좋은 방법이 있어야합니까?

Occam의 면도기는 일반적으로 선호되는 접근 방식입니다. 간단할수록 좋습니다. 합병증이 거의 없거나 전혀없는 FTP는 쉽습니다. XCOPY, Filezilla 또는 WSFTP를 사용하는 사람도 있고 아직 익숙하지 않은 MS Web Deployment Tool을 사용하는 사람도 있지만 ASP.NET 웹 응용 프로그램을 배포하는 더 좋은 방법이 있습니다. 일반적으로 앱). IMO, 개발 초기부터 배포를 고려하면 배포 는 미래에 상대적으로 고통이없는 부드러운 배포하게 웹 응용 프로그램과 통합 될 수있다.

규모, 복잡성 및 사용자 수 (수백 명에서 수만 명)에 이르는 ASP.NET 웹앱을 개발하는 여러 회사에서 근무한 .NET 개발자 인 IMO '배포'는 종종 가장 "유동적 인"주제입니다. 일부 조직은 관료주의 측면에서 너무 멀리 가져 가고 다른 조직은 배포 관련 문제를 전혀 다루지 않습니다. 내 경험상 배포 관련 문제는 어려움 / 실패 측면에서 3 가지 범주 중 하나 이상에 속합니다.

1. 디자인 단계에서는 배포가 무시 되거나 깊이 잊혀집니다. 대부분의 웹 응용 프로그램은 웹 서버와 데이터베이스를 통합하는 경향이 있습니다. 응용 프로그램 코드, 일부 저장 프로 시저 및 데이터베이스 테이블 외에도 배포에는 많은 생각이 필요하지 않습니다. ASP.NET 배포에 원조 할 수있는 것보다 더 많은하지만 대부분의 개발자가 실행하는 실제 응용 프로그램을 얻고 측면에서 산만되는 일을 떠나는 동안의 작업을 하는 방법을 별도의 문제로 배포합니다.

2. 배포는 여러 시스템과 사람들 사이에서 복잡합니다. 복잡성은 나쁜 것입니다. MSMQ, T-SQL 저장 프로 시저 및 트리거, Reporting Services, SOAP / XML 메시징, AD 인증, SSAS / SSIS 등에서 사용중인 기술의 수는 사람들의 수를 증가시킵니다. 무엇보다도, 이러한 서로 다른 모든 구성 요소는 일반적으로 조직 내의 다른 엔터티에 의해 관리됩니다. 모든 사람이 서로 동기화되어 있지 않으면 배포가 복잡성을 빠르게 증가시켜 여러 지점의 장애가 발생할 수 있습니다.

3. 게으름, 무관심 또는 의사 소통 및 / 또는 관리 부족 : 문서화가 거의 없거나 전혀없는 통합 커뮤니케이션 및 프로토콜에 이르기까지 비교적 간단한 프로세스를 망가 뜨리기 가 쉽습니다. 배포는 수행 된 작업을 문서화하는 동안 수많은 검사를 수행하는 간단한 절차 여야하지만 종종 그렇지 않습니다. 대부분의 사람들은 단지 그 사이트가 돌아 가기를 원합니다. 뭔가 때까지 내 경험에 의하면, 사람들은 (프로그래머가 아닌) 정말 상관 없어 정말 망가. 책임은 거의 사실에 한 사람에 빠진다 없습니다 할 아무도 정말 책임이있다, 그래서 실패의 이유가되고 싶어하지 않기 때문에 배포를 일반적으로 분산.

파일이 너무 많기 때문에 실수로 업로드하지 않도록 프로세스를 최대한 자동화해야합니다. 팀은 어떻게합니까?

배포를 자동화 할 공급 업체를 모르는 경우도 있지만 놀라지 않을 것입니다. VBScript / WMI를 통해 솔루션을 스크립팅하거나 솔루션을 일괄 스크립팅 할 수 있지만 더 복잡한 ASP.NET 사이트를 위해 솔루션을 함께 조정해야합니다. 페이지, 데이터베이스 연결 등으로 구성된 단순한 사이트는 응용 프로그램 자체의 복잡성에 따라 배포 작업을 확장 할 필요가 거의 없습니다.

지금까지 필자의 현재 작업에서는 여전히 FTP를 통해 배치되고 많은 파일을 이동합니다. 추악하고 쉽게 조일 수 있으며 정확한 기록이 없습니다. FTP 로그를 통해 빗질 수 있다고 인정했지만 아무도 그렇게 귀찮게하지 않습니다. 우리의 응용 프로그램은 FTP를 넘어서는 많은 필요없이 매우 간단합니다. 팀에서 웹앱을 배포하는 방법은 거의 쓸모가 없습니다. 대신이 기회를 사용하여 더 나은 사례 를 제안하고 싶습니다 .

• 아무것도 가정하지 마십시오. 사용자 계정, R / W / X 권한, ACL, 방화벽, 타이밍 (배포 시기 및 수행 시간 ) 및 가능한 경우 최종 "시작 날짜"전에 모든 환경에 대한 배포를 테스트 하십시오.
• 개발이 실제로 시작되기 전에 배포를 개발에 반영하십시오. 간단한 사이트라면 그렇습니다. 움직이는 부분이 많으면 모든 부분을 고려하여 실제로 빌드하십시오. 계획되는 모든 구성 요소 (코드, 데이터베이스, 보고서, 큐 등) 같은 계획에 있습니다.
• 다른 패리티와 조정하고 효과적이고 효율적으로 의사 소통합니다.
• 가능한 한 많은 관련 정보를 문서화하십시오.
• 환경 : 하나의 웹 서버 대 웹 팜; 32 비트 대 64 비트; 로그 / 오류 / 회전 등을 모니터링하는 방법을 찾으십시오.
• 배포에 도움이되는 도구를 찾거나 빌드하십시오.
• 프로그래밍 가능한 배포가 가능하다면 패러다임을 고수하십시오. 예를 들어, 응용 프로그램의 상태, 배포, 액세스 등을 수행하기위한 기본 수단으로 데이터베이스 서버를 사용하려는 경우 데이터베이스 서버를 응용 프로그램에 굽고 고수하십시오. 반드시 web.config와 같은 XML 파일을 읽는 것을 선호한다면 애플리케이션 배포의 일관된 패러다임을 고수 하십시오. 다른 예 : 일부 조직은 각 환경에서 web.config를 정적 파일로 남겨두고 다른 환경에 배포 해서는 안됩니다 . 오류없이 여러 환경에 배포 할 수있는 기타 프로그램 web.config

이 게시물이 원래 요청 된 질문에 대해 과도 할 수 있음을 알고 있습니다. 불행히도 응용 프로그램의 복잡성이 다양 할 수 있으므로 배포는 단순한 것이 아닙니다. 복잡한 ASP.NET 응용 프로그램을 배포하는 대부분의 조직은 시간 이 지남 에 따라 적어도 적어도 안정적으로 특정 전략을 개발 했다고 확신합니다.