.NET 포트폴리오를위한 자동화 된 빌드 플랫폼-최선의 선택? [닫은]


10

상당히 큰 .NET 응용 프로그램 포트폴리오를 유지 관리하는 데 관여합니다. 또한 포트폴리오에는 다른 플랫폼 (기본 C ++, ECLIPS 양식 등) 위에 구축 된 레거시 응용 프로그램이 있습니다.

NAnt 위에 복잡한 빌드 프레임 워크가 있어이 모든 응용 프로그램의 빌드를 관리합니다. 빌드 프레임 워크는 NAnt를 사용하여 여러 가지 다른 작업을 수행합니다.

  • Subversion에서 코드를 가져오고 Subversion에서 태그를 만듭니다.
  • .NET 용 MSBuild 또는 다른 플랫폼 용 다른 컴파일러를 사용하여 코드 작성
  • AssemblyInfo 파일 내부를 들여다보고 버전 번호 증가
  • 빌드 / 릴리스에 포함되어서는 안되는 특정 파일을 삭제하십시오.
  • 배포 폴더에 코드를 해제합니다
  • 백업 목적을위한 우편 번호
  • Windows 서비스를 배포하십시오. 그들을 시작하고 중지
  • 기타.

이러한 작업은 대부분 NAnt만으로 수행 할 수 있지만 NAnt가 환경과 관련된 몇 가지 작업을 수행하기 위해 몇 가지 확장 작업을 작성했습니다. 또한 위의 대부분의 프로세스는 많은 다른 응용 프로그램 빌드 스크립트에서 일반화되고 재사용되므로 논리를 반복하지 않습니다. 따라서 간단한 NAnt 코드가 아니며 간단한 빌드 스크립트가 아닙니다. 빌드를 실행하기 위해 함께 수십 개의 NAnt 파일이 있습니다.

최근 몇 가지 이유로 NAnt에 불만을 표명했습니다. (1) 구문이 끔찍합니다. XML을 기반으로하는 프로그래밍 언어는 유지하기가 정말 끔찍합니다. (2) 프로젝트는 포도 나무에서 죽었습니다. 최근에 수많은 업데이트가 없었으며 실제로 아무도 주도권을 잡고 있지 않은 것 같습니다. .NET 4로 작업하려고하면이 활동 부족으로 인해 약간의 어려움이 발생합니다.

그래서, 그 배경을 모두 벗어난 내 질문이 있습니다. 위의 목록을 기반으로 달성하고자하는 것들 중 일부를 주로 고려하고 있으며 주로 .NET 상점에 있지만 비 .NET 프로젝트를 빌드해야한다는 점을 고려할 때 NAnt에 대한 대안을 고려해야합니다 로 전환?

내 레이더에는 Powershell ( psake 포함 또는 제외 ), MSBuild 자체 및 rake가 있습니다. 이들은 모두 장단점이 있습니다. 예를 들어, MSBuild는 충분히 강력합니까? 나는 그것을 몇 년 전에 사용한 것을 기억하고 NAnt만큼 많은 힘을 가지고 있지 않은 것 같습니다. 레이크를 사용하여 빌드를 수행하기 위해 팀에서 Ruby를 배우도록 정말로 하시겠습니까? psake는 내 포트폴리오를 고정시킬 수있는 프로젝트로 충분히 성숙합니까? Powershell이 ​​"금속에 너무 가까워서"필자가 직접 사용하는 것과 비슷한 자체 빌드 라이브러리를 작성해야합니까?

고려해야 할 다른 도구가 있습니까? 상당히 복잡한 .NET 포트폴리오를 유지 관리하는 데 관심이 있다면 어떤 빌드 도구를보고 계십니까? 귀하의 팀은 현재 무엇을 사용하고 있습니까?

답변:


2

이미 TeamCity를 사용하고 있다면 필요한 기능 대부분에 기존 기능을 사용할 수 있어야합니다. 기본적으로 Visual Studio .sln 파일 작성을 지원하며 모든 프로젝트에 추가 작업이 필요한 경우 빌드 시스템에서 .NET Framework의 .targets 파일을 수정할 수 있으므로 개별 csproj 파일을 변경할 필요가 없습니다.

zip 아티팩트 인 Subversion에서 자동으로 체크 아웃하여 배치 가능한 아티팩트로 간주되는 파일을 제어 할 수 있습니다. 새 버전 (6.0)은 여러 빌드 단계를 허용하므로 아티팩트를 공유에 xcopy 배치 할 수 있습니다.

또한 명령 줄 러너를 통해 빌드의 일부로 실행할 수있는 고유 한 앱 / 태스크를 작성하고 원하는 작업 (예 : Windows 프로세스 시작 / 중지)을 수행 할 수 있습니다.


3

빌드, 배포 및 설치라는 세 가지 활동으로 접근합니다. 우리는 Powershell에 대한 콜 아웃이 적은 빌드 서버에 TFS를 사용합니다. 그런 다음 Powershell을 사용하여 상당히 복잡한 로컬 및 클라우드의 여러 서버에서 모든 배포 및 설치 작업을 수행합니다. MSBuild 또는 다른 도구를 통해 Powershell을 배우는 것에 매우 만족했습니다. 또한 과거에는 Visual Build에 대한 경험이 풍부했습니다.


2

hudson 과 MSBuild를 한 쌍으로 살펴보십시오 . MSBuild의 강력한 기능과 hudson의 플러그인이 제공 됩니다.

예를 들어, MSBuild로 마이그레이션 한 후 MSBuild 스크립트를 실행할 수있을 때까지 hudson을 사용하고 NAnt 스크립트를 실행할 수 있습니다.

구체적으로 요점을 해결하십시오.

  • 서브 버전태깅
  • MSBuild
  • SO 에 AssemblyInfo 엿보기가 요청 되었지만 원하는 해결책이 아닐 수도 있습니다.
  • MSBuild는 쉽게 파일을 삭제할 수 있습니다
  • "배포 폴더로 코드 공개"-빌드 시스템이 해당 단계를 건너 뛰고 여러 방법을 사용하여 자동으로 배치하도록 할 수 있습니다. 또는 원하는 경우 FTP 를 사용할 수 있습니다 .
  • MSBuild 는 압축 가능
  • Windows 서비스, 다시 MSBuild는 당신의 친구입니다.

MSBuild에 대한 정보를 주셔서 감사합니다. 내가 마지막으로 사용하려고했던 것보다 더 많은 힘이있는 것 같습니다. Hudson과 관련하여 현재 사용중인 TeamCity와 같은 다른 CI 서버가 제공하는 것 이상의 이점을 제공합니까? 여기에 너무 많은 현상을 피하려고 노력하고 있으며 빌드 스크립트를 교체하는 동시에 CI 서버를 교체하는 것이 더 고통스러워 보입니다.
RationalGeek

겸손한 의견으로는 TeamCity가 환상적이며 허드슨이 더 좋다고 생각합니다. 그들은 당신이 멋진 것을 원할 때까지 동일한 기능을 수행하는 것을 볼 수 있습니다-허드슨이 이깁니다. 솔직히 hudson은 RSS, SMS, XFD를 통해 최신 상태를 유지하면서 분석하고 (stylecop / fxcop)-> 빌드-> 테스트-> 태그-> 로컬 및 오프 사이트 백업-> 배포 할 수 있습니다.
Steven Evers

흠 ... 팀 시티에서는 불가능한 것은 없지만 허드슨에서는 더 쉬울 것입니다. 어느 쪽이든, 우리가 TC로 어려움을 겪지 않으면 곧 전환 할 것이라고 생각하지 않습니다.
RationalGeek

@ jkohlhepp : 어려움은 같은 공간에 많은 솔루션이 있다는 것입니다. 하루가 끝나면 허드슨 쉬우 며 100 % 무료입니다. TC가 hudson에 가질 수있는 IIRC는 다중 에이전트 빌딩입니다.
Steven Evers

2

내가 사용하는 자동화 된 빌드 스튜디오 . 나는 그것을 제거하고 싶다.

100 % MS Build 또는 Team Foundation Build 로 전환하지 않는 유일한 이유 는 오늘날 완벽하게 작동하는 스크립트를 다시 작성 하는 데 드는 비용 때문입니다. 스크립트는 많이 바뀌지 않습니다 ...

그러나 다음 제품의 경우 다음과 같은 주요 이유로 인해 망설임없이 Team Foundation Build 가 될 것입니다 .

  • 배포가 쉽습니다 (최신 버전 : 2010)
  • Visual StudioTeam Foundation Server 와 완전히 통합되었습니다.
  • MS 빌드와 같은 표준이되고 있습니다
  • 비즈 파크 (무료)

.NET에도 있으므로 TFB를 사용하는 것이 좋습니다.

Bizspark를 신청할 수 없거나 라이센스를 구매할 여유가없는 경우 CruiseControl.NET + MS Build 와 지원 스크립트를 거의 사용할 수 없습니다 . 제가 근무한 대규모 유틸리티 회사에서 CruiseControl.NET 을 사용 하여 모든 프로젝트를 빌드, 테스트, 배포 및보고했습니다. 자동 웹 서비스 배포가 포함되었습니다.


나는이 옵션을 고려하지 않았지만 우리가 TFS를 전혀 사용하지 않기 때문에 우리에게 현실적인 옵션이 될 것이라고 생각하지 않으며 과거 (예산과 다른 이유로) 이전하려고 거부했습니다. 그러나 흥미로운 아이디어 인 제안에 감사드립니다.
RationalGeek

그렇게 광대하지 않습니다. 귀사의 경영진이 가격에 민감한 경우, MS Build가 완벽하게 일치합니다. 나는 MS Build + CruiseControl.NET에서만 일했고 잘 작동했습니다! 내 대답에 추가하겠습니다.

@Pierre 303 : 호기심을 위해 왜 Automated Build Studio를 제거하고 싶습니까?
RationalGeek

@Pierre 303 : TFS의 비용이 유일한 문제는 아닙니다. 내 상점은 대기업의 일부이며 Subversion 및 기타 도구를 표준화했으며 "비표준"으로 TFS를 사용하면 정치적 문제가 발생합니다.
RationalGeek

@ jkohlhepp : 사용하기 쉽지 않고 Visual Studio (적어도 내가 가지고있는 버전)와 잘 통합되지 않았으며 표준이 아닙니다.

2

FinalBuilder 는 멋진 GUI와 빌더 서버 응용 프로그램을 무료로 제공하여 요청한 모든 항목을 수행 할 수 있습니다.


2

현재 MSBuild (> 3000 줄의 스크립트)를 사용하여 현재 수행중인 작업 (예 : 빌드에서 패키징에서 배포까지)을 수행하고 있습니다. CI는 CruiseControl.Net을 사용하고 있으며 앞으로 TeamBuild로 이동할 수 있기를 바랍니다. MSBuild는 번거롭지 만 (XML로 프로그래밍) 특히 일괄 처리 및 종속성 추적에 매우 강력합니다. 새로운 .Net 버전에서는 적극적으로 유지 관리되고 개선되며 Visual Studio 및 TFS의 빌드 시스템의 기초입니다. 또한 Visual Studio 프로젝트 파일은 실제로 MSBuild 프로젝트이며 다양한 확장 점에 연결할 수 있습니다. 은 MSBuild 확장 팩많은 추가 작업이 있으며 프로그래밍 방식으로 직접 작업을 만드는 것이 쉽습니다. 나는 MSBuild에게 진지한 생각을하도록 제안한다. 최근에는 powershell을 배우고 인증서, IIS 등의 설치 및 구성과 같은 배포 단계에서 특정 작업을 쉽게 수행 할 수 있습니다.

구문을 이해하고 정보를 제공하는 VisualStudio에서 MSBuild 프로젝트를 편집하십시오.
MSBuild 런치 패드 -쉘 확장 용
MSBuild SideKicks- 스크립트를 그래픽으로 편집, 실행 및 디버그합니다.


1

아마도 팀 도시를 사용하면 너무 많은 빌드 스크립트를 요구하고 빌드 서버는 충분하지 않습니다. TeamCity 빌드 작업을 이해하고 사용하는 언어 또는 스택에 관계없이 각 글 머리 기호를 달성하는 간단한 스크립트를 쉽게 가질 수 있습니다. 적절하게 연결하십시오.


이러한 답변의 대부분은 CI와 빌드 스크립트를 동일시하는 것으로 보입니다. 나는 항상 빌드 스크립트를 똑똑한 것으로 생각했으며 CI 서버는 트리거를 기반으로 빌드를 시작하는 것으로 간주했습니다. 그러나 아마도 당신이 옳고 이것을 다시 생각해야합니다.
RationalGeek

1

TeamCity를 강력히 추천하며 구성 및 설정이 쉽습니다. MS2008은 vs2008 / 2010의 모든 프로젝트 / 솔루션 파일이 기술적으로 MSBuild 파일이기 때문에 NAnt보다 선호되지만 MSBuild 또는 NAnt로 TeamCity를 구성 할 수 있습니다.

물론, TeamCity는 비용을 지불합니다. psake도 좋은 후보이지만 다른 도구와 비교할 때 Ruby 도구와의 마찰로 인해 개인적으로 갈퀴를 선호합니다.


1
빌드 구성이 20 명 미만이고 사용자가 20 명 미만인 경우 FYI TeamCity는 무료입니다. 또한 오픈 소스 프로젝트 인 경우 무료 무제한 라이센스를 신청할 수 있습니다.
RationalGeek

0

허드슨 을 고려 했습니까 ? Java 응용 프로그램 서버를 실행해야하기 때문에 번거 로울 수 있지만 현재 NAnt 스크립트 를 사용하고 다른 도구를 사용하여 그 위에 빌드 할 수 있다고 생각 합니다 .


Hudson은 지속적인 통합 플랫폼이 아니라 실제로 빌드 플랫폼이 아닙니다. 우리는 CI 서버를 가지고 있습니다-TeamCity는 NAnt와 잘 작동합니다. 그러나 NAnt를 교체하려는 이유는 NAnt 스크립트를 유지 관리하는 것이 어렵 기 때문입니다. Hudson을 통해 현재 스크립트를 사용해도이 문제는 해결되지 않습니다. 그래도 제안 해 주셔서 감사합니다.
RationalGeek

IMHO Hudson은 VS 프로젝트에서 올바르게 수행하는 작업이 매우 제한적입니다. 체크 아웃은 웹 인터페이스와 많은 플러그인을 통해 생성하는 배치 파일을 실행하는 것 외에는 예상과 방식으로 변경 세트와 관련이 없습니다. 그래도 잘 작동하면 좋을 것 같습니다.
Bill
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.