我想使用 Debian 软件包将软件（Web 应用程序）部署到基于 Debian 的服务器。由于超出此问题范围的原因，我们无法使用 Docker（或 PaaS，例如 Heroku）来完全避免此问题。
设置非常简单，我们有一个包含一些源代码的 Git 存储库。我们在分支上工作并在本地运行代码（这里没有 Debian 特定的东西，事实上开发是在各种不同的操作系统上完成的）；当我们高兴地提交到一个分支时，等待 CI 测试运行、审查并合并到 master。
合并到 master 后，我们希望将其部署到 Debian 服务器。目前，这是通过 shell 脚本“手动”完成的，该脚本将文件移动到正确的位置并重新启动正确的服务。由于多种原因，这很脆弱（脚本可能会在中间失败并使生产服务器处于不一致的状态），我想要更好的东西。
Debian 软件包听起来是一个很好的解决方案。它们对我们当前通过部署脚本手动执行的许多操作进行内置处理，例如复制文件、（重新）启动 systemd 服务等。此外，我们的 CI/CD 系统 (Azure DevOps) 具有以下概念：文物它们被存储并且可以随时手动重新部署，因此它非常适合.deb包含整个应用程序的想法。
我看到的问题：
- Debian 坚持发行版和版本的概念。在我们的例子中，我们没有版本并且不需要它们；我们关心的是能够部署当前
master分支的任何内容 -.deb文件本身将通过 SSH 上的 shell 脚本进行复制和编辑，dpkg因此用于维护 APT 存储库的版本控制是无关紧要的。 - Debian 坚持更新日志。我们不想手动维护它们；
gbp dch --ignore-branch -S为我们生成一个，但它将所有提交压缩为一个“更改”，而且仍然无法解决版本问题。 - 大多数工具和文档假设我有某种版本化的源 tarball，其中的“Debian”部分是它自己的存储库。我不仅没有版本的概念，而且应用程序的源代码和 Debian 打包工具都在同一个存储库中。
问题：
- 一开始这是个好主意吗？
- 我如何完全忽略/解决版本和变更日志的概念？
- 我仍然可以保留软件包安装与升级的区别吗？我的应用程序对于我们是升级不同的安装还是从头开始进行新安装有不同的逻辑（例如，在新安装上，应用程序将依赖于需要手动创建的配置文件，因此自动启动 systemd 服务是不行的，但是在升级过程中我们假设配置文件已经存在，因此如果服务已经启动，我们确实希望重新启动它）。