Overview This blog post assumes you’re familiar with the ElasticBeanstalk deployment process, the management UI included in the AWS console, and Azure DevOps build and release pipelines. I’ve documented this here since it was quite time consuming to resolve this issue and neither StackOverflow nor AWS Support had a solution for this issue. While deploying a .NET Core based application from an Azure DevOps pipeline to an ElasticBeanstalk environment, I kept receiving an error during the deployment step in the engine logs indicating that:

In the past, I’ve spoken about using Servicestack with Raven DB for building REST APIs. Inevitably, we get to a point where we need audit trails for the API. Audit trails are different from Request logs in that you want to capture not just the request but the details of the actual changes resulting from the request. Since I’m not a big fan of re-inventing the wheel, I used the Audt.

SR&ED filings are a yearly thing, which leads them to be left to the end of the year. Ideally, documentation should be performed as an ongoing part of R&D and Engineering activities. To this end, I’ve set up a process for my team. A simple process Add an “SR&ED” label to Github to each of the repositories issues are stored. This label is to be applied to all items that meet SR&ED requirements.

Having discovered Hugo while building this blog, I’ve introduced it to engineering at work to build our internal documentation. Due to the need to ensure confidentiality, I run our Hugo blog on a micro instance on AWS with IP restrictions and AD authentication. Currently, this means that I have a little shell script that checks the GitHub repo every so often and then pulls and outputs the latest version. The intent is to move it to Jenkins and build and deploy, but that wasn’t happening on a Saturday at midnight when I was setting it up.

I’ve been using both ServiceStack and RavenDB for building REST APIs for some time and it has been a great development experience. When Ravendb 4 came out, it made a change from the previous iterations of the product where in the id of the document being loaded now needed to be fully qualified, i.e. it had to have the name of the collection present. So an id would now be of the form: users/1-A This was not the case in earlier versions.