svn - SVN を使用したお気に入りの Web アプリ展開ワークフローは何ですか?

Question

現在、リモート SVN サーバー、DEV、STAGE、PROD 用の 3 つの SVN ブランチ、パッチによるコードの昇格などを含むやや複雑な展開セットアップを使用しています。小規模な開発チームの状況での展開には何を使用しているのだろうか?

score 15 · Accepted Answer

開発用のトランク、および本番用のブランチ（本番）。

ローカルマシンには、変更をテストするためにトランクブランチを指すVirtualHostがあります。

トランクへのコミットは、svnエクスポートを実行してオンラインサーバーの開発URLに同期するコミットフックをトリガーします-したがって、サイトがstackoverflow.comの場合、このフックはdev.stackoverflow.comを自動的に更新します

次に、svnmergeを使用して、ローカルチェックアウトでトランクから本番環境に選択したパッチをマージします。ローカルマシンに、本番ブランチを指すVirtualHostが再びあります。

マージされた変更を本番ブランチにコミットすると、SVNエクスポートフックが本番（ライブ）エクスポートを更新し、サイトがライブになります！

score 3 · Accepted Answer

3つのブランチは余分な作業のように聞こえます。

環境の違いは、トランク内に関連するファイルのバージョンを変えることで処理できます。つまり、database.ymlとdatabase.yml.prodです。展開プロセスは環境に配慮し、環境ごとのファイルをデフォルトのファイルにコピーするだけです。

score 3 · Accepted Answer

私が小さな開発チーム (私、別のプログラマー、および上司) で働いていたとき、それは非常に混沌とした混乱でした。ただし、「ゲートキーパー」タイプのプロセスを割り当てるとうまくいくことがわかりました。

ゲートキーパーは、アプリで最も多くの作業を行った人物でした (この場合、私はゼロから開発した 2 つのプロジェクトを持っていましたが、彼は 4 つほど持っていました)。

基本的に、彼が私のプロジェクトに取り組む必要があるときはいつでも、彼は仕事をしていることを私に通知し、リポジトリが最新でビルド可能であることを確認してから、プルダウンして変更を加え、コミットしました。 . 彼はそれが完了したことを私に知らせ、私はプルダウン、ビルド、デプロイしました。DB の変更があった場合は、DB を修正するすべてのスクリプトを含む DB Change フォルダーが作成されました。

明らかに多くの穴が開いていましたが、プロセスはうまく機能し、お互いを重ね合わせることができませんでした。

score 2 · Accepted Answer

単純なトランクブランチには最新のコードが含まれており、ライブになるたびにブランチをカットします。これはかなり有効に機能しているようです。ライブシステム用に切り取った現在のブランチに障害が発生した場合は、いつでも前のブランチに簡単に移動できます。また、現在稼働中のブランチのバグを修正するのは簡単です。また、新しいブランチをカットするとブランチは効果的に消滅するため、作業する必要がある実際のブランチは 1 つだけです (そしてそこから修正をマージします)。ライブブランチ)。

score 1 · Accepted Answer

継続的インテグレーションの原則（とりわけ）に基づいてソフトウェア配信を管理するための完全なプロセスを説明している本（現在ラフカット）を強くお勧めします。

ブランチとマージのアプローチは非常に厄介になる可能性があり、実際には新しい価値をもたらさないアクティビティに時間を費やすことになるため、かなり無駄になるため、私はブランチとマージのアプローチを強く嫌います。すでにコードを開発、テスト、修正したことがありますが、なぜこの作業をやり直す必要がある状況を作成する（コードを別のブランチにコピーする）のですか？

とにかく、分岐とマージを回避する方法は、トランクからデプロイ可能なアーティファクトを構築し、テストやステージングなどに合格するときに、構築されたアーティファクトを（ソースではなく）プロモートすることです。これにより、自分が正しいことを100％確信できます。本番環境に移行することは、テストしたことと同じです。

さまざまなスケジュールでリリースする必要のあるさまざまな機能がある場合は、実装方法のアプローチを変更する（機能を構成可能にする、またはより適切にモジュール化する）と、単一の開発トランクを維持するのに役立ちます。

score 1 · Accepted Answer

トランクには、現在の「プライマリ」開発コードベースが含まれています。

開発者は、トランクコードベースをホースでつなぎ、他の開発者の邪魔になる可能性のある中長期プロジェクト用に個別のブランチを作成することがよくあります。彼が完了すると、彼はトランクに再びマージします。

コードを本番環境にプッシュするたびに、タグ付きリリースを作成します。/ tags内のフォルダーは、単にバージョン番号です。

本番環境にデプロイするために、ステージングへのSVNエクスポートを実行しています。それで十分な場合は、単純なrsyncを使用して本番クラスターにロールアウトします。

score 1 · Accepted Answer

Web 関連のものをステージングするためにブランチを使用しません。トランクにマージするのに長い時間がかかる (読む: 1 日以上) 実験的なものをテストするためだけに。「継続的インテグレーション」スタイルのトランクは、(できれば) 動作中の現在の状態を表します。

したがって、ほとんどの変更はトランクに直接コミットされます。CruiseControl.NET サーバーは、IIS も実行し、追加サイトのすべてのリソースの最新コピーが利用可能なマシン上で自動的に更新されるため、サイトを社内で完全かつクリーンにテストできます。テスト後、ファイルは公開サーバーにアップロードされます。

これが完璧なアプローチとは言えませんが、シンプルで (したがって、比較的少人数のスタッフに適しています)、比較的安全で、問題なく機能します。

score 0 · Accepted Answer

私たちはリリースブランチを使用しています-これは私たちが行っていた機能ブランチよりも効率的であるようです。

環境ごとに異なるブランチを作成しないでください。

score 0 · Accepted Answer

私は個人的にローカルで作業し (開発)、機能の追加/修正を行い、準備が整ったらトランク (本番) にコミットします。本番サーバーでは、svn update を実行するだけです。

score 0 · Accepted Answer

私はあなたが現在抱えている状況と同様の状況で働いています。私は「より良い」解決策を見つけることを任され、それは次の行に沿って何かを実行しました.

ライブブランチは、現在の状態のサーバーを表します。

開発作業はすべて、ライブから取得したブランチで行う必要があります。これは、1 人の 30 分の仕事、または 1 年間にわたる複数チームのプロジェクトである可能性があります。必要に応じて、ライブへの変更をこれらの開発ブランチにマージできます。

作品がライブになる前に、ライブからの変更が再びマージされ、潜在的なリリースとしてタグ付けされます。このリリースはステージング環境でテストされ、テストに合格すると、新しいライブがタグから取得されます。

うまくいくのであれば、複数の作業を 1 つのリリースにマージすることも可能です。

これは、開発ブランチをライブで最新の状態に保つのが非常に簡単であり、開発中の作業が中断された場合に行うべき片付けは最小限で済むことを意味します。

あるプロジェクトの作業から別のプロジェクトに変更するには、開発者はローカルの作業環境を別のブランチに svn 切り替えるだけです。

あなたが説明したように、システムで私たちが抱えていた問題の 1 つは、DEV が PROD とかなり早く時代遅れになる可能性があるため、ライブに対して開発していないことであり、ステージまで相互依存関係を見つけるのは簡単ではありません。上記のソリューションは、これらの問題を解決しながら、かなり軽量なままです。

svn - SVN を使用したお気に入りの Web アプリ展開ワークフローは何ですか?

11 に答える 11

Related

Reference