問題タブ [maintenance]

コードベースで古いコードをコメントアウトした期間はどれくらいですか? 請負業者は、古いコードをコメントに変換することにより、コード ベースに保持し続けます。これは本当にイライラするので、古いコードをコメントアウトするのではなく、単に削除してほしいと思っています。

コードベースに古いコードをコメントとして残す正当な理由はありますか? Visual Sourcesafe によるバージョン管理を使用しています

アプリケーションが何をしているのかをもっとよく理解したいと思います。ASP.NETおよび.NETカウンターを監視していますが、何が起こっているのか、どのくらいの速さで起こっているのかをより深く把握する必要があります。これに関するベストプラクティスは何ですか？また、Microsoft.NET環境で利用できる特定のガイダンスまたはドキュメントはありますか？これにエンタープライズライブラリを使用しますか？アプリケーションにデータを取り込むために、ライブラリの一部をすでに使用しています。

この時点での最大の苦痛：

• アプリケーションのトラブルシューティングの方法はほとんどありません

  _{（ログはありますが、ログが多すぎるため、サイズが原因でログが実質的に役に立たなくなりました）}

• 既存のパフォーマンスへの影響を最小限に抑える
• ヒットミスなどの観点から、Enjimクライアントが何をしているのかがわかりません。
• 非常にユニークなパフォーマンスを監視する（mem cache server deadなど）

ボーナス

• MOM内で収集されたデータを使用する
• このデータを使用して、最も効果的な場所でアプリケーションを最適化します
• システムの保守性を高めて、私たちの業務担当者がこのシステムの世話をしやすくします。

組織のMaven 2 リポジトリを維持することに関心があります。役立つポインタと落とし穴のいくつかは何ですか。

コードをリリースするときに、リポジトリからダウンロードしたり、リポジトリに独自のアーティファクトを公開するための標準を設定するときに、ユーザーが従うべきガイドラインは何ですか? この種のことに対して、どのような種類のガバナンス/ルールを設けていますか? 開発者向けガイド/ドキュメントには、それについて何を含めていますか?

更新: 私たちは Nexus を立ち上げ、非常に満足しています。Sal のガイドラインのほとんどに従い、問題はありませんでした。さらに、デプロイ アクセスを制限し、Hudson CI サーバーを介したスナップショット アーティファクトの自動ビルド/デプロイを行いました。Hudson は上流/下流のプロジェクトの依存関係をすべて分析できるため、コンパイルの問題、テストの失敗、またはその他の違反によってビルドが中断された場合、デプロイは行われません。2 つのバージョン間でメタデータが変更されているため、Maven2/Maven3 でスナップショットのデプロイを行うことにうんざりしてください。「Hudson のみ」のスナップショット展開戦略は、これを軽減します。Release プラグインは使用しませんが、Versions プラグインに関するいくつかの配管を作成しました。スナップショットをリリースに移動するとき。また、m2eclipse も使用していますが、設定ファイルから Nexus を確認でき、そこから検索するためにアーティファクト情報をインデックス化することを知っているため、Nexus と非常にうまく連携しているようです。(ただし、内部スナップショットを完全にインデックス化するために、これらの設定の一部を調整する必要がありました。) また、これを行うことに興味がある場合は、標準的な方法として、アーティファクトを含むソース jar をデプロイすることをお勧めします。これをスーパー POM で構成します。

UPDATE2 : このSonatypeホワイトペーパーに出くわしました。これには、Maven リポジトリ マネージャーの使用目標がそれぞれ異なる、採用/成熟度のさまざまな段階が詳述されています。

SQL Server 2008 でデータベースの可用性とパフォーマンスを向上させるジョブを提案できる人はいますか?

すべてのストアド プロシージャが依然として構文的に有効であることを確認したいと考えています。(これは、誰かがテーブル/列の名前を変更/削除した場合に発生する可能性があります)。

現在、すべてのストアド プロシージャの構文をチェックする私の解決策は、Enterprise Manager に移動し、リストの最初のストアド プロシージャを選択して、次の手順を使用することです。

1. 入る
2. Alt+C
3. エスケープ
4. エスケープ
5. 下矢印
6. 後藤1

動作しますが、かなり面倒です。というストアド プロシージャが欲しい

SyntaxCheckAllStoredProcedures

ビューに対して同じことを行う、私が書いた他のストアドプロシージャのように：

RefreshAllViews

みんなの利益のために、RefreshAllViews:

RefreshAllViews.prc

すべての人の利益のために、すべてのストアド プロシージャを再コンパイルが必要であるとマークするストアド プロシージャ (ストアド プロシージャを再コンパイルするようにマークしても、構文的に有効かどうかはわかりません):

RecompileAllStoredProcedures.prc

完全を期すために、UpdateAllStatisticsプロシージャを使用します。これにより、完全なデータ スキャンを実行して、データベース内のすべての統計が更新されます。

RefreshAllStatistics.prc

いくつかのパッチを適用した外部svnリポジトリをチェックアウトしました。
（パッチの適用は、競合のために手動でのみ実行できます。）

ここで、リモートリポジトリのこのローカルコピーを適切な方法で維持できるようにしたいと思います。
（リモートリポジトリで読み取る以外のアクセス権はありません。）

まず、パッチの適用には手動の手順が含まれていたため、ある種のソース管理システムでローカルの変更をチェックインできるようにする必要があります。

そして第二に、私はまだリモートリポジトリから更新を受信できるようにしたいです。

これを達成するための最良の方法は何ですか？

私は最近、私が取り組んでいたサイトでバグを見つけて修正しました。これにより、テーブル内に何百万ものデータの重複行が発生し、それらがなくても非常に大きくなります (まだ数百万)。これらの重複行を簡単に見つけることができ、単一の削除クエリを実行してそれらをすべて削除できます。問題は、一度にこれほど多くの行を削除しようとすると、テーブルが長時間ロックされることです。これは、可能であれば回避したいと考えています。(テーブルをロックすることによって) サイトをダウンさせずに、これらの行を取り除くことができる唯一の方法は次のとおりです。

1. 数千の小さな削除クエリをループで実行するスクリプトを作成します。これにより、理論的にはロックされたテーブルの問題を回避できます。これは、他のクエリがキューに入って削除の間に実行できるためです。ただし、それでもデータベースの負荷がかなり高くなり、実行に時間がかかります。
2. テーブルの名前を変更し、既存のテーブルを再作成します (現在は空になります)。次に、名前が変更されたテーブルでクリーンアップを行います。新しいテーブルの名前を変更し、古いテーブルの名前を元に戻して、新しい行を名前を変更したテーブルにマージします。これにはかなり多くの手順が必要ですが、中断を最小限に抑えて作業を完了する必要があります。ここで唯一難しいのは、問題のテーブルがレポート テーブルであることです。名前を変更して空のテーブルを元の場所に配置すると、元の場所に戻すまですべての履歴レポートが消えてしまいます。さらに、格納されているデータの種類が原因で、マージ プロセスが少し面倒になる可能性があります。全体として、これは今のところ私の選択の可能性が高いです。

他の誰かが以前にこの問題を抱えていたかどうか、もしそうなら、サイトを停止せずに、できればユーザーへの中断を最小限に抑えて、どのように対処したのだろうか? 2 番目の方法、または別の同様の方法を使用する場合、夜遅くに実行し、翌朝早くマージを実行するようにスケジュールを設定し、事前にユーザーに知らせることができるので、大したことではありません。誰かがクリーンアップを行うためのより良い、またはより簡単な方法についてアイデアを持っているかどうかを確認しているだけです.

この.htaccessをインストールして、ユーザーにサイトのメンテナンスを通知しようとしました。最初の[L]が機能しておらず、2番目の書き換えがすべてを行っているようです。

サイトメンテナンスメッセージはどのように行いますか？

私の会社は、サポートにお金を払っている大規模な組織にオンサイトでインストールされたアプリケーションのコンテキストで、メンテナンス リリースと「通常の」リリースの問題に苦しんでいます。まず、私の用語を定義させてください。

• 製品のバージョン 1.0、1.1、および 1.2 をリリースしたとします。これらは、私が「通常の」リリースと呼んでいるものです。つまり、開発のメイン ブランチからの次のリリースであり、最新かつ最高のバグ修正と機能強化がすべて組み込まれています (リリースごとにそれぞれ数十もの可能性があります)。
• ここで、1.0 の大物顧客が、これまで誰も遭遇したことのないショーストップの問題を報告したと想像してください。この問題は 1.2 にもまだ存在しており、残念ながら 1.3 は数週間または数か月でリリースされません。そこで、コードを 1.0 で分岐して、問題を修正する 1 つの変更だけを含む1.0.1 の「メンテナンス」リリースを作成します。

このアプローチでは、次の通常のリリースまで数週間待たせる代わりに、1 日ほどで問題を修正できるため、お客様は満足しています。また、メンテナンス リリースには小さな変更が 1 つしか含まれていないため、大規模な UAT プロセスを実行する必要はありませんが、次の通常のリリースにアップグレードする場合は、いくつかのバージョンが含まれている可能性があり、おそらく 30 または 40 を受け取ることになります。 (彼らのリスク回避的な意見では) 大規模な UAT を必要とする製品の変更。

問題はそれです：

• ソフトウェアの複数のバージョンを作成してサポートするにはコストがかかります
• これにより、泥沼に固執する顧客が最新バージョンから大幅に遅れることができます
• インストールが他のすべての 1.0 の顧客と微妙に異なるため、これらの顧客を将来最終的にアップグレードするプロセスが複雑になります (データベースのアップグレードは、メンテナンス リリースで何らかの形で変更された場合に特に複雑になります)。

それで、この問題に対する他の人たちのスタンスはどうなのかと思っていましたか? メンテナンス リリースの急増によって自分自身の背中のためにロッドを作成せずに、どうすれば顧客を満足させ続けることができますか? たとえば、一部のカテゴリの修正をメンテナンス リリースとして実行することを許可しますが、他の種類の修正は次の通常のリリースで実行することを主張しますか?

明確化: バグのないソフトウェアを書くことは完全な解決策ではありません。なぜなら、上記の文脈における「問題」は、私たちの製品が依存する外部システムの動作に対する予測不可能な変化である可能性があるからです。