4

完成した製品を設置チームに引き渡した経験のある人はいますか?

当社の製品は RPM を介してインストールできますが、一部の MySQL データのコピー、一部の構成ファイルの変更、いくつかの開発スクリプトの実行も必要です。インストール チームを持つことは素晴らしいことですが、それはオンコールの開発であり、各インストールの後、サポートしなければならない時間外に顧客から電話を受けます。

私たちはそれぞれの事件から学びますが、顧客、私たちの評判、そして私の睡眠のために、もう少し積極的になることは良いことです.

具体的には：

  • チーム間のコミュニケーション/コラボレーションを改善するためにどのツールを使用しましたか?
  • どの技術ソリューションを使用しましたか?
  • どのようなポリシーを使用しましたか?
  • インストール後の検証ツールの作成に成功した人はいますか?

編集: 開発や QA が把握すべきソフトウェアの障害について話しているのではないことを明確にする必要があります。問題は、お客様から「オプションAが設定されていないために突然利用できなくなった」、「認証サーバーが正しく設定されていないためにログオンできない」という電話です。

4

5 に答える 5

3

これは基本的に、異なる強調を加えたAssafの答えです。展開の両側に行ってきたので、適切な展開を保証するための2つの主要な項目があります。

  1. 可動部品が少ない

つまり、いくつかのファイルを提供してデプロイヤーにそれらを実稼働環境の特定のフォルダーに配置させるオプションがある場合、またはファイルをフォルダー構造に事前配置して、デプロイヤーにルートにコピーさせることができる場合。またはさらに簡単に、バッチファイル。またはMSI。SQLスクリプトを実行する必要がある場合は、それらがどこにあるかを明確に示します。

基本的に、この手順は、開発者がスクリプトとバッチファイルを作成し、可能な限り人間的に（ええ​​と）自動化できるようにすることです。そうすれば、デプロイヤー（あなたと同じようにアプリを知らない）は、残っている3つのファイルで何をすべきかを気にする必要はありません。（ええと、あなたはそれらをフォルダA、B、D、ZZに置くことになっています）

  1. 導入ガイド

それはステップ1に勝るので、それはすべてキャップスです。私は非常に徹底的なガイドについて話している。

言うべきではない

「マップ関連のファイルをMap-App-Dataフォルダーに移動します。」

それは言うべきです

"*ファイルx、y、z（展開パッケージのフォルダーXにあります）をMap-App-Dataフォルダー（ D：\ AppName \ Map-App-Dataにあります）*に移動します。

デプロイヤーがどのサーバー上にあるべきかは明らかだと思うかもしれないので、「Xサーバーにリモートインしてからyを実行する」とさえ言う動きを通り抜けますが、マルチサーバーセットアップの場合、何をすべきかについてかなり厄介になる可能性がありますどこ。ドキュメントがあれば、これは、何が起こっているかについてトレーニングする機会がなかった人でも、誰でも展開できることを意味します。

2.1ロールバック計画

ロールバック計画を展開ガイドに正しく配置します。展開がうまくいかない場合、そして時々そうなる場合は、展開者が何が起こっているのかを知っている誰かを起こすことができるまで、サーバーをオフラインのままにしたくないでしょう。それは彼らの目の前にあるはずです。当たり前のように思えても、このプロジェクトに夢中になっているのは過去4週間で、この人は過去20分間を過ごしたことを忘れないでください。彼らはあなたが彼らに何を言わないかを知ることを単に期待することはできません。

2.2導入ガイドをテストする

自分で手順を実行します。または、さらに良いことに、プロジェクトに参加していない同僚に、ガイドと一緒にUATに展開してみてもらい、あなたは彼らの隣に座ってください。彼らがそれを間違えたところはどこでも、ガイドを変えてください。展開がうまくいかない場合（以前に見た状況）、この状況が発生する理由と、可能であれば修正する方法を説明する脚注をガイドに追加します。展開ガイドにエラーがないことが非常に重要です。展開ガイドを作成するときは、基本的に展開を実行しているため（方法を知っているため）、それを介してスリープするというボーナスが得られます。しかし、それはまた、あなたに間違いがあることを意味します。

私が見逃したものについてコメントを追加してください、そして私はそれを投げます。

于 2009-05-27T19:57:36.907 に答える
1

  • 「インストールチーム」はありません。開発者は、機能するシステムを開発する責任を負うべきであり、他の貧弱な樹液が機能するために壁を越えて投げる部品の山ではありません。

  • 完全に自動化された展開/アップグレード プロセスを使用します。ある日、誰かが誤って間違った決定を下す可能性があるため、展開には手動での決定は必要ありません。

  • デプロイが失敗した場合は、自動化を修正して再リリースします。ある日、人々は修正をソース コード リポジトリにチェックインするのを忘れるからです。

  • 開発中に展開/アップグレード プロセスを定期的にテストします。できれば、継続的インテグレーション プロセスの一環として、すべてのコミットで。

  • テスト環境が可能な限り本番環境に近いことを確認してください。理想的には、唯一の違いはパスワードであるべきです。

  • 展開の一部として環境テストを実行します。私は通常、これらをシステム自体に実装して、ランタイム環境の何が問題なのかを自己テストして報告できるようにします。

  • 失敗した展開を簡単にロールバックできるようにします。

于 2009-05-27T20:34:56.423 に答える
1

特定の質問を対象としているわけではありませんが、むかしむかし、テストと検証のために一連のサーバーに Web アプリケーションをデプロイする開発者とテスターのチームがありました。

リリースの時期になると、顧客はデプロイ可能なファイルを取得し、仕様に従ってデプロイしました...サーバーのセットに対して、開発サーバーとはまったく異なります。

大量のバグが流入し、混乱が続き、顧客は激怒し、貧しい開発者は眠れなくなりました。

私のヒントは、最も明白なものの 1 つです。環境固有のバグを回避するために、開発環境が本番環境と一致していることを確認してください。

于 2009-05-27T19:36:12.533 に答える
1

はい。いくつかの基本ルール:

  1. 必ず署名と捺印のある製品をお届けください。zip (またはチェックサムのあるもの) を使用し、個々のファイルやディレクトリを配信しないでください。
  2. CDに焼いて、物理的に手渡す。そうすれば、機能するハード コピー (およびバックアップ) があることがわかります。ファイルを静かに破壊する CD バーナーのせいで、インストールを簡単に台無しにしてしまうことに驚かれることでしょう。
  3. インストール チーム (または QA) は、顧客が受け取るものとまったく同じものを受け取る必要があります。彼らはあなたの製品について最も愚かな顧客よりも知識が少ないと仮定してください。
  4. 当然のことながら、バージョンごとにカタログ化されたすべての配信のリポジトリを常に保持する必要があります。
  5. バージョンに付属するインストール/展開/ユーザー ガイドを印刷して、物理的に手渡します。紙として。ドキュメントが最後のバージョンから変更されていない場合でも。QA がインストールをデバッグするのを手伝うのに多くの時間を無駄にしましたが、後で間違ったインストール ガイドを使用していることに気付きました。
于 2009-05-27T19:40:39.793 に答える
0

いくつかの議論の後、ジャンプスタートと呼ばれるものを使用するというアイデアを思いついたのは私たちのビルドチームでした. RPM と必要な構成 (MySQL コマンド、httpd.conf への変更など) をパッケージ化できます。インストールで問題が発生したら、スクリプトを変更できます。これにより、同じ間違いが 2 回行われないことがほぼ保証されます。

実際にライブで使い始めたら更新します。

于 2009-06-02T13:59:00.580 に答える