C# 빌드 머신을 어떻게 그리고 왜 설정합니까? [닫은

https://stackoverflow.com/questions/616149

03-07-2019
|

문제

C# 프로젝트에서 소규모 (4 인) 개발 팀과 함께 일하고 있습니다. 나는 이것이 좋은 것이라는 것을 이해하기 때문에 프로젝트의 야간 빌드와 테스트를 수행 할 빌드 머신을 설정할 것을 제안했습니다. 문제는 여기에 예산이 많지 않기 때문에 권력에 대한 비용을 정당화해야한다는 것입니다. 그래서 알고 싶습니다.

어떤 종류의 도구/라이센스가 필요합니까? 현재 우리는 Visual Studio 및 Smart Assembly를 사용하여 구축하고 소스 제어를 위해 성과를 거두고 있습니다. 다른 것을 필요로합니까, 아니면 자동 스크립트를 실행하기위한 Cron 작업과 동등합니까?

깨진 빌드의 표시를 제외하고는 정확히 무엇을 얻을 수 있습니까? 이 스크립트에서 실행할이 솔루션 (SLN 파일)에서 테스트 프로젝트를 설정해야 특정 기능을 테스트 할 수 있습니까? 우리는 현재 두 가지 테스트를 가지고 있습니다. 왜냐하면 우리는 좋은 단위 테스트를 할 시간이 없었기 때문입니다.

이것에 어떤 종류의 하드웨어가 필요합니까?

빌드가 완료되고 테스트되면 FTP 사이트에 빌드를 올리거나 내부 액세스를위한 다른 방법이있는 것이 일반적인 관행입니까? 아이디어는이 기계가 만든 것입니다 그만큼 빌드하고 우리 모두는 그것에 가지만 우리가해야한다면 디버그 빌드를 만들 수 있습니다.

이런 종류의 빌드를 얼마나 자주 만들어야합니까?

공간은 어떻게 관리됩니까? 우리가 야간 건물을 만들면, 우리는 모든 오래된 빌드를 유지하거나 약 일주일 정도 후에 그들을 버리기 시작해야합니까?

여기서 보지 못하는 다른 것이 있습니까?

나는 이것이 매우 큰 주제라는 것을 알고 있으며, 방금 시작합니다. 이 질문의 복제본을 찾을 수 없었고, 책이 있다면 방금 가져와야합니다. 알려주세요.

편집 : 마침내 작동하게되었습니다! Hudson은 완전히 환상적이며 FXCOP는 우리가 구현 한 일부 기능이 실제로 불완전하다는 것을 보여줍니다. 또한 설치 프로그램 유형을 구식 VDPROJ에서 New Hotness Wix로 변경해야했습니다.

기본적으로주의를 기울이는 사람들을 위해 명령 줄에서 빌드를 실행할 수 있다면 Hudson에 넣을 수 있습니다. MSBuild를 통해 명령 줄에서 빌드를 실행하는 것은 도구가 최신 상태가되기 때문에 유용한 연습 자체입니다.

해결책

업데이트: 젠킨스 허드슨의 최신 버전입니다. 모든 사람은 이제 Jenkins를 사용해야합니다. 그에 따라 링크를 업데이트하겠습니다.

허드슨 강 무료로 구성하기 쉽고 VM에서 쉽게 실행됩니다.

부분적으로 나의 오래된 포스트에서 :

우리는 그것을 사용합니다

Windows 서비스를 배포합니다
웹 서비스를 배포합니다
MSTESTS 실행 및 모든 JUNIT 테스트만큼 많은 정보 표시
낮은, 의학, 높은 작업을 추적하십시오
트렌드 그래프 경고 및 오류

다음은 Hudson이 지원하는 .NET 제품 중 일부입니다.

또한, 신은 당신이 시각적 소스 안전을 사용하고있는 것을 금지하고, 그것은 또한 그것을 지원합니다. 나는 당신을 살펴 보는 것이 좋습니다 Hudson을 사용한 .NET 프로젝트 구축에 관한 Redsolo의 기사

당신의 질문

큐: 어떤 종류의 도구/라이센스가 필요합니까? 현재 우리는 Visual Studio 및 Smart Assembly를 사용하여 구축하고 소스 제어를 위해 성과를 거두고 있습니다. 다른 것을 필요로합니까, 아니면 자동 스크립트를 실행하기위한 Cron 작업과 동등합니까?
ㅏ: 방금 Windows Server OS를 설치하는 신선한 패치 된 VM의 신선한 사본에 Visual Studio를 설치했습니다. 따라서이를 처리하려면 라이센스가 필요합니다. Hudson은 Windows 서비스로 자체 설치하고 Port 8080에서 실행되며 업데이트 된 코드를 위해 코드 저장소를 스캔하려는 빈도를 구성하거나 특정 시간에 빌드하도록 지시 할 수 있습니다. 브라우저를 통해 모두 구성 할 수 있습니다.
큐: 깨진 빌드의 표시를 제외하고는 정확히 무엇을 얻을 수 있습니까? 이 스크립트에서 실행할이 솔루션 (SLN 파일)에서 테스트 프로젝트를 설정해야 특정 기능을 테스트 할 수 있습니까? 우리는 현재 두 가지 테스트를 가지고 있습니다. 왜냐하면 우리는 좋은 단위 테스트를 할 시간이 없었기 때문입니다.

ㅏ: 빌드가 처음 실패하거나 불안정 해지면 이메일을 받게됩니다. 단위 테스트가 실패하거나 설정 한 여러 가지 기준을 통해 불안정 할 수있는 경우 빌드가 불안정합니다. 단위 테스트 또는 빌드가 실패하면 이메일을 보내면 어디서, 왜, 어떻게 실패했는지 알려줍니다. 내 구성을 사용하면 다음을 얻습니다.
- 마지막 작업 빌드 이후 모든 커밋 목록
- 그 커밋에 대한 메모를하십시오
- 커밋에서 파일 목록이 변경되었습니다
- 빌드 자체의 콘솔 출력으로 오류 또는 테스트 실패를 보여줍니다.
큐: 이것에 어떤 종류의 하드웨어가 필요합니까?

ㅏ: VM으로 충분합니다
큐: 빌드가 완료되고 테스트되면 FTP 사이트에 빌드를 올리거나 내부 액세스를위한 다른 방법이있는 것이 일반적인 관행입니까? 아이디어는이 기계가 빌드를 만들고 우리 모두가 그것을 만들지 만 우리가해야한다면 디버그 빌드를 만들 수 있다는 것입니다.

ㅏ: Hudson은 MD5 해시를 통해 ID를 포함하고, 업로드하고, 복사하고, 아카이브 등을 포함하여 원하는대로 원하는 모든 것을 할 수 있습니다.이를 자동으로 수행하고 빌드 아티팩트의 장기적인 기록을 제공합니다.
큐: 이런 종류의 빌드를 얼마나 자주 만들어야합니까?

ㅏ: 우리는 매 시간마다 SVN을 설문 조사하고 코드 변경을 찾고 빌드를 실행합니다. 야간은 괜찮지 만, 어제 일한 일이 있기 때문에 다소 쓸모없는 IMO는 아침에 들어올 때 마음에 신선하지 않을 것입니다.
큐: 공간은 어떻게 관리됩니까? 우리가 야간 건물을 만들면, 우리는 모든 오래된 빌드를 유지하거나 약 일주일 정도 후에 그들을 버리기 시작해야합니까?

ㅏ: 오랫동안 빌드 아티팩트를 장기 저장소로 옮기거나 삭제하지만 텍스트 파일 / XML 파일에 저장된 모든 데이터를 보관할 수 있습니다. verrrry 작은 공간이있는 서버. 또한 Hudson을 설정하여 건물의 후행 #에서 유물을 유지할 수 있습니다.
큐: 여기서 보지 못하는 다른 것이 있습니까?

ㅏ: 아뇨, 지금 허드슨을 데려 가서 실망하지 않을거야!

다른 팁

우리는 다음 콤보로 큰 행운을 빕니다.

Visual Studio (특히 MSBuild.exe 명령 줄 도구를 사용하여 솔루션 파일을 전달합니다. MSBuild 스크립트의 필요성을 제거합니다)
넌트 (MSBuild보다 XML 구문/작업 라이브러리와 같이 P4 SRC 제어 작업을위한 옵션도 있습니다)
cruisecontrol.net - 모니터링/시작 빌드를위한 웹 대시 보드에 내장되었습니다.

CCNET은 빌드가 성공/실패 할 때 이메일을 보낼 알림을 내장했습니다.

정당화 : 이것은 수동 빌드를 수행하는 개발자를 제거하고 방정식에서 인간의 오류를 가져 오기 위해 많은 노력을 기울입니다. 이 효과를 정량화하는 것은 매우 어렵지만 일단 그렇게하면 다시는 돌아 가지 않을 것입니다. 소프트웨어를 구축하고 해제하기위한 반복 가능한 프로세스가있는 것이 가장 중요합니다. 나는 당신이 그들이 손으로 소프트웨어를 구축하는 곳이었고, 그것은 야생에서 나옵니다. 당신의 빌드 녀석은 "죄송합니다. 나는 그 새로운 DLL을 포함시키는 것을 잊었을 것입니다!"

하드웨어 : 가능한 한 강력합니다. 더 많은 전력/메모리 = 더 빠른 빌드 시간. 당신이 그것을 감당할 수 있다면, 그룹이 아무리 작더라도 최고 수준의 빌드 머신을 얻는 것을 후회하지 않을 것입니다.

우주 : 많은 하드 디스크 공간을 확보하는 데 도움이됩니다. 빌드가 시작될 때마다 중간 파일을 삭제하기 위해 Nant 스크립트를 작성할 수 있으므로 실제 문제는 로그 이력 및 기존 응용 프로그램 설치 업체를 유지하는 것입니다. 디스크 공간을 모니터링하고 경고를 보내는 소프트웨어가 있습니다. 그런 다음 드라이브를 수동으로 정리합니다. 일반적으로 3-4 개월마다 수행해야합니다.

빌드 알림 : 이것은 CCNET에 내장되어 있지만 추가 단계로 자동 테스트를 추가하려면 Get-Go에서 프로젝트에이를 작성하십시오. 프로젝트가 커지면 테스트를 지원하기가 매우 어렵습니다. 테스트 프레임 워크에 대한 많은 정보가 있으므로 (아마도 많은 정보에 대한 정보도있을 것입니다), 특정 도구의 이름을 지정하는 것을 연기하겠습니다.

이전 직장에서 우리는 사용했습니다 TeamCity. 사용하기가 매우 쉽고 강력합니다. 약간의 제한과 함께 무료로 사용할 수 있습니다. 튜토리얼도 있습니다 멍청한 캐스트. 우리가 cruisecontrol.net을 사용하지 않은 이유는 우리가 소규모 프로젝트를 많이 가지고 있기 때문에 cc.net에 각 프로젝트를 설정하는 것은 매우 고통 스럽기 때문입니다. 나는 TeamCity를 강력히 추천합니다. 당신이 오픈 소스를 향해 있는지 요약하면 CC.net은 약간 높은 학습 곡선을 가진 그랜드 아빠입니다. 예산이 확실히 TeamCity와 함께 이동하거나 무료 버전을 확인할 수있게하는 경우.

어떻게? Carel Lotz 's를 살펴보십시오 블로그.

왜요? 내가 생각할 수있는 몇 가지 이유가 있습니다.

적절하게 구현 될 때 작업 빌드는 모든 개발자가 ~할 수 있다 빌드가 녹색 일 때 기계를 구축하십시오
작업 빌드는 올바르게 구현 될 때 언제든지 배포 할 준비가되었음을 의미합니다.
작업 빌드는 올바르게 구현 될 때 출시 된 모든 것이 소스 제어 시스템으로 여행했음을 의미합니다.
작업 빌드는 올바르게 구현 될 때 조기 및 종종 통합하여 통합 위험을 줄임을 의미합니다.

마틴 파울러의 기사 지속적인 통합 결정적인 텍스트로 남아 있습니다. 그것을보세요!

유리한 주요 주장은 가능한 빨리 빌드 또는 실패 테스트가 실패하도록 최대한 빨리 개발 프로세스 비용을 절감 할 것이라는 점입니다.

여러 개발자의 작업을 통합하는 문제는 팀 성장의 주요 위험입니다. 팀이 커질수록 작업을 조정하고 서로의 변화를 엉망으로 만드는 것을 막기가 더 어려워집니다. 유일한 좋은 해결책은 완료 될 때 소규모 작업 (때때로 "스토리"라고 함)을 확인함으로써 "초기 및 자주"라고 말하는 것입니다.

하루 종일 체크인 할 때마다 빌드 머신을 재건해야합니다. 크루즈 컨트롤을 사용하면 빌드가 고장날 때 빨간색으로 바뀌는 작업 표시 줄에 아이콘을 얻을 수 있습니다.

그런 다음 소스 버전에 레이블이 지정된 (고유 한 빌드 번호가 주어진) 밤에 완전한 청정 빌드를 수행하여 이해 관계자 (제품 관리자, QA People)에게 게시하도록 선택할 수 있습니다. 버그가보고되면 알려진 빌드 번호에 위배됩니다 (매우 중요합니다).

이상적으로는 빌드를 다운로드 할 수있는 내부 사이트가 있어야하며 클릭하여 전날 밤 빌드를 게시 할 수있는 버튼이 있어야합니다.

Mjmarsh가 위대한 기초를 마련한 이후로 Mjmarsh가 말한 것을 조금 구축하려고 노력했습니다.

비주얼 스튜디오. MSBuild는 잘 작동합니다.
넌트.
nantcontrib. 이것은 Perforce 운영과 같은 추가 작업을 제공합니다.
cruisecontrol.net. 이것은 다시 기본적으로 "빌드 대시 보드"입니다.

위의 모든 것 (VS를 위해 저장)은 오픈 소스이므로 추가 라이센스를 보지 않습니다.

Earwicker가 언급했듯이 일찍 건축하고 자주 빌드하십시오. 무언가가 부러지고 전달 가능한 것을 생산할 수 있다는 것을 알면 일찍 물건을 잡는 데 유용합니다.

Nant는 작업을 포함합니다 NUNIT/NUNIT2 또한 실제로 장치 테스트를 자동화 할 수 있습니다. 그런 다음 결과에 스타일 시트를 적용 할 수 있으며 CruiseControl.net이 제공하는 프레임 워크의 도움으로 모든 빌드에 대해 잘 읽을 수 있고 인쇄 가능한 단위 테스트 결과가 있습니다.

동일하게 적용됩니다 NDOC 직무. 모든 빌드마다 문서를 제작하고 사용할 수 있도록하십시오.

당신은 심지어 사용할 수 있습니다 exec 예를 들어 다른 명령을 실행하는 작업 (예 : InstallShield를 사용하여 Windows Installer를 생성합니다.

아이디어는 인간이 실수를 저지르기 때문에 가능한 한 많이 빌드를 자동화하는 것입니다. 앞쪽에 소요되는 시간은 길을 따라 내려가는 시간입니다. 사람들은 빌드 프로세스를 통해 빌드를 보모 할 필요가 없습니다. 빌드의 모든 단계를 식별하고 각 작업에 대한 Nant 스크립트를 작성하고 전체 빌드 프로세스를 완전히 자동화 할 때까지 NANT 스크립트를 하나씩 구축하십시오. 그런 다음 모든 빌드를 한 곳에두고 비교 목적에 적합합니다. 빌드 380에서 잘 작동 한 Build 426에서 무언가가 깨질까요? 글쎄, 테스트 할 준비가 된 결과물이 있습니다. 가져 가서 테스트하십시오.

라이센스가 필요하지 않습니다. cruisecontrol.net은 자유롭게 사용할 수 있으며 빌드 할 .NET SDK 만 있으면됩니다.
자동화 된 단위 테스트가 없어도 빌드 서버는 여전히 건물 릴리스를위한 제어 환경을 제공합니다. "John은 보통 그의 기계를 기반으로하지만 그는 아프다. 어떤 이유로 든 내 기계를 만들 수 없다"
지금은 가상 PC 세션에 하나가 설정되어 있습니다.
예. 빌드는 접근 가능한 곳에 버려야합니다. 개발 빌드는 디버깅을 켜야합니다. 릴리스 빌드는 꺼져 있어야합니다.
얼마나 자주 당신에게 달려 있습니다. 올바르게 설정하면 각 체크인이 거의 오버 헤드가 거의 없으면 빌드 할 수 있습니다. 단위 테스트가 있거나 계획 중이라면 좋은 아이디어입니다.
필요에 따라 이정표와 릴리스를 유지하십시오. 다른 것은 얼마나 자주 구축하는지에 달려 있습니다 : 지속적으로? 버리세요. 일일? 일주일 가치를 유지하십시오. 주간? 2 개월의 가치를 유지하십시오.

프로젝트가 클수록 자동화 된 빌드 머신의 이점을 더 많이 볼 수 있습니다.

그것은 빌드의 건강에 관한 것입니다. 이것이 당신을 얻는 것은 빌드에서 일어나고 싶은 모든 유형의 일을 설정할 수 있다는 것입니다. 이 중에서 테스트, 정적 분석 및 프로파일 러를 실행할 수 있습니다. 최근에 응용 프로그램의 해당 부분에서 작업했을 때 문제는 훨씬 빠르게 다루어집니다. 당신이 작은 변화를 저지르면, 그것은 당신이 그것을 어디에 끊었는지 거의 알려줍니다 :)

물론 이것은 모든 체크인 (연속 통합)마다 빌드하도록 설정합니다.

또한 QA와 Dev가 더 가까워지는 데 도움이 될 수 있습니다. 프로파일 러 및 DEV 팀에 대한 피드백을 향상시키는 기능과 함께 기능 테스트를 실행할 수 있습니다. 그렇다고 기능 테스트가 모든 체크인마다 실행되는 것은 아니지만 (시간이 걸릴 수 있음) 전체 팀에 공통적 인 도구로 빌드/테스트를 설정합니다. 연기 테스트를 자동화하고 있으므로 제 경우에는 더욱 면밀히 협력합니다.

이유 : 10 년 전 우리는 소프트웨어 개발자로서 Nth Degree에 무언가를 분석하는 데 사용 된 소프트웨어 개발자로서 문서 (인간 언어로 작성)를 '사인 오프'하고 코드를 작성하기 시작합니다. 우리는 단위 테스트, 문자열 테스트를 한 다음 시스템 테스트를 치릅니다. 시스템 전체가 처음으로 함께 실행되는 경우, 때로는 문서가 서명 된 후 일주일 또는 몇 달 후에 함께 실행됩니다. 그때 우리는 모든 것을 분석 할 때 우리가 가진 모든 가정과 오해를 발견 할 것입니다.

지속적인 통합 및 아이디어로 인해 완전한 (초기에는 매우 간단한) 시스템이 끝날 수 있습니다. 시간이 지남에 따라 시스템 기능은 직교로 구축됩니다. 완전한 빌드를 할 때마다 시스템 테스트를 일찍 그리고 자주 수행합니다. 즉, 버그와 가정을 최대한 빨리 찾아서 수정하는 것이 가장 저렴한 시간 일 때 버그와 가정을 최대한 빨리 찾아 고정시킵니다.

How : How에 관해서는, 나는 조금 전에 이것에 대해 블로그를 작성했습니다 : [ 여기를 클릭하십시오]

8 개 이상의 게시물은 .NET 솔루션을 위해 Windows 환경에서 Jenkins 서버를 설정하는 방법을 단계별로 진행합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow