Question

I'm working with ASP.NET core web API project, where I have 8 controllers, multiple DTOs being used for request and response and mappers to map models(also used in the web app) with DTOs.

Recently, we have started with versioning, for that, we're referring to the best practices: API-Version-Conventions. Here is the project structure we have so far:

MyProject
└ API
  ├─ v1
  │  └ Controllers
  |  L Models
  ├─ v2
  │  └ Controllers
  |  L Models
  └─ v2_5
     └ Controllers     
     L Models

But in this case, we need to copy the same code again and again, even if the release is minor. So is this good practice or is there any other way around?

Was it helpful?

Solution

This is bad practice.

The problem with the structure is that your 'versions' are not release versions anymore.

When you added version 2 to your API you deployed v1 and v2 together. The original deployment for v1 was presumably overwritten.

Best practice is to use your version control for versioning your code, and to deploy a new version completely separately from the old version on new virtual machine.

Then you route the network traffic to the new or old version using your network infrastructure not your websites code.

That way, you don't touch the old version at all when you deploy the new one. there is no possibility of a bug being introduced to the old version, as you haven't changed it at all.

If you need to roll back, its simply a matter of routing the traffic to the old boxes again. They are still there working away as normal.

Licensed under: CC-BY-SA with attribution
scroll top