Using the same concept of putting Octopus Deploy behind a reverse proxy, I want to wrap SonarQube behind an IIS reverse proxy so I can use Let’s Encrypt certificates to host it.
I posted a couple of months ago about some ideas I had for integrating Let’s Encrypt certificates with the hosting of Octopus Deploy. The idea was to use many PowerShell scripts with a scheduled release to request a new certificate and install it against the Octopus Server.
I never got to complete this and have since come up with a much easier solution, the reverse proxy. The way a reverse proxy works is by exposing one website as a wrapper around another (internal) website. This is a feature that IIS supports and works well with Octopus Deploy.
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.