A short post continuing the subject of builds with this one covering the use of virtualised infrastructure.

I would advise any software development department to make use of virtualisation – especially for appliances such as Build Agents. The choice of virtualisation product in a commercial environment typically comes down to one of two choices. Microsoft offer Hyper-V for free as a role on Windows 2008 and newer and VMWare provide ESX (both free and paid versions). Both are excellent solutions though at this time my preference is with VMWare – it’s simply a more mature product with a greater feature set. I have no experience of ESX setup/configuration however and whilst this is an area where Hyper-V scores well I would still put ESX ahead.

Read More…

Tags: Hardware, TFS

Nearing the end of my posts regarding builds, this one describes a TFS build definition.

If you’ve read the previous articles you will know that I consider TFS to have an excellent build eco-system. Other application suites offer similar services but somehow TFS manages to do exactly what’s expected with the minimum of hassle. Whilst many of the concepts are technology agnostic please be warned I’ll be using TFS as my reference point.

I’d first like to touch on how Visual Studio solution (.sln) files are typically used as it has an impact on how each build definition may be configured. Read More…

Tags: TFS, Visual Studio

Continuing on from where I left off, I now move on to discuss the builds themselves.

A build is the term given to the process by which content stored in a code repository is transformed into deliverable artifacts. Most source code is compiled/processed into binary artifacts such as DLLs or EXEs using a known toolset initiated and controlled by a pre-defined build process. Each process usually follows the ‘get latest, build components, run tests and drop build output to deployment folder’ sequence. TFS provides an adequate starter in the shape of the ‘default process’.

Build output can be anything from loose files right up to an installation package. Whilst there is no ‘one size fits all’ answer I would always advocate the provision of an installation package to deploy an application. Using the right technology this can also created as part of the default build process.

Read More…

Tags: TFS

This is Part 2 of a series covering Builds with this post focusing, albeit superficially, on code repositories.

The assumption is you’ve had your application composition and software structure defined and everyone is desperate to get stuck in to code generation. After all, we’re all doing Agile and the business expects results [because of it]!

Developers typically submit code to the repository and move on to the next feature. After all a developer’s purpose is to develop features and the job of pulling the source together is not usually a shared responsibility.

For small development teams, < 5 co-located for example, it’s perfectly possible to get away with the bare minimum. That is Microsoft Visual SourceSafe with the benefit being that it takes no time to install, there’s not a lot of configuration to it and it [mostly] works. There are many horror stories on the Internet regarding VSS but in reality you have to do something to break it, it doesn’t just break itself.

Read More…

Tags: TFS

Part of my role has always required me to understand how to build software reliably. That is both on a developer machine, for the production of debug or release binaries, or as part of an automated build system. I’ve managed builds for 20 years across a number of different systems/platforms and it’s not a subject that has ever been solved for free.

Before anyone can get to building components there’s usually a large amount of [largely unseen] effort required to define application composition, software structure, code repository configuration and deployment plans. I’ll set the scene by defining what I consider those terms to mean:

Read More…

Tags: TFS