多くの人々が「ステージングの闘争」の概念に精通していると思います。
リリース前日のすべての開発者がベストプラクティスを共有したいので、テスターはできるだけ早くチェックし、
一晩中
バグを修正する必要はありませんか？ Capistranoを使用してRoRプロジェクトのこの問題をどのように解決するかを誰が見たいですか？猫をお願いします。
ツールについて少し
git-flowがアドバイスしているように、それぞれの新しいチケットを別々のブランチで作成します。 タスクマネージャー/バグトラッカーとしてJIRAを使用しているため、JIRAのチケット番号はブランチの名前です。 Jenkins CIを最大限に活用しているわけではありません。これまでのところ、統合テストのためにコードをマージした後、ステージング開発バージョンにコードをデプロイするためにのみ使用しています。
問題の本質
各チケットを単独でチェックできるようにしたかったので、チェックしたチケットのみをリリースに取り込み、バグを含むチケットは次のリリースに残します。
カピストラーノ以外は？
私たちは、
ngrokで作業マシンを共有することから、
teatroのようなSaaSまで、さまざまなオプションを見ました。 最初のオプションは不便であることが判明し、2番目のオプションはすべてのプロジェクトがサードパーティに送信する機会を持っているわけではないため、失敗しました。 したがって、すべてのRoRプロジェクトはcapistranoを使用してデプロイされるという事実により、プロジェクトを特定のブランチからそのホスト（
jira-123.example.comなど ）にデプロイする小さな拡張機能を作成することが決定されました。
プロセス
要するに、開発プロセスは次のようになります：チケットが完了すると、開発者はそれをデモホストに注ぎ、テスターがチェックした後、マージリクエストが作成されます。その後、ジェンキンスはステージングに将来のリリースを注ぎます。
capistrano-demoは何をしますか
開発者が開発中に行うことは、コードの注入、移行のローリング、サードパーティサービス（sidekiq、resqueなど）の起動のみです。
このプラグインにはいくつかの制限がありますが、ほとんどの場合、RoRプロジェクトでのみ動作し、gitでのみ動作します。
構成
使い方
このプラグインには3つのコマンドしかありません。
- demo：create-デモホストを作成/更新します
- デモ：再起動-再起動
- demo：destroy-プロセスを停止し（before / afterを使用して構成）、ディレクトリを削除します。
デモホストを作成するには、
capステージングデモを入力するだけです。作業ディレクトリから
createコマンドを実行するだけです。 デフォルトでは、現在のブランチを注ぎ出すように提供されます。
おわりに
現時点での最大の問題は、アセットの長いアセンブリです。すべてを再構築するのではなく、差分のみを再構築する必要があります。 また、誰かの移行は他の人のホストを破壊する可能性があるため、この場合、ステージングに基づいてクリーンな基盤を維持します。 ブランチごとに個別のデータベースを作成しようとしましたが、空のデータベースまたはコピーを作成する必要がありました。 最初のオプションはテストのためにコンテンツをハンマーで打つ必要があるという点で悪く、2番目のオプションはいくつかのDBMSのデータをコピーするための普遍的なツールはありませんが、将来的にはSqlLite、MySqlおよびPostgresのアダプターを作成する予定です。
成果を
パブリックドメインに配置したので、誰もがそれを読んで使用できるようになりました。プルリクエストは大歓迎です。
PS：コメントでは、あなたの質問に答え、代替ソリューションと建設的な批判に耳を傾ける準備ができています。