C # 빌드 머신을 어떻게 그리고 왜 설정합니까? [닫은]
C # 프로젝트에서 소규모 (4 인) 개발 팀과 협력하고 있습니다. 나는 이것이 좋은 것임을 이해하기 때문에 프로젝트의 야간 빌드 및 테스트를 수행 할 빌드 머신을 제안했습니다. 문제는, 우리는 여기에 예산이 많지 않기 때문에 그 비용에 대한 비용을 정당화해야한다는 것입니다. 그래서 알고 싶습니다.
나는 이것이 매우 큰 주제라는 것을 알고 있으며, 이제 막 시작했습니다. 여기에서이 질문의 사본을 찾을 수 없었으며 거기에 책이 있으면 알려주세요.
편집 : 마침내 작동하도록했습니다! 허드슨은 완전히 환상적이며 FxCop은 우리가 구현했다고 생각한 일부 기능이 실제로 불완전하다는 것을 보여줍니다. 또한 설치 프로그램 유형을 Old-and-Busted vdproj에서 New Hotness WiX로 변경해야했습니다.
기본적으로주의를 기울이는 사람들을 위해 명령 줄에서 빌드를 실행할 수 있다면 허드슨에 넣을 수 있습니다. MSBuild를 통해 명령 줄에서 빌드를 실행하는 것은 도구를 최신 상태로 유지하기 때문에 유용한 연습입니다.
업데이트 : Jenkins 는 Hudson의 최신 버전입니다. 모든 사람이 지금 Jenkins를 사용해야합니다. 그에 따라 링크를 업데이트하겠습니다.
Hudson 은 무료이며 구성이 매우 쉽고 VM에서 쉽게 실행할 수 있습니다.
내 오래된 게시물에서 부분적으로 :
우리는 그것을 사용합니다
- Windows 서비스 배포
- 웹 서비스 배포
- MSTests를 실행하고 모든 junit 테스트만큼 많은 정보를 표시
- 낮고, 높은, 높은 작업을 추적
- 트렌드 그래프 경고 및 오류
허드슨이 지원하는 내장 .net 항목 중 일부는 다음과 같습니다.
또한, 신은 당신이 영상 소스 안전을 사용하는 것을 금지합니다 . 그것은 그것을 지원합니다 . 허드슨을 사용하여 .net 프로젝트를 빌드하는 Redsolo의 기사를 살펴 보는 것이 좋습니다.
당신의 질문
Q : 어떤 도구 / 라이센스가 필요합니까? 현재 Visual Studio 및 Smart Assembly를 사용하여 소스 제어를 구축하고 Perforce를 사용합니다. 자동화 스크립트를 실행하기위한 다른 작업이 필요합니까?
A : 방금 패치 된 Windows 서버 OS 설치를 실행하는 VM의 최신 사본에 Visual Studio를 설치했습니다. 따라서이를 처리하려면 라이센스가 필요합니다. Hudson은 Windows 서비스로 설치되어 포트 8080에서 실행되며 업데이트 된 코드에 대해 코드 저장소를 스캔하는 빈도를 구성하거나 특정 시간에 빌드하도록 지시 할 수 있습니다. 브라우저를 통해 구성 할 수 있습니다.
Q : 빌드가 손상되었다는 표시 외에 정확히 어떤 것이 나에게 도움이됩니까? 이 스크립트에서 실행될이 솔루션 (sln 파일)에 테스트 프로젝트를 설정해야하므로 특정 기능을 테스트 할 수 있습니까? 현재 두 가지 테스트가 있습니다. 좋은 단위 테스트를 수행 할 시간이 없었기 때문입니다.
A : 빌드가 처음 실패하거나 불안정해질 때 이메일이 발송됩니다. 단위 테스트에 실패하거나 설정 한 여러 기준을 통해 불안정한 것으로 표시 될 수있는 경우 빌드가 불안정합니다. 단위 테스트 또는 빌드가 실패하면 이메일로 전송되며 실패한 위치, 이유 및 방법을 알려줍니다. 내 구성으로 우리는 다음을 얻습니다.
- 마지막 작업 빌드 이후의 모든 커밋 목록
- 그 커밋의 메모를 커밋
- 커밋에서 변경된 파일 목록
- 빌드 자체의 콘솔 출력, 오류 또는 테스트 실패 표시
Q : 어떤 종류의 하드웨어가 필요합니까?
A : VM으로 충분합니다
Q: Once a build has been finished and tested, is it a common practice to put that build up on an ftp site or have some other way for internal access? The idea is that this machine makes the build, and we all go to it, but can make debug builds if we have to.
A: Hudson can do whatever you want with it, that includes ID'ing it via the md5 hash, uploading it, copying it, archiving it, etc. It does this automatically and provides you with a long running history of build artifacts.
Q: How often should we make this kind of build?
A: We have ours poll SVN every hour, looking for code changes, then running a build. Nightly is ok, but somewhat worthless IMO since what you've worked on yesterday wont be fresh in your mind in the morning when you get in.
Q: How is space managed? If we make nightly builds, should we keep around all the old builds, or start to ditch them after about a week or so?
A: Thats up to you, after so long I move our build artifacts to long term storage or delete them, but all the data which is stored in text files / xml files I keep around, this lets me store the changelog, trend graphs, etc on the server with verrrry little space consumed. Also you can set Hudson up to only keep artifacts from a trailing # of builds
Q: Is there anything else I'm not seeing here?
A: No, Go get Hudson right now, you wont be disappointed!
We've had great luck with the following combo:
- Visual Studio (specifically, using the MSBuild.exe command line tool and passing it our solution files. removes the need for msbuild scripts)
- NAnt (like the XML syntax/task library better than MSBuild. Also has options for P4 src control operations)
- CruiseControl.net - built in web dashboard for monitoring/starting builds.
CCNet has built in notifiers to send emails when builds succeed/fail
On justification: This takes the load off developers doing manual builds and does a lot to take human error out of the equation. It is very hard to quantify this effect, but once you do it you will never go back. Having a repeatable process to build and release software is paramount. I'm sure you've been places where they build the software by hand and it gets out in the wild, only to have your build guy say "Oops, I must have forgotten to include that new DLL!"
On hardware: as powerful as you can get. More power/memory = faster build times. If you can afford it you'll never regret getting a top-notch build machine, no matter how small the group.
On space: Helps to have plenty of hard disk space. You can craft your NAnt scripts to delete intermediate files every time a build starts, so the real issue is keeping log histories and old application installers. We have software that monitors disk space and sends alerts. Then we clean up the drive manually. Usually needs to be done every 3-4 months.
On build notifications: This is built in to CCNet, but if you are going to add automated testing as an additional step then build this into the project from the get-go. It is extremely hard to back fit tests once a project gets large. There is tons of info on test frameworks out there (probably a ton of info on SO as well), so I'll defer on naming any specific tools.
At my previous workplace we used TeamCity. It's very easy and powerful to use. It can be used for free with some restrictions. There is also a tutorial on Dime Casts. The reason we didn't use CruiseControl.NET is that we had a lot of small projects and it's quite painful to set each one up in CC.NET. I would highly recommend TeamCity. To summarize if you are toward open source then CC.NET is the grand daddy with slightly higher learning curve. If your budget allow you definitely go with TeamCity or check out the free version.
How? Have a look at Carel Lotz's blog.
Why? There are several reasons that I can think of:
- A working build, when properly implemented, means that all your developers can build on their machine when the build is green
- A working build, when properly implemented, means that you are ready to deploy at any time
- A working build, when properly implemented, means that whatever you release has made a trip to your source control system.
- A working build, when properly implemented, means that you integrate early and often, reducing your integration risk.
Martin Fowler's article on Continuous Integration remains the definitive text. Have a look at it!
The main argument in favour is that it will cut the cost of your development process, by alerting you as soon as possible that you have a broken build or failing tests.
The problem of integrating the work of multiple developers is the main danger of growing a team. The larger the team gets, the harder it is to coordinate their work and stop them messing with each other's changes. The only good solution is to tell them to "integrate early and often", by checking in small units of work (sometimes called "stories") as they are completed.
You should make the build machine rebuild EVERY time some checks in, throughout the day. With Cruise Control, you can get an icon on your task bar that turns red (and even talks to you!) when the build is broken.
You should then do a nightly full clean build where the source version is labeled (given a unique build number) that you can choose to publish to your stakeholders (product managers, QA people). This is so that when a bug is reported, it is against a known build number (that's extremely important).
Ideally you should have an internal site where builds can be downloaded, and have a button you can click to publish the previous nightly build.
Just trying to build a bit on what mjmarsh said, since he laid a great foundation...
- Visual Studio. MSBuild works fine.
- NAnt.
- NantContrib. This will provide additional tasks such as Perforce operations.
- CruiseControl.net. This is again basically your "build dashboard".
All of the above (save for VS) is open source, so you're not looking at any additional licensing.
As Earwicker mentioned, build early, build often. Knowing something broke, and you can produce a deliverable is useful for catching stuff early on.
NAnt includes tasks for nunit/nunit2 as well, so you can actually automate your unit testing. You can then apply stylesheets to the results, and with the help of the framework provided by CruiseControl.net, have nice readable, printable unit test results for every build.
The same applies to the ndoc task. Have your documentation produced and available, for every build.
You can even use the exec task to execute other commands, for instance, producing a Windows Installer using InstallShield.
The idea is to automate the build as much as possible, because human beings make mistakes. Time spent up front is time saved down the road. People aren't having to babysit the build by going through the build process. Identify all the steps of your build, create NAnt scripts for each task, and build your NAnt scripts one by one until you've wholly automated your entire build process. It also then puts all of your builds in one place, which is good for comparison purposes. Something break in Build 426 that worked fine in Build 380? Well, there are the deliverables ready for testing -- grab them and test away.
- No licenses needed. CruiseControl.net is freely available and only needs the .NET sdk to build.
- A build server, even without automated unit tests still provides a controlled environment for building releases. No more "John usually builds on his machine but he's out sick. For some reason I can't build on my machine"
- Right now I have one set up in a Virtual PC session.
- Yes. The build needs to be dumped somewhere accessible. Development builds should have debugging turned on. Release build should have it turned off.
- How often is up to you. If set up correctly, you can build after each check in will very little overhead. This is a great idea if you have (or are planning on having) unit tests in place.
- Keep milestones and releases as long as required. Anything else depends on how often you build: continuously? throw away. Daily? Keep a week's worth. Weekly? Keep two month's worth.
The larger your project gets the more you will see the benefits of an automated build machine.
It is all about the health of the build. What this gets you is that you can set up any type of things you want to happen with the builds. Among these you can run tests, static analysis, and profiler. Problems are dealt with much much faster, when you recently worked on that part of the application. If you commit small changes, then it almost tells you where you broke it :)
This of course assumes, you set it up to build with every check in (continuous integration).
It also can help get QA and Dev closer. As you can set up functional tests to run with it, along with profiler and anything else that improves feedback to the dev team. This doesn't mean the functional tests run with every check in (can take a while), but you set up builds/tests with tools that are common to the whole team. I have been automating smoke tests, so in my case we collaborate even more closely.
Why: 10 years ago we as software developers used to analyse something to the nth degree get the documents (written in a human language) 'signed off' then start writing code. We would unit test, string test and then we would hit system test: the first time the system as a whole would be run together, sometimes week or months after we got the documents signed off. It was only then that we would uncover all the assumptions and misunderstandings we had when we analysed everything.
Continuous Integration as and idea causes you to build a complete (although, initially, very simple) system end to end. Over time the system functionality is built out orthogonally. Every time you do a complete build you are doing the system test early and often. This means you find and fix bugs and assumptions as early as possible, when it is the cheapest time to fix them.
How: As for the how, I blogged about this a little while ago:[ Click Here]
Over 8 posts it goes step by step on how to set up a Jenkins server in a windows environment for .NET solutions.
참고URL : https://stackoverflow.com/questions/616149/how-and-why-do-i-set-up-a-c-sharp-build-machine
'development' 카테고리의 다른 글
| 'float'vs. 'double'정밀도 (0) | 2020.06.17 |
|---|---|
| AngularJS $ resource RESTful 예제 (0) | 2020.06.17 |
| 생성자 또는 속성 설정자를 통한 종속성 주입? (0) | 2020.06.17 |
| 컴파일이 완료되지 않았습니다 : 프로그램 유형이 이미 있습니다 : com.google.android.gms.internal.measurement.zzabn (0) | 2020.06.17 |
| 여러 파일로 views.py 분할 (0) | 2020.06.17 |