How did that even come up?

I originally started writing another post last week but in the meantime I did a domain name migration. What is a domain name migration you will ask? It is the act of migrating content from a domain to another domain. Not host, domain. If this was about host migration there would be no need for a post as the changes would be straightforward. People may give you a different or more precise description but it is basically what I did. And also what it sounds like. I like to name things so that when they are described or revealed they turn out to be pretty much what you expect. It’s like coding. If I have a piece of code with a method boolean validatePassword(string username, string password) when looking at the code you pretty much expect to see some user retrieval and maybe encoded password validation. You definitely do not expect a session to be started or anything funny like that. Enough with this, let’s get back onto today’s topic. Domain name migration.

Continuous what?

Continuous delivery. You may recall that in my previous post I announced that today’s entry would be revolving around continuous integration. And technically it can count as such since we will cover continuous integration along the next step. That next step is continuous delivery. If you are not familiar with these terms and the concepts behind them I will sum them up briefly.

Basically, continuous integration allows verifying that your codebase still builds and passes tests passing whenever you push changes. Add a trigger to deploy your code to production upon success and you pretty much have the idea around continuous delivery.

This tutorial is an introduction to .NET Core CLI tools. More precisely it is about creating a web API using the CLI tools provided for .NET Core. Whether you are a beginner in development or just new to .NET Core this tutorial is for you. However, you need to be familiar with what an API is and unit tests to fully enjoy this tutorial. Today, we will set up a solution grouping an API project and a test project.

Last month, I posted about Postman enabling you to test your APIs with little effort so that you can build future-proof software. Here we are going to cover setting up continuous integration for a simple project by using Newman to run your Postman collections. You may have heard about continuous integration in the past. Most commonly, continuous integration will build software from one’s changes before or after merging them into the main codebase. Even though there is an infinity of tools that allow implementing continuous integration, I will focus on Appveyor CI. In order to make things simple, I will create a very basic web API project and will host it on GitHub.

Turning shaky code into future-proof software

Over the past years, we moved more and more towards web-oriented architectures, connecting to services in order to provide information. Along with the evolution of testing tools and development methodologies we can build crazily robust software. However, it happens that sometimes we will not build unit tests because of project constraints. Those reasons often go from time pressure on a project to laziness but I am not here to judge.