みなさんおはようございます！
私の日常業務では、NGINX+uWSGI+MongoDB を Python アプリケーション コンテナーとして使用しています。バージョン管理と共同開発のために、各開発者のコンピューターに GIT をインストールし、配信用に中央の GIT リポジトリを使用しています。
すべてが順調かつスムーズに実行されていますが、小さな問題が 1 つあります。
これまで、社内ソフトウェアの新しいバージョンを配信する場合、すべての開発者が変更をマージし、その後、選ばれた開発者 (通常はプロジェクト マネージャー) が最終製品を中央 GIT サーバー上の「ブランチ マスター」リポジトリにプッシュしていました。
このプッシュが行われると、GIT を継続的に監視しているスクリプトが新しいバージョンを取得し、それを uWSGI サーバーにプッシュします。その後、すべての新しい接続に対して新しいバージョンがロードされます。
ここで、GIT サーバーにプッシュして、uWSGI がこの GIT サーバーから Web アプリケーションを直接ロードして提供する方法を考えています。
同様のソリューションや uWSGI 構成をすでに持っている人はいますか?
答え1
サーバーベースのgitリポジトリは、あなたが作業するものではありません。常に、中央のgitリポジトリから派生したローカルリポジトリのクローンに依存することになります（IMHO）。醜いcronジョブを取り除くためにできること：gitの受信前/受信後フックGitサーバー上で:
クライアント側のフックに加えて、システム管理者はいくつかの重要なサーバー側のフックを使用して、プロジェクトにほぼあらゆる種類のポリシーを適用できます。これらのスクリプトは、サーバーへのプッシュの前後に実行されます。事前フックはいつでもゼロ以外で終了してプッシュを拒否し、クライアントにエラー メッセージを出力できます。必要に応じて複雑なプッシュ ポリシーを設定できます。
有益な情報もありますウェブサイトステージング用の git-post-receive-hook に関する stackoverflow のディスカッション特にトップアンサーの最初のリンクを確認してくださいgit ウェブサイトの使い方
答え2
私の会社の Web サイト (github リポジトリから生成) で使用するトリックは、uWSGI にこれらのオプションを追加することです。
; reload the server everytime the repository is updated
touch-reload = .git/index
; every minute pull from the repository
cron = -1 -1 -1 -1 -1 git pull