4

私は現在、ライブ Web アプリケーションの開発を管理しています。開発者は二人。ビルドとデプロイがどのように行われるかを指定するワークフローを定義しようとしています。

現在、ソース管理に codebaseHQ を使用しています。

これは私が考えていることです:

  1. Dev1 と Dev 2 は、変更を取得して CodeBaseHQ の単一のリポジトリにコミットします。
  2. 最初のテストのために、codebaseHQ から本番データベースから切り離された alpha.domain.com に更新をプッシュします。
  3. テストがうまくいったと仮定して、さらにテストするために、運用データベースに結合されている beta.domain.com に変更をマージします。
  4. これらのテストがうまくいくと仮定して、domain.com (本番) にマージします。

これは大丈夫ですか?開発者にとっては非常に面倒なプロセスのように思えます。変更セットごとに 2 回テスト/プッシュする必要があります。更新頻度が低いため、これは耐えられるように思えますが、毎日変更をプッシュしている場合、何をお勧めしますか?

4

2 に答える 2

1

開発者にとっては非常に面倒なプロセスのように思えます。変更セットごとに 2 回テスト/プッシュする必要があります。

プッシュまたはテストのための自動化があまり行われていないようです。自動化されたテストをいくつか用意したら、Go (完全な開示: 私はそこで働いています) などのツールを使用して、さまざまな環境を定義し、さまざまな環境へのプッシュが自動的に行われるようにワークフローをモデル化できます。日常的に変更をプッシュしていることは素晴らしいことです。継続的デリバリーの本で多くの関連するアドバイスを見つけることができるでしょう。

于 2012-10-23T05:52:38.127 に答える
0

私は、ソース コードをプロモートして機能を製品にプロモートするという考えが本当に嫌いです。私は環境を通じてビルドを促進することの大ファンです (私たちは競合しているので、Bagheera もそうだと思います)。

コンパイルされたものであろうと単なるパッケージであろうと「ビルド」を取得し、スクリプトまたはツールを使用して環境を通じてそのパッケージを昇格させます。

于 2012-10-23T14:10:28.473 に答える