1

以下のような git ワークフローを使用して、さまざまな開発者のチームで作業しています。

  1. チケットを受け取る
  2. gitプル/チェックアウト
  3. 機能/バグ修正ブランチを作成する
  4. 変更を行う
  5. ブランチにコミットする
  6. テスト ブランチにマージし、テスト環境に git pull します。
  7. ライブと同じ環境でテストする
  8. テストが成功したら、マージして証明し、git pull して証明します
  9. クライアントのサインオフ
  10. マージしてライブ
  11. git pull on live

しかし、開発者が変更をライブサーバーにプルするための最良の方法を決定することはできません.

現在、開発者は (個々のユーザー アカウントを使用して) ライブ サーバーに SSH で接続し、git pull を実行しますが、サーバー上のコードベースへの読み取り/書き込みアクセスが必要です。

1 人 (またはシステム管理者) だけが展開を実行する必要があるため、これは嫌いです。

別の方法は、Web アクセス可能な git pull スクリプトを作成することです。これにより、開発者がプルを実行したい場合、スクリプトは文字通りサーバー上で git pull を実行し、ブラウザーに出力します。

私の意見では、リポジトリがプッシュされたときにフックをトリガーするのが最善の方法です。gitlab を使用しているため、この実装は比較的簡単だと思います。Web サーバー上のスクリプトは、リポジトリに関する情報を含む POST オブジェクトを受け取ります。 、したがって、フックを受け取るブランチが更新された場合にのみプルをトリガーするようにスクリプト化できます (それが理にかなっている場合)。プッシュを実行したユーザーに git pull メッセージの出力を含む電子メールを送信して、すべてが計画どおりに進んでいることを確認することもできます。ただし、開発者が誤って間違ったブランチにプッシュし、コミットが時期尚早にライブになる可能性があることに不快感を覚えます。理想的には、ある種の github スタイルのマージ リクエスト機能が必要です。

他の推奨事項や提案はありますか?

4

3 に答える 3

0

プロセスで特定された問題とは別に、並行した変更が衝突し、「証明」環境で効果のないテストが作成されることについても懸念しています。

Bob が変更 #1 を Proof にプルし、次に Dave が変更 #2 を Proof にプルし、次にクライアント テストが変更 #1 (#1 と #2 のコードベースに対して) をプルするとします。変更 #1 を Live にプルすると、テストされていないコードを効果的に引き出します。

不変のビルドとビルド アーティファクトの観点から考えることをお勧めします。私の同僚は、このトピックに関する優れた記事を書きました。プロセスの主な変更点は次のとおりです。

  • 1-5 : (同上)
  • 6 : テスト ブランチから取得します。ビルド アーティファクトをキャプチャします。ビルド アーティファクトをテストにデプロイする
  • 7 : (同上)
  • 8 : ビルドをプルーフにプロモートします。ビルド アーティファクトをデプロイする
  • 9(同)
  • 10ビルドを Live にプロモートします。ビルド アーティファクトをデプロイする

また、Inedo のBuildMasterなどの展開/配信自動化ツールの使用を検討する必要があります。無料版は、必要以上のものである必要があり、「ログインしてスクリプトを実行する」から「適切な承認後にボタンをクリックする」までの作業を支援します。

免責事項:私はInedoで働いています

于 2013-09-02T15:23:53.450 に答える