Debianパッケージを使用して、Debianベースのサーバーにソフトウェア（Webアプリケーション）をデプロイしたいと思います。この質問の範囲外の理由から、Docker（またはHerokuなどのPaaS）を使用すると、この問題を完全に回避することはできません。
設定はとても簡単です。いくつかのソースコードを含むGitリポジトリがあります。私たちはブランチで作業し、コードをローカルで実行します（ここにはDebian関連のエントリはありません。実際には開発はさまざまなオペレーティングシステムで行われます）。ブランチに十分にコミットし、CIテストが実行され、レビューされ、マスターにマージされるまで待ちます。 。
マスターにマージした後、Debian サーバーにデプロイしようとしています。現在、これはファイルを正しい場所に移動し、正しいサービスを再起動するシェルスクリプトを介して「手動で」実行されます。これはいくつかの理由で脆弱であり（スクリプトが途中で失敗し、本番サーバーが一貫していないままになる可能性がある）、より良いことを望んでいます。
Debian パッケージは良い解決策のように聞こえます。これには、ファイルのコピー、systemd サービス（再）の開始など、デプロイメントスクリプトを介して現在手動で実行する多くのタスクの処理機能が組み込まれています。さらに、CI/CD システム (Azure DevOps) には次の概念があります。文化遺物保存され、いつでも手動で再配布できるため、.debアプリケーション全体を含むアイデアに適しています。
私が見た問題：
- Debian はディストリビューションとバージョンの概念に固執します。私たちの場合はバージョンがなく、必要ありません。私たちが興味を持っているのは、
master現在のブランチから何でも配布できることです。.debファイル自体はSSH経由でシェルスクリプトを介してコピーおよび編集されるため、次のdpkg操作に使用されます。 APTリポジトリのバージョン管理を維持することは関係ありません。 - Debian は変更ログを管理します。私たちはこれを手動で維持したくありません。
gbp dch --ignore-branch -S1つは私たちのために作成されますが、すべてのコミットを1つの「変更」に圧縮し、まだバージョンの問題を解決しません。 - ほとんどのツールとドキュメントでは、「Debian」部分が独自のリポジトリであるバージョンのソースタールボールがあると想定しています。バージョンの概念がなかっただけでなく、アプリケーションのソースコードとDebianパッケージングツールの両方が同じリポジトリにありました。
質問：
- 最初はこれはいい考えでしたか？
- バージョンと変更ログの概念をどのように完全に無視/解決できますか？
- パッケージのインストールとアップグレードの違いを維持できますか？私のアプリケーションは、他のインストールをアップグレードするか、最初から新しいインストールを開始するかという論理が異なります（たとえば、新しいインストールでは、アプリケーションは手動で生成する必要がある構成ファイルに依存するため、systemdサービスを自動的に開始することはオプションです。そうではありませんが、アップグレード中に構成ファイルがすでに存在すると想定されるため、サービスがすでに起動している場合は再起動する必要があります。