DevOps tools for deploying applications typically have a setting which is called something along the lines of 'Remove Additional Files at Destination'. This means that the deployment process will not only copy files onto your server (or wherever you're deploying your software to), but it will also delete any files which are already on the server but are not included in your deployed code.

For example, this is what it looks like in Azure DevOps when deploying a web application to IIS:

I would strongly advise that you should enable this setting unless you have a good reason not to. Your deployment pipeline should remove any files from previous deployments for at least two reasons:

1. If this is unchecked, you can never really delete files. Even once they're gone from your source code, they stay on the server. This has the potential to cause bugs which are specific to that deployment and will be impossible to replicate on a different environment.
2. With this option unchecked, you can never really know if your pipeline is actually deploying everything which is needed for the application to work. It could be that the pipeline is broken and misses the deployment of some key files, but your software is still running because the necessary files are left over from a previous successful deployment. This means a broken pipeline can remain undetected for a long period of time, potentially causing problems in the future when deploying to a new environment (which won't have the legacy files).

I recently came across a situation where this option was left unchecked on a pipeline, and 3 years after some code was deleted it caused a bug which prevented the software from running at all. The bug occurred only on one environment.

The files which had been left on the server from an old deployment were the Views folder of an ASP.NET Core MVC project. One of these files was _ViewImports.cshtml and it referenced a project which no longer existed. The web application had been restructured and became an API project rather than an MVC project, so the Views folder had been deleted from the code. However, it remained on the server, ignored by the application but nonetheless present.

3 years later, the web application was converted to an MVC application again. A new Views folder was created, and it again had a _ViewImports.cshtml file, but this time it was within a subfolder. This meant it didn't overwrite the original one when it was deployed to the server. Upon deployment, suddenly the old _ViewImports.cshtml (with its broken reference) became relevant again, and the application broke.

Once the issue was understood, the problem was easy to fix. Simply deleting the old file instantly fixed the application. The more fundamental problem is the pipeline, but happily that's also easy to fix - just check the checkbox and save it. Now, not only is the bug resolved and the application working again, but the deployment pipeline has become more robust and reliable.