複数のgitブランチ用のステージングサーバーを作成する方法

開発とテストのための新しいステージングプロセスを作成する必要があります。

常に、活発に開発およびテストされているgitブランチは約4つだけです。各gitブランチ内には、実行する必要のあるデータベースエボリューションスクリプト（ストレートSQL）と、より重い処理のためのバックエンドからのエボリューションスクリプトがあります（これらは、データベースを実行する管理者資格情報を使用してアプリ内で呼び出す必要があるHTTPルートです）移行や、前述のプレーンなSQL進化スクリプトでスクリプトを作成することが困難または不可能であるその他の変更）。

私たちのライブDBは、適度なサイズの4.2 GBです。セットアップの準備ができて、使い捨ての真新しいDell PowerEdgeサーバーがあります。

次の質問についてのアドバイスと、経験豊富なDevOpsがこれにどのように取り組むかを知りたいです。

1. ステージングサーバーでいくつかの異なるブランチを実行するにはどうすればよいですか？これらのブランチは、QAに合格し、マスターにマージされて解放されると、頻繁にポップアップして消えます。

2. 各ブランチに常に適切なDBがあることを確認するために、DB進化システムをどのようにセットアップしますか？各ブランチは、マージされるまで相互に互換性があるとは限らないさまざまな方法でDBに変更を加える場合があります。

3. これらのブランチを最新の状態に保つにはどうすればよいですか？各ブランチでコミットを自動プルする方法はありますか？

これをすべて設定する方法について少し迷っていますので、これ以上の入力は大好きです。現在のワークフローは関係者全員にとって困難です。開発者は完全に分離されたアプリのローカルコピーをローカルで実行しており、QAは3〜4台のラップトップをローテーションしてステージング「サーバー」として機能させます

1）ステージングサーバーでいくつかの異なるブランチを実行するにはどうすればよいですか？

Docker

2）各ブランチに常に適切なDBがあることを確認するために、DB進化システムをどのようにセットアップしますか？

これは、DBがどれだけの規模になると予想するかによって異なります。データベースデータのクローンを作成する方法にはかなり夢中になりますが、通常は、コードが本番環境にリリースされるまで変更しないマスターコピーが必要です。その際、適切なバックアップを維持してください。もしながら、インフラストラクチャは、不変で、使い捨てすることができ、あなたのデータはありません。データでのみ使い捨てをエミュレートできます。4.2 GBは、コピーするのにそれほど多くはありません。ビルドごとに新しいデータベースインスタンスを生成するスクリプトを作成し、テストが完了したらそれを破棄することができます。

3）これらのブランチを最新の状態に保つにはどうすればよいですか？各ブランチでコミットを自動プルする方法はありますか？

gitフックのようなものを使用してビルドをトリガーしたり、コードのチェックアウトを強制したり、コンテナを生成してデータベースのクローンを作成したりすることを検討できます。Jenkinsなどのビルド自動化システムにAPI呼び出しを行ったり、それを使用して、Puppet、Chef、Salt Stack、Ansibleなどの構成管理システムを開始したりできます。これは、自動プッシュよりも自動プルに似ています。

質問の文言から、変更可能なインフラストラクチャを検討していることは明らかですが、代わりに不変のテストデプロイメントの使用を検討してください。

これは実際にはサーバーのステージングに関するものではないと主張します。ステージングサーバーは、本番環境によく似ており、本番環境に移行する直前にリリースが行われます。マスターにマージされていない機能ブランチは、本番環境に直接リリースされないため、ステージングサーバーには配置しないでください。

共有開発サーバーに関する質問に再構成すると、検索するリソースが増えます。お気づきのように、このような開発リソースを共有すると多くの問題が発生するため、代わりに根本的な問題の解決に焦点を当てた方がよい場合があります。機械？

現在、これらの共有サーバーが本当に必要な場合があります。試してみて、本当にそうであると判断した場合は、プロセスを簡略化するために使用できるテクニックがいくつかあります。

ステージングサーバーでいくつかの異なるブランチを実行するにはどうすればよいですか？これらのブランチは、QAに合格し、マスターにマージされて解放されると、頻繁にポップアップして消えます。

最も簡単な方法の1つは、URLの一部を使用して、実行するコードブランチを切り替えることです（この変更は、これが適切なステージング環境ではない理由の一部です）。これは、ワイルドカードDNS（foo.our-dev-domain.com同じサーバーにリダイレクトされるDNS ）と/our/release/directory/fooインクルードパスに読み込まれたルーティングコードを使用して過去にこれを実行したことがあります。

必要に応じて、ブランチに必要な構成を追加するコマンド（Ansibleなどを使用）を持つこともできます。これはおそらくデプロイプロセスの一部になるでしょう。これについては、後で説明します。

各ブランチに常に適切なDBがあることを確認するために、DB進化システムをどのようにセットアップしますか？各ブランチは、マージされるまで相互に互換性があるとは限らないさまざまな方法でDBに変更を加える場合があります。

一番簡単なことは、それと一緒に暮らして、人々に短命のブランチを持つように勧めることです。

別のアプローチは、動的ルーティングコードを使用して、ブランチの名前に基づいてデータベース（RDBMS用語では「データベース」）の個別のコピーに切り替えることです。

これらのブランチを最新の状態に保つにはどうすればよいですか？各ブランチでコミットを自動プルする方法はありますか？

押したり引いたりできます。例えば：

• プル -んcronジョブの設定git pull（またはおそらく、git fetchとgit reset --hard）数分おき
• プッシュ - プッシュ時にトリガーするWebhookをセットアップし、それをリッスンして必要に応じてリポジトリを更新するマシン上の小さなWebサービス
• push-開発者にサーバー上のブランチを更新するためにデプロイコマンドを明示的に実行させる

最初にユーザーと話し、要件を収集してユーザーが何を望んでいるか（ユーザーが何かをテストしている最中に自動的に更新するのは嫌いかもしれません）を確認します。

しかし、再び：

開発者はローカルで実行されているアプリの完全に分離されたローカルコピーを持ち、QAはステージング「サーバー」として機能する3〜4台のラップトップをローテーションで持っています

問題は、開発者が行うように特定のブランチをチェックアウトするのではなく、QAが共有ラップトップをローテーションすることです。

それがgitlabが最も得意とすることです。gitlabに移動し、kubeクラスタをセットアップして自動デプロイすることを検討してください。これにより、各ブランチがテスト用の一意のURLにデプロイされます。