Granted this might be old news but it's still worth repeating.  MSDN has launched a beta version of MSDN which has wiki functionality known nothing other than MSDN Wiki.  I am a big fan, I hope to see the community actively contribute.

http://msdnwiki.microsoft.com

I don't think anyone will argue but the majority of technical books are used for reference.  OK so every so often a new book comes out and you read it cover to cover.  Well that time has come. 

Vincent Maraia has just authored a book called The Build Master.  If you have anything to do with software development then you MUST read this book.  I don't care how good you are, how many products you shipped or if you are already a build master, you MUST read this book.

Every development shop must address most if not all of the topics found in this book.  If you're not, then you really need to invest some time and money in yourself and clean shop.  I guarantee things could be better.  Just ask yourself a few questions:

• Do you have a good concurrent development mailline strategy? Do you know what one is?
• Do you know how to branch and merge?
• Do you version?
• Do you have any automation?
• Do you have a build process?
• Do you have a build team?

If you have answered No to any of these questions then just go buy it now and start reading.  Again regardless no matter who you are, you still need to read this book.

Vincent Maraia, Great Read and Great Job!!! I can't wait for the next one.

Table of Contents

1. Defining a Build
2. Source Tree Configuration
3. Daily Not Nightly Builds
4. The Build Lab
5. Build Tools
6. SNAP Builds
7. The Build Environment
8. Visioning
9. Build Security
10. Managed Code Versus Unmanaged Code Builds
11. Building for International
12. Build Verification Tests
13. Building Setup and Deploying Every Day
14. Ship It
15. Product Support Services
16. Hotfixes or Patch Management
17. Suggested Steps to Change Your Religion or Philosophy (Corporate Culture)
18. Future Build Tools from Microsoft

That was just stupid easy and fast!!!!  Now we will see what all works on it.

So far I am loving it!!!!

Alright I lied, a few cups of Joe.  I got really bold and decided to bring a few laptops up to the local coffee shop and install Vista B2 on one of them.  So far so good I just started Step 2.  I guess I will soon find out what I forgot to backup ;)

More to come....

Like any good geek I have a ton of different machines and always seem to work work off a few monitors at once.  Since I have a few monitors I really didn't need a KVM but I needed a way to get rid of the stacks of keyboards and mice, Multiplicity!!!!   I just installed the trial version and it just rocks.

Long and short, if you don't know anything about MSBuild, it's time to hit the links below.  Honestly it will do nothing but save you time and automate those dreaded processes.  The links below will get you pointed in the right direction.

General Links

• MSBuild Wiki
• MSBuild Documentation
• MSBuild Reference

• MSBuild Forum

Blogs

• MSBuild Blog

Packages

• Microsoft Services (UK) Enterprise Solutions Build Framework (SBF)

Team Build

• Managing Builds with Team Foundation Build
• Administering Team Foundation Build

I have now installed and used TFS at a number of clients.  On every installation the very first question asked has alway been, what is a project?  This question seems to provoke a solid hour of conversation about organization structure and development practices.  No doubt every shop will always be different, regardless you will still derive from some base.  Last night while browsing around on MSDN, I ran across the official "project" party line.  Below is just a snippet from Team Foundation Team Projects.

The Logical Definition of a Team Project

Logically (or conceptually), a team project is a single infrastructure that encompasses all of the separate tools and elements used in the life cycle of the development of a software application. Each software application, or "team project," in development is virtually grouped in its own namespace intended solely for the team project. Therefore, a team project is simply a container isolating all of the tools and artifacts associated with a particular software application in development, such that all other team projects will not have access to those tools or artifacts (for example, source code, work items, and documents).

The team project is the central concept that holds together the team endeavor of creating a specific software technology or product. The team project is the virtual collection of artifacts relevant to a software application on which a team is working. For the team members, the team project concept eliminates the problem of having access to multiple artifacts not relevant to the team project; such an excess of artifacts causes confusion and delays the software development process. At a minimum, the team project consists of a set of tools and artifacts. The team project may also include source control policies, a team project reporting site, and a team project portal. The Team Foundation team project allows the process template, during the creation of a team project, to select which tools are relevant and will be added in the team project container.

The team project concept enhances reporting across all the tools used by the team. In the past, cross-tool reporting was challenging because the data from different tools was not related. For example, if a software developer wanted to obtain a cross-tool report on defects, he or she would have to distinguish the defects from multiple projects, since the defects were all stored in a common location. A team project is created in a namespace containing only tools and artifacts relevant to the software project; therefore a common filter is created which can relate different artifacts from different tools.

A single Team Foundation Server server may contain multiple team projects, each of which are created in a separate namespace, such that a document named X in namespace A is not the same as a document named X in namespace B. Creating a team project in a separate namespace allow artifacts or tools to be unique to the team project for which they belong, such that a tool or artifact contained in team project A is not accessible to a software developer working on team project B.

MSDN | Team Foundation Team Projects, http://msdn2.microsoft.com/en-us/library/ms181234(VS.80).aspx

Let's face it if you are on a big enterprise development project you most likely will have both platforms, Java and .Net.  I am a big fan when it comes to using the right tool for the job.  I have been lucky enough to see Teamprise in action on some heterogeneous projects I have been on.  It's great to see a product like it harness the power and vision of the TFS platform.

Nice job goes out to the staff at Teamprise!