問題タブ [migration]

Visual Studio 2005 で既存の Delphi 7 ビジネス アプリケーションを .NET 2.0 に移行する方法について何かアドバイスはありますか?

Visual Studio 2005 は既に購入済みで、会社は Borland/Codegear ツールから離れたいと考えています。

このアプリケーションは単一のクライアント サーバー実行可能ファイルであり、多数のサード パーティの UI コントロールとレポート用の Crystal レポート 10 を利用しています。

多くの SQL Server 2000 ストアド プロシージャだけでなく、UI 内の Delphi 型にまたがる広範なビジネス ロジックがあります。ストアド プロシージャ ロジックの多くを .NET クラスに移動することも、もう 1 つの目標です。

顧客への影響を軽減するために、可能であれば、完全な書き直し/変換ではなく、部分ごとのアプローチが推奨されます。前もって感謝します。

[更新] この種のシナリオで Managed VCL を使用した経験がある人はいますか?

私たちのアプリケーションは適切に構造化されており (最善を尽くしました!)、モデルをビューから分割しました。次に、Web アクセスを使用してクライアントに情報を提供する必要があります。IIS と Web フォームを使用して小さなものを構築したいと考えています。

役に立つと思われる情報を次に示します。

1. コントローラーにはデータベースクエリのスレッドがあります
2. 私たちのデータベースはPostGresqlです
3. すべてC#2.0でビルド
4. Winform のビューとコントローラーの間で多くのデータバインディングを使用しました。
5. Winform は内部目的で残り、インターネット上で利用できるのはほんの一部です。

この種の動きに対するあなたの提案は何ですか?

アップデート

当社のサーバーで Web をホストするので、データベースは社内に留まります。データを複製したり、同期したりする必要はありません。

多くの開発者は、あるプログラミング言語から別のプログラミング言語への移行は比較的簡単であると主張します。言語が同様のパラダイムに基づいている場合は特にそうです。ただし、実際には、言語の構文を学習することではなく、言語のニュアンスを深く理解し、さらに重要なことに、言語のライブラリで何が提供されているかを知ることが努力の対象となります。たとえば、Java から .Net への切り替えは、構文の観点からは難しくありませんが、プログラミングの効率を高めるには、使用可能なライブラリに関する十分な知識が必要です。PHP から .Net への切り替えは、言語の違いを考えると、さらに大きなハードルを提示する可能性があります。

開発者が同じパラダイムで別の言語に移行する場合の実際のオーバーヘッドは何ですか? パラダイムが異なる場合はどうなりますか？

私が始めた新しい仕事では、コア ビジネス ロジックの重労働のほとんどを処理する Java アプリケーションと、もちろんこのサーバーへの Web インターフェイスを処理する Rails アプリケーションの両方を使用しています。これらは両方とも同じデータベースにアクセスします。

これまで、ほとんどの焦点は Java アプリケーションに向けられていたため、Rails プロジェクトには移行がありません。共有データベースを更新するための sql は、changes.sql のようなファイルで管理されます。

ご想像のとおり、これにより開発がやや難しくなります。

Java プロジェクトと Rails アプリケーションには依存関係があるため、コードベースを結合し、その SQL ファイルをソースで管理することを最初に考えました。ただし、他の誰かがこの問題に取り組み、ある程度成功したかどうかを確認するために、ここで質問したいと思いました.

Java 5 に移行したばかりのかなり大量のコードがあります。Java 5 バージョンでのリリースを目標として、これらのコンポーネントでジェネリックを使用してきましたが、残りのコードはもちろん生のコードでいっぱいです。種類。生の型のエラーを生成するようにコンパイラを設定し、手動でそれらをクリアし始めましたが、現在の速度では、処理に非常に長い時間がかかります (約2500のエラーがあります)。そして、これは Eclipse の便利な Infer Generic Type クイック フィックスによって実現されます。これは常にエラーを取り除きますが、多くの場合、さらに作業が必要なコードを生成します。

これに対処するより良い方法はありますか？Eclipse より優れた自動化ツールはありますか? リファクタリングを1つずつ行うのではなく、すべての発生に適用する方法はありますか? それとも、警告を無視しますか?

私は現在、ソース管理用の CVS リポジトリを維持しています。StarTeam への移行が進められています。すでに購入されており、ほとんどのプロジェクトの企業標準となっています。StarTeam サーバーの企業所有者から、現在の CVS リポジトリを StarTeam に完全に移行する既知の方法はないと言われました。最新バージョンをチェックアウトして、それを StarTeam にインポートすることをお勧めします。

私は自分のバージョン履歴をすべて保持したいと思っています。単純にすべてのデータを失うか、CVS リポジトリを無期限に維持するかを選択する必要はありません。

これをやって運が良かった人はいますか？推奨されるツールまたはプロセスはありますか? それとも、時間を無駄にしているだけで、移行して損失を削減する必要がありますか?

更新: Borland からの公式の回答では、これは間違いなく実行可能ですが、ボックス版のソフトウェアでは実行できません。これを実現するために、ボーランドからサービスを購入できます。

大規模なプロジェクトを StarTeam 5 から Subversion に移行する必要があり、メジャー リリースの (少なくとも) 5 ～ 10 のスナップショットを保持したいと考えています。私は次のことを検討しました：

• 各スナップショットの手動またはスクリプトによるエクスポート/インポート。利点: 分かりやすく、ラベル付き/日付付きのバージョンを簡単に選択できます。短所: 時間がかかる、コメントが保持されない。
• Polarion は svnimporter で完璧なツールと思われるものを提供しますが、StarTeam 5 には存在しない StarTeam 8.0 の .jar ファイルが必要です。利点: 自動化、完全。短所: 1 回限りの使用のために StarTeam 8.0 にアップグレードする必要があります。
• いくつかの中間リポジトリ (例: StarTeam -> CVS -> Subversion) を介して移行します。StarTeam と協力してくれる仲介者をまだ見つけていません。
• 最新のソースのみを移行します。利点: シンプル、高速、開発者が歴史を繰り返すのではなく、新しいソリューションを発明することを奨励します。欠点: 開発者が歴史を繰り返すのではなく、新しいソリューションを発明することを奨励します。:-)

あなたが提供できる経験や提案をいただければ幸いです。ありがとうございました。

ローカル ワークステーションに CVS リポジトリがあります。バージョン管理が素晴らしいアイデアであることを雇用主に示しました。大丈夫！そこで、CVS 履歴をローカル ワークステーションから実サーバーに移行したいと考えています。

サーバーに CVS をインストールしましたが、動作しています。

さて、リポジトリ ファイルを移動することはできますか? または、何らかのインポート コマンドを実行する必要がありますか?

現在のコードベースを新しい CVS サーバーにチェックインできることはわかっていますが、それでは履歴が失われてしまいますよね?

ですから、私は少し古臭いかもしれませんが、過去に Web サイトを作成したときは、開発サーバーでサイトを開発してから、ページとファイルを運用サーバーに公開または昇格していました。これは常に、私たちの 1 人が失敗したためにページがめちゃくちゃになったり、サーバーがダウンしたりするのをユーザーが見ないようにするための良い方法であると思われてきました。

しかし、Microsoft が SharePoint を作成したときにこの考えを念頭に置いていたようには見えません...少なくとも、定義されているインフラストラクチャでこれを行う方法を見つけることができませんでした。

SharePoint 開発の管理戦略があるかどうか知っている人はいますか? 開発環境のバックアップを作成し、運用サーバーに復元できることをオンラインで読みました。最初はうまくいくかもしれませんが、運用サーバーへの更新は、運用サーバーでデータが失われる危険を冒さずにそれを行うことはできません。リストのコンテンツ、ページ、およびドキュメントをあるサーバーから別のサーバーに移行するためのツールがいくつか出回っていますが、確かに、それらについてはまだ調査していません。

しかし、私のもう 1 つの懸念事項は、カスタム コンテンツ タイプです。リストがコンテンツ タイプを使用すると、リストからアイテムを削除し、コンテンツ タイプの関連付けを解除し、コンテンツ タイプを再度関連付けないと更新できないようです。コンテンツ タイプをアップグレードする方法はありませんか?

とにかく、これらの現在のジレンマのいずれかについて何か提案があれば、ぜひご連絡ください.

前もって感謝します、

ダン

早々に返事をくれてありがとう。

サイト用に作成されたいくつかの機能と、基本 (コンテンツ タイプ、列など) に向けられた機能をバンドルするソリューション パッケージ、およびブランド化に関係する機能 (ページ レイアウト、マスター ページなど) のための別のソリューションが既にあります。

しかし、これは 1 回限りのショットのようです...基本的に、これでサーバーがセットアップされますよね? 運用環境を使い始めると、ドキュメント、ページ、リスト アイテムがすべてコンテンツ データベースに存在することになり、コンテンツ タイプや列などを更新することはできなくなります。

新しい機能をインストールしてアクティブ化する前に、非アクティブ化してアンインストールする必要がある機能ですよね? 機能定義で Version プロパティを見たことがありますが、私が知る限り、これは何もしません。ソリューションは、バージョン番号を増やすことでアップグレードできるように見えますが、特に使用中の場合、コンテンツ タイプや列などを変更するようには見えません。さらに、ソリューションによるアップグレードがどれほど広範囲に及ぶかはわかりません。

この種のことについては、貴重なドキュメントがほとんどありません。私が読んでいるのは、SharePoint サーバーを最初にセットアップする方法だけのようです...長期的に管理することではありません。

アドバイスや提案はありますか？

ご提案いただきありがとうございます。

しかし、私たちはこのサイトに 1 年以上取り組んできました。私たちは、あなたのほとんどが推奨しているものに従って、すでにセットアップされていると確信しています. コンテンツ タイプ、列、マスター ページ、ページ レイアウト、ワークフローなどをインストールするいくつかの機能が既に用意されています。これらの機能のほとんどは、ソリューション パッケージに含まれています。すべての開発環境を VPC サーバーとしてセットアップしました。

これで、初期展開はほぼ完了しました。私が本当に知りたいと思っているのは、コンテンツの種類や列などをアップグレードする方法です。使用後にコンテンツ タイプを変更することはできますか? 私の最初のテストに基づいて、これが可能であるとは思えないからです。アセンブリは問題なく交換されているように見えるため、アセンブリについては心配していませんが、コンテンツ タイプを更新する唯一の方法は、それらを参照しているアイテム (つまり、ページ ライブラリ内のすべてのページ) を削除することです。コンテンツ タイプを再追加します。

最初の展開後にコンテンツ タイプを更新する方法があるかどうか知っている人はいますか? ...ユーザーが既にデプロイ済みのコンテンツ タイプに基づいてアイテムを作成した場合は?

(私の質問の他の部分は、実際には既存のページを開発サーバーから本番環境に移動することでしたが、それがなくても生きていけます。私の主な心配はコンテンツの種類です。)

私は 2 つのマシンを持っています... 開発マシンと生産マシンです。Rails アプリを本番サーバーに初めて導入したときは、何の問題もありませんでした。rake db:schema:load RAILS_ENV=production を実行して schema.rb をインポートしました。すべてが順調でした。

そこで、開発マシンでさらにいくつかの変更と別の移行を行い、新しいアプリケーションを運用マシンにコピーしました。次に、rake db:migrate RAILS_ENV=production を実行してデータベースを更新しようとしました。次のエラーが表示されます:「データベースには、'schema_migrations' という名前のオブジェクトが既に存在します。」

私は自分自身に考えています、冗談じゃないレーキ... あなたがそれを作成しました! rake で trace を実行しましたが、rake が実行されたのはこれが初めてだと思われるようです。しかし、開発マシンと本番マシンの「schema_migrations」テーブルを分析すると、1 つの移行、つまり移行したい移行に違いがあることがわかります。

また、バージョン番号を明示的に定義しようとしましたが、それも機能しません。

本番サーバーを最新の状態にする方法について何かアイデアはありますか?

アップデート：

データベースを単に「ドロップ」することはできないということから始めましょう。これは、すでに 100,000 を少し超えるレコードがある運用サーバーです。今後、同様の問題が発生した場合はどうなりますか? データベースに問題が発生するたびにテーブルを削除する必要がありますか? 今回はうまくいくかもしれませんが、すべてのデータベースの問題に対する実際的な長期的な解決策とは思えません。私が今抱えている問題は、私だけのものではないと思います。

1. 「schema_info」テーブルと「schema_migrations」テーブルは同じようです。私のセットアップでは、「schema_migrations」しかありません。前述のとおり、本番サーバーと開発マシンの「schema_migrations」テーブルの違いは 1 つのレコードだけです。つまり、移行したい変更のバージョン番号を含むレコードです。

2. 私が読んだ本「Simply Rails 2」には、最初に本番サーバーに移動するときは、rake db:migrate を実行する代わりに、rake:db:schema:load を実行するだけでよいと書かれています。

3. 問題があれば、Rails バージョン 2.1 を使用しています。