Looking for a specific post? Checkout the Blog Index.
Last week I updated all my packages and realised that everything was broken! The reason why was that rxjs decided to move out of extensions on observable in favor of pipable functions in version
6.x. A major breaking change where majority if not all codebase built using rxjs needs to be changed.
Today we will explore the reasoning behind this change.
Last year I talked about Entity Framework Core, an easy and feature rich ORM which makes working with database in a .NET environment typesafe. But even though it makes things easy, there are ambiguous cases which can take us off guard. Today we will see four of this cases and how to deal with them.
In Angular, it is common practice to execute commands prior routing a page using guards and resolvers. Guards prevent the routing from occuring until the condition turns to true and resolvers prevent the routing from occuring until the data is returned. Those actions can take time to complete and during the time being, the component will not load leaving the user with an impression of unresponsiveness. Today we will see how we can implement a navigation loading bar for Angular using PrimeNG progress bar component.
Last week we saw how we could Setup CloudWatch to push logs from our application to CloudWatch. Apart from the application logs, another type of logs that is worth looking into are the access logs from Nginx. Nginx being the entrypoint of the application, every traffic in and out goes through it and today we will see how we can leverage its access logs to monitor the response time of our application from CloudWatch.
Few weeks ago we saw How to configure Serilog to work with different environment. At the end of the post, we saw briefly how to get the structured logs synced to Cloudwatch. Today we will explore the configuration in more details.
Basic authentication provides an easy way to password protect an endpoint on our server. Today we will see how we can create a password file and use it to enable basic authentication on Nginx.
Almost a year ago I wrote about how we could setup CI/CD with gitlab pipeline. I showed a very simple 3 stages pipeline build/test/deploy. Since then Gitlab has improved considerably their CI tool with features simplifying releases management. Today we will revisit pipelines and introduce few concepts which will help in managing releases.
CI/CD pipelines allow us to automatically build, test and deploy code changes. With Jenkins pipeline, the pipeline itself is generated from a file called the Jenkinsfile which, usually, is source controlled together with the source code repository. When we need to push new changes, what we would usually do, is test locally and then commit to the repository. From there, the Jenkins pipeline will trigger and build, test on the integration server and deploy to a testable environment (DEV/QA). But what do we do when the changes that we are making are on the Jenkinsfile itself? How do we test locally the validity of the Jenkinsfile or more simply, how do we try on a sandbox a Jenkins pipeline to learn how to write a Jenkinsfile? Today we will see how we can setup a sandbox with a full CI/CD deployment which can be quickly brought up and teared down for testing.
Last week we saw how we could install and run an ASP NET Core application in a container, we saw how Visual Studio uses
docker-compose to setup our services. Today we will see how we can use
compose to setup a cluster composed by an ASP NET Core application container with a SQL Server container and how we can place in a third party process.
Last week we saw a flow to manage versioning and releases. As a continuation of last week, today I will show how we can setup versioning and releases for open source projects by configuring Appveyor and using FAKE to setup a build script.
Few weeks ago I explained how Gitversion can be used to apply semantic versioning to projects based on commit and tag history. Today I will dive deeper in the purpose of versioning and introduce a flow which can be followed to version open source project libraries by looking into four important parts in the lifecycle of an open source library.
Few weeks ago I explained [how to use the new
HttpClientFactory. This freed ourselves from managing the confusing lifecycle of a HttpClient and at the same time allowed us to setup commmon options like base address for all HttpClient injections in our classes. Today we will see how we can setup timeout and retry policies for the HttpClient in in ASP NET Core using Polly.
Few weeks ago we saw how we could Setup continious integration and deployment to deploy an application using Gitlab Pipeline. We configured a service with
systemd and had an ASP NET Core application automatically deployed when code was pushed to the repository. This automation allows us to reduce interaction with the server and reducing the manual work. The “infrastructure” configurations like
systemd service files and
nginx site files must also be created or edited on the server therefore it makes sense to also have them automatically deployed. On top of that, it makes even more sense to have them save in repository and source controlled. Today we will see how we can leverage Gitlab Pipeline to setup a continuous deployment for our infrastructure files.
In previous blog posts, we saw how to proxy requests to an ASP NET Core application using Nginx. We saw that request headers also can be proxied with
proxy_set_header In order to ease development, we need to be able to debug the values to verify that they are what we expect.
Today we will see two methods to inspect the proxied requests.