This is part of a larger series in building a proper build process. For more information and additional series links, check out the introductory post.
Under Construction:The language in these posts may be a little terse at first, but I’ll be fleshing it out over time – be sure to check back!]
Why Undertake This (Plus: Look at my Presentation!)
I’ve seen too many instances in various jobs and projects where the build/integration process is not afforded due diligence (or any diligence, really).
I decided I needed to do something about it. Part experiment, part challenge, part reference guide. I’m going to see if I can put together an entire continuous integration / build process for .NET environments from scratch.
Below, you can find some slides from a presentation I gave at work (and yes, the design ideas are at times ripped directly from Zach Holman’s article as I tried to emulate his style. He’s awesome, and I’m shameless. Credit was given.) This talk highlighted the benefits of inte”great”ion and what I was about to undertake.
In short, dear reader, my end desire is to have a completely integrated build process for .NET using (almost) free and/or open-source tools, and to share my process with you.
The build process so far will include the following:
- Subversion repository on CentOS VM
- An ASP.NET MVC Project Added to the Source control
- Trac web site connected to Subversion repository on CentOS VM
- Build Server VM (Windows Server 2008 R2)
- CruiseControl.NET running on the Build Server
- Building the Project with MSBuild via CCNet
- Building a Release build via CCNet; if successful, publishes to AppHarber via a cloned git repository
- NUnit Tests
- NCover code coverage metrics
- SpecFlow User Acceptance Test / Feature Test coverage
- Selenium Server as a web driver to execute specflow tests
- Selenium Grid executing tests on multiple OSes / platforms
- Adding FxCop to the mix to check my coding standards
- Adding StyleCop to the mix to make sure the code is consistently written.
- Utilizing Nuget packages and Octopus to transform releases for different environments.
Hoo-boy, Here We Go
It’s a lofty goal – especially for someone who’s not a pro developer – but I’m excited for everything I’m about to learn during this process.
Onward and Upward!
I'd love to hear any comments on this series. Find it useful? Think there's a better way to implement the technique or something I should have mentioned? Please drop a line in the comments to help me improve the series!
This article is Part 1 in a 10-Part Series.
- Part 1 - This Article
- Part 2 - Building A Build Process: Groundwork -- The VMs
- Part 3 - Building a Build Process: OS Setup
- Part 4 - Building a Build Process: Source Code Management via Subversion and Apache on CentOS
- Part 5 - Building a Build Process: Securing Subversion's Connection via TLS
- Part 6 - Building a Build Process: TortoiseSVN Client Connection and Repository Layout
- Part 7 - Building a Build Process: Creating a Custom MSBuild File
- Part 8 - Building a Build Process, Part 6b: MSBuild Integration With Cassini and Visual Studio
- Part 9 - Building a Build Process: Installing CruiseControl.NET
- Part 10 - Building a Build Process: CruiseControl.NET Preparation