How to do daily build for .net project from A - Z?

Question

I'm a newbie developer who want to learn software development process better. My questions are:

1. what is daily-build in general?
2. what's the difference if I build my own project in VS?
3. how do we do it the best way for .net project (preferably using TFS)?
4. more things that I should/have-to know about?

Any reference to an article/books/other questions are welcome.

Thanks

Foulmouthed

good start: google.ru/search?q=continuous+integration+tutorial – Implement

also try this: jetbrains.com/teamcity – Implement

Are you using Team Foundation Server or a source control system? – Jeep

Answer 1

1) From the Wikipedia entry:

A daily build or nightly build is the practice of each day doing a software build of the latest version of a program. This is so it can first be compiled to ensure that all required dependencies are present, and possibly tested to show no bugs have been introduced. The daily build is also often publicly available allowing access to the latest features for feedback.

2) There should be no difference between a nightly build and a build from VS, however the idea behind a daily build is that it is automated. That way you can schedule it to run at 3 AM :)

It would also be a good idea to run verification steps (for example, unit or functional tests) to verify nothing has been broken in the latest build. By doing so you can guarantee that the build compiles and is in good working order. That way you can deploy a fresh build at-will.

Without such a process in place, if someone needs a build you never really know how long it might take to deliver it to them. You may be able to just build it in VS without any trouble, or you may have have to fix up parts of the code just to get it to build. This becomes a bigger problem when your build is large and consists of multiple solutions that each need to be built separately.

3) You could create a batch script that runs the build for you, of you could use a tool for this purpose. For more information see: what-tool-to-use-for-automatic-nightly-builds. Some of their suggestions include:

• CruiseControl.NET
• Visual Build
• Team City

Allerie

It's usually good practice to run a few build verification tests on daily builds (they're a bit like basic sanity tests or smoke tests) to ensure nothing obvious is broken – Jeep

Answer 2

Article from Joel. Good to read.

Chaperone

Answer 3

A daily build is mostly an automated build, build by a central server. The difference in building your own project is that you get aware of all DLL packaged in your application, code not checked in in source control, local dependencies, etc.. The final compiled application and DLL's are the same as the one's you build locally.

We use Hudson for overnight builds but you can also use Cruise control.Net. Because we do Java & .NET Hudson is the best solution. If you have the Team Foundation server from MS you could also use this.

Please look at this for integrating Hudson and C#.

Also consider integrating Stylecop, FXCop and Unit testing in your build server.

Colosseum

Answer 4

There is an excellent article from Martin Fowler on this topic

http://martinfowler.com/articles/continuousIntegration.html

I personally disagree that building source code from you development env is same as doing a nightly build or daily build. Development environment is flooded with components, SDK's, libraries and resources that sometime hide loose ends. Doing a nightly build on a build machine is the best way to go.

Also doing a build from your own machine prevents daily check-ins to mainstream code. Again a bad practice.

A nightly build should work with minimum required build tools and libraries. Using whole dev env on build machine is a bad idea. A complete build would also have some quick and dirty - shallow automated tests to run on code after it's compiled, build, and deployed in test/pre-prod env. NUnit, Selenium, and FxCop are your friends.

Wellknit

Answer 5

1. An automated build every day (or night) of the complete system. The build system report build errors my mail, etc.
2. It builds on a separate machine, it makes sure you have not forgotten to check in any files, or have installed undocumented dependencies on your machine only. And it reports errors.
3. Don't stop at daily builds, go for continuous integration that builds after each check in. Have a look at Cruisecontrol.net.

Tuxedo

Answer 6

1. Daily builds are intended to ensure that at least once a day your application is in buildable state. They are usually run by an automated process. Many teams prefer to have continuous integration builds that are prepared after every check-in to the repository.

2. Automated daily process has the advantage of being automated :) You also can set it up to perform various auxiliary tasks: from running unit tests to automatically deploying server components. When you're building on your dev machine, you are ensuring that your local copy is valid and compilable, while CI server asserts the same about your repository.

3. CruiseControl.NET is a popular solution. You may also consider using Rake.

Duchy

Answer 7

1) A daily build is a complete soup to nuts build of your code base and the processes that the installer would go through including testing, installation, and potentially removal.

2) That is a local build, there should be no real difference except you will only be compiling and testing the code not necessarily the application process.

3) It is up in the air, depends on budget,team, among other things.

4) The article by Joel as was posted previously.

Elwina

Answer 8

what is daily-build in general?

"Daily build" is a part of "continuous integration", and means that a complete project is built regularly and automatically. Typically this happens at least daily, or even more frequently if possible, maybe even after every change.

The main goal is to make sure the project can always be built; also, various tests can be run as part of the build, you can automatically deploy to a testing environment, generate installers for further testing etc. .

what's the difference if I build my own project in VS?

It happens automatically, and using the default configuration. This makes sure the project always builds correctly, and not only on your system (e.g. because you have a special config which you forgot to check into version control, or you have a particular IDE installed).

how do we do it the best way for .net project?

Use a CI (continous integration) server, e.g. CruiseControl.NET. There are several available.

Greff