5

VC、バグトラッキング、QA、単体テスト、展開、およびその他の類似したもの（計画/クライアント通信の側面を除く）に焦点を当てて、それほど高くないレベルでWebアプリケーションを開発するために使用するプロセスを説明してください。

私はこの分野で新しいので、私の大まかな例（読んでください：このプロセスを使用していません）は、いわば、間違いなく少し離れています-私が学ぶことができるように、それは欠陥であることを指摘してください。

例えば。

  1. ローカルSVNサーバーにプロジェクトリポジトリを作成します。
  2. DNSマッピング用のバッチ/シェルスクリプトを作成します。
  3. プロジェクトをチェックアウトし、ローカル作業コピーの作業を開始します。
  4. 機能をブランチとして開発します。
  5. Mantisでバグを追跡します（リンクはSVN統合を通じてバグにコミットします（それが存在するかどうかはわかりません））。
  6. あなたが行くように文書化します。
  7. ブランチでQAを行います。
  8. 安定したらトランクにマージします。
  9. ユニットテスト？
  10. 機能が実装されて安定したら、リポジトリにコミットします。
  11. リリースをリポジトリ内のタグにコピーします。例えば。/ project / tags / rel-123 /
  12. Phingを使用してステージングサーバーにアップロードします。（誰かが「テスト」以外にステージングサーバーが何に使用されているかを正確に明確にしていただけませんか？）
  13. Phingを使用して、ライブサイトを更新する準備をしたり、DB/デプロイを設定したりします。
4

3 に答える 3

2
  1. HEADバージョンの作成/チェックアウト（「メインブランチ」）
  2. コードを開発し、メインブランチと同期します-少なくとも毎日-
  3. 開発が完了したら、単体テストを作成して実行します
  4. コードレビューを通過し、コード/変更をメインブランチに送信します
  5. 継続的なビルダーに、メインブランチですべての単体テストとシステム/統合テストを実行させます
  6. 準備ができたら、リビジョンを選択してQAブランチに統合します
  7. システムと統合テストを実行し、報告されたバグを修正するか、必要に応じてロールバックします。これはステップ4〜7を繰り返します
  8. QAサインオフ後、QA変更をリリースブランチに統合します
  9. リリースブランチで単体テスト、システム/統合テストを実行します
  10. 本番環境にデプロイし、健全性テストを実行します。

ステージングサーバーは、可能な限り最新の本番環境のコピーです。私の現在のプロジェクトでは、各リリースを互いに独立させておくことができるので、「ステージングサーバー」は本番サーバーであり、異なるURLからアクセスするだけです。

メモと不一致：

すべてのステップには、プロジェクトのサイズに応じていくつかのバリエーションがあります。プロジェクトが大きいほど、チェリーピッキングと環境分離のメリットが大きくなります。小規模なプロジェクトでは、これらは単なる時間のシンクであり、無視されたりバイパスされたりすることがよくあります。

明確にするために、開発スタック、QAスタック、およびステージングスタックがあります。プロジェクトのサイズに応じて、QAはステージング、プロダクションはステージング、またはそれらの組み合わせの場合があります。DevスタックとQAスタックの分離が最も重要です。

上記の手順では、コードと関連データの両方がバージョン管理または追跡されていると想定しています。制御データを考慮に入れたリリースおよびビルドプロセスがあると、リリースが非常に簡単になります。

中小規模のプロジェクトでは、リリースブランチがある場合とない場合があります。コード変更の頻度によって異なります。また、コード変更の頻度とプロジェクトのサイズに応じて、完全なQAブランチをリリースブランチに統合するか、特定のリビジョンを選択してリリースブランチに統合することができます。

FWIW、「移行スクリプト」はほとんど価値がないことがわかりました。それらは常に再利用がほとんどない1回限りのスクリプトであり、ロールバックがお尻の痛みになります。アプリケーションに下位互換性を持たせる方がはるかに簡単です。数回のリリース後（ロールバックが笑える場合）、必要に応じてデータのクリーンアップを実行する必要があります。

于 2009-03-20T04:32:03.227 に答える
1

非常に大まかに：

  1. SVNでリポジトリを作成する
  2. 開発者環境へのローカル作業コピーの確認
  3. 変更を頻繁に更新/コミットする
  4. カスタムデプロイスクリプトを使用してSVNトランクからステージにデプロイする
  5. ステージでのQAテスト、Mantisのバグの報告
  6. 開発者はバグを修正し、解決済みとしてマークします
  7. ステージに再デプロイする
  8. QAはバグをテストし、修正された場合は閉じます
  9. QAが終了し、回帰テストを実行します
  10. カスタムデプロイスクリプトを使用して本番環境にデプロイする
  11. 少し踊る

また、将来のバージョンまたは機能のためにブランチを作成します。これらは最終的にトランクにマージされます。

db構造は、デプロイ中に実行されるカスタムdb比較ツールと同期されます。

于 2009-03-19T11:12:57.630 に答える
1

古い投稿ですが、興味深い質問です!

現在、私の会社では：

  1. 新しい Github リポジトリを作成する
  2. ジェンキンスの構成
  3. ローカルで複製
  4. ブランチを開始する
  5. テストの開発と追加 (サーバー、クライアント、e2e)
  6. ステップごとにコミットし、フェッチとリベースを行ってブランチの同期を維持する
  7. 準備ができたら、ブランチをサーバーにプッシュします。プリコミット チェック lint とテストを行い、問題がなければブロックします。
  8. ブランチのプル リクエストを作成する
  9. ここで、jenkins は自動的にブランチでテストを実行し、プル リクエストで直接「グリーン」または「壊れたテスト」としてフラグを立てます。
  10. 最後に 2 人の同僚にプル リクエストをレビューしてもらい、発見事項を修正してもらいます (ステップ 5 に戻ります)。
  11. すべての緑と 2 人の同僚が同意すると、最後の 1 人がプル リクエストをマージします
  12. サーバー上のブランチを削除します
  13. 準備ができたら、新しいバージョンをプッシュします
  14. 最新バージョンは、テスト プラットフォームにすぐに展開されます
  15. 導入された修正と機能を QA で検証します (問題がある場合は 5 に戻ります)。
  16. (TODO) 本番環境と同じパラメータで本番環境にデプロイする
  17. 本番環境へのデプロイ
  18. 導入されたバグについてユーザーに謝罪し、Issue Manager で報告してください。
  19. 機能リクエストを取得し、Issue Manager で報告する
  20. ステップ 2 でサイクルを再開する
于 2014-02-28T15:34:29.703 に答える