### Cake build

5th of Jan 2019: a lot has been happening since I initially wrote this post. Azure DevOps released a free tier for open source projects, the Cake and GitVersion contributors have been hard at work to take advantage of the latest features of .NET Core. So much things have changed that I decided to update this post to reflect the current state of affairs (inclusion of Azure DevOps, upgrade to .NET Core 2.2, utilisation of .NET Core global tools and removing the Mono requirement on Unix platforms).

As a developer I’m amazed by the number of free tools and services available. I wanted to create an end-to-end demo of a CI/CD pipeline that would include:

For my purpose I wanted anonymous users to have access to a read-only view. I initially selected AppVeyor as it seems to be the most popular choice for .NET open-source projects. But while browsing around I discovered than projects were often using more than one platform. Travis CI and CircleCI seemed to be the two other prevailing options. Since the initial version of this post, Azure DevOps has released a free and unlimited plan for open source projects. I decided to leverage the four platforms so that I could highlight their pros and cons.

After eyeing it for a while I finally decided to buy Advanced .NET Debugging by Mario Hewardt. I’ve been studying WinDbg for some time and consider myself somewhere between beginner and intermediate level. To my dismay I got stuck on the first excercise! Luckily I didn’t give up and finally stumbled on a blog post that unblocked me. This series has for goal to make Advanced .NET Debugging more accessible to people - quite like me - that haven’t grasped all the concepts yet.

## Prerequisites

### Testing anti-patterns #1

I often ask candidates to define a good unit test. This is the starting point of a conversation around testing strategies and delivering value. Over the years I’ve heard opinions ranging from the 100% coverage, passing by testing is for testers, all the way to we don't do automated testing. If the notion of a good test can be subjective, it is easier to identify a bad test. Bloggers have written about this topic at length but I thought I would try paraphrasing the same content hoping nobody would notice.

I must admit I have written - quite - a few bad tests myself and that’s fine. We all make mistakes, how we handle those mistakes is what help us grow:

• It’s important to understand why the mistake happened and put in place measures to prevent the same mistake from happening again
• Equally we should challenge existing practices, they might be there for a good reason but they might instead be there for a bad reason
This new series is an attempt to improve my WinDbg skills. The concept is to create faulty applications and troubleshoot the issue using WinDbg pretending that I have no prior knowledge of the code.