本当にあなたともう 1 人の開発者がそれに取り組んでいるだけの場合、ナイトリー ビルドはおそらくあまり役に立ちません。
ナイトリー ビルドに相当する Web アプリは、ステージング サイト (ナイトリー ビルド可能) であると言えます。
ステージング エリアへのナイトリー ビルドが真の利益をもたらし始めるのは、クライアント、プロジェクト マネージャー、および QA 担当者が、アプリの最新の比較的安定したバージョンを確認できるようにする必要がある場合です。あなたの開発者サンドボックス (少なくとも私のような人なら) は、次の機能を実装しようとして物事を壊しているため、使用できない状態で多くの時間を費やしている可能性があります。したがって、典型的な問題は、QA担当者がバグが修正されたことを確認したい、PMが計画された機能が正しく実装されていることを確認したい、またはクライアントが関心のある問題について進捗状況を確認したいということです。約。開発者のサンドボックスにしかアクセスできない場合は、それを見てみると、サンドボックスのバージョンが実行されていない可能性が高くなります (./manage. py runserver がどこかの端末で起動している)、または何か他の理由で壊れた状態になっている。それは本当にチーム全体を遅くし、多くの時間を無駄にします。
本番バージョンを自動的に更新するだけなので、ステージング設定がないようです。あなたが私 (そしてほとんどの開発者だと思います) よりもはるかに慎重で規律があり、完全に防弾ではないものを決してコミットしないのであれば、それは問題ありません。個人的には、私の作品が本番環境に入る前に、私以外の誰かによる大ざっぱな QA を通過したことを確認したいと思っています。
結論として、私が働いているセットアップは次のとおりです。
- 各開発者は独自のサンドボックスをローカルで実行します (あなたが行うのと同じです)
- cronjob から夜間に更新される開発サーバーには、「共通の」ステージング サンドボックスがあります。PM、クライアント、QA はそこに行きます。開発者サンドボックスに直接アクセスすることは決してありません。
- 本番環境への自動化された (手動で開始された) 展開があります。開発者または PM は、物事が十分に QA され、安定していて安全であると感じたときに、本番環境に「プッシュ」できます。
唯一の欠点は (毎晩のステージング ビルドを設定するための少し余分なオーバーヘッドを除いて)、バグ検証のターンアラウンドに 1 日かかることです。つまり、QA はソフトウェアのバグを報告し (その日のナイトリー ビルドを調べて)、開発者はバグを修正してコミットします。QA は翌日のビルドまで待って、バグが実際に修正されたことを確認する必要があります。誰もがスケジュールに影響を与えないほど十分な作業を行っているため、通常はそれほど問題にはなりません。ただし、マイルストーンが近づいていて、機能が凍結され、バグ修正のみのモードになっている場合は、ステージング サイトをより頻繁に手動で更新します。