I posted the other day about trying to integrate Let’s Encrypt with Octopus Deploy. Nathan Stohlmann had a great idea of using machine policy health checks as a way of triggering certificate renewal of Octopus Deploy. Here is the powershell to do just that.
I’ve been keen to configure an Octopus Deploy server with Let’s Encrypt certificates. The ultimate goal would be for this to be fully automated so that the the server can maintain it’s own certificates.
TL;DR - This post provides a collection of custom Octopus Deploy steps that can assist with DNS based domain validation to process Let’s Encrypt certificates.
I use GitVersionTask extensively in my projects so that I can get really good automation over my software versioning. I found a performance issue against one repository last year when using GitVersionTask 3.6.0 and greater. The biggest impact this had was on the build agent which provides both validation of the developer commits but also a build for the tester to promote to a test environment for validation. My team was hitting a large bottleneck because of the slow builds.
This performance issue by no means devalues GitVersionTask and we will continue to use it regardless of performance. It also seems like we are an outlier in how GitVersionTask is performing against a specific repository. I have the utmost respect for the people behind GitVersionTask who are frankly a lot smarter than I. This post describes a workaround put in place to address the bottleneck in our build process while the performance issues are addressed.
I have been slowly working on rebuilding a web application from ASP.Net MVC into a SPA application over the last six months. The timescale of this work has been a blessing and a curse. It is a blessing because there has been an amazing churn in the client frameworks, build pipelines and current best practices so I get to learn a lot of new things. This is directly linked to the curse however as it makes it very difficult to rewrite an existing system and keep up with that rate of change.
I want to share what I have learnt about module loaders as part of this journey. It is new to me so please shout out any inaccuracies in the comments.
One of the benefits of work items in VSTS/TFS is the ability to put metadata into your project system. Associating work items with automated builds is a good example of this. The XAML build system in VSTS/TFS has a handy feature of linking the build number against associated work items as a part of the build process. Unfortunately, there is no out of the box implementation to achieve this in build vNext.
The XAML build workflow stores build numbers in the
Microsoft.VSTS.Build.IntegrationBuild field to link a work item to the build. The IntegrationBuild field is only visible by default in the Bug work item template however the field still exists for PBI and Task work items. You can modify the PBI and Task work item templates however to make this field visible.
We can add the functionality for linking work items to builds by executing some PowerShell during a build that will populate the IntegrationBuild field. As this will be a custom script we can also add some additional functionality.
I’ve been sitting on this one a while and I think this library is ready for some consumption. I created ModelBuilder earlier this year partly as a fun project, but also so that I could get some better test data to work with when doing test automation in C#.
The library provides an easy way to build model classes with random data where the data is better quality that just Guid values for string properties or Environment.TickCount for integers. It also has a lot of extensibility points so that you can customise the model generation.
You can get ModelBuilder from NuGet by running Install-Package ModelBuilder. The following is the documentation for the first release.
Writing release documentation is one of those tasks that you need to do, but nobody wants to do it. We want the ability to automate the generation of documentation as much as possible to remove both manual labour and human error.
My team uses VSTS to manage the planning and delivery of software and we have defined it as the source of truth about our software from requirements to release. This means that (assuming good process is followed) VSTS contains all the information about the history of the product. This is the perfect source of information to produce release notes.
I’ve been rebuilding my Octopus Deploy infrastructure to make use of the new VM, network and security support in Azure. Having to install an Octopus Tentacle on each target machine is obviously cumbersome and PowerShell is a really good answer.
The Octopus Deploy documentation already contains the bulk of the work for the script. I did find however that the netsh called failed because PowerShell didn’t like it being quoted.
In order to streamline this process as much as possible, I want the script to also download the latest tentacle MSI, install it and then clean up.
A couple of years ago I posted a second version of recommended reading for developers. At the time I was training up my team on some of the newer development features, namely the new async support in .Net. Since then I have come across two pitfalls that can catch developers off guard.
For some background, we need to understand what the compiler does when it processes the async and await keywords. The async keyword only affects the local method, not its callers or callee’s. The compiler adds a state machine into the method so that it can track what happens before and after hitting an awaited task. For example, all variables (and parameters) declared before the awaited task must be stored so that the continuation has access to them. The continuation is the code that executes after the awaited task. The continuation may or may not execute on the thread that originally invoked the method.
One thing to note here is that using the async keyword on a method that doesn’t have a continuation adds a performance hit because the compiler is adding an unnecessary state machine into the method. There would be no continuation either because there is no awaited task or no code blocks after the only awaited task. To avoid the performance hit of the state machine, a simple pass-through style method should not use async.
I’m working through a support issue with Microsoft to do with Azure Service Bus. One potential issue raised was that my application is running as 32bit rather than 64bit. When I checked it out, the Prefer 32 bit setting was enabled on the project. This means that the exe’s will be running as x86 even though it is running on an x64 machine.