Ultima Businesswareのバージョン管理

この記事では、 私たちのプラットフォームでグループワークを組織化するためにどのメカニズムがあるかを教えます。

不可解な理由で、すべての開発グループに共通する問題は、コードの品質と信頼性が最優先されるべきと思われるERPシステムで3番目に重要です。

ただし、これにより（この観点から）この分野の先駆者の栄誉を主張することができます。

既往歴

プラットフォームの最初のバージョンにはバージョン管理のサポートがありませんでした 。



このブログの以前の記事を読んでいない場合は、簡単な説明を読んでおく価値があります。

したがって、オブジェクトまたはスクリプトコードの構造の変更は、システムのユーザーを含むすべてのユーザーがすぐに利用できるようになりました。



エラーをユーザーに即座に配信するための素晴らしいメカニズム。



少し苦労し、間違いなく完全に書くことが機能しないことを確認した後、私たちは松葉杖に限定することにしました。



公平に言えば、非常に厳しい締め切りのために、これは複雑なメカニズムよりも簡単に取り付けられた松葉杖が好まれた時代だったと言わなければなりません。

そのため、ソリューションはスクリプト用に2つのバージョンを作成することでした-開発者用とユーザー用です。 すぐに、テスト用に3番目のバージョンがそこに追加されました。



ただし、これはもちろん、原則的に問題を解決しませんでした。

エラーはすぐにユーザーに伝わりなくなりましたが、複数の開発者による単一の変更との競合は解消されていません。



新しいバージョンの開発中、私たちは基本的に松葉杖を放棄し、完全に機能するメカニズムを実装することにしました。



ビジネスオブジェクト、スクリプトなどのコミュニティ全体として構成の概念を導入し、プラットフォームの構成用に分散バージョン管理システムを実装しました。 したがって、各開発者は、他の開発者やユーザーに影響を与えることなく、自分のブランチに変更を加えます。 したがって、すべての変更は制御された安定した環境で行われ、「予期しない」エラーの可能性が大幅に減少します。 したがって、すべてのバージョンは構成バージョンのツリーを形成し、各バージョンには完全な（少なくとも開発者によると）変更セットが含まれています。 システムは、デフォルト（Mercurialの用語を使用）ブランチから変更をプルし、デフォルトブランチに変更をプッシュするためのすべてのメカニズムを実装しています。 根拠がないように、アプリケーションのスクリーンショットを提供します。



各開発者（またはロシア語でクルグゾの音に関係なく展開マネージャー）は、何が、誰によって、いつ行われたかを見ることができます。 次のタブで、どのような変更が行われたかを確認できます。



競合解決の最後のタブは、Mercurialなどのバージョン管理システムを使用している人には馴染みがあるはずです。 また、異なるバージョンのオブジェクトを比較するためのすべてのメカニズムを添付しました。



スクリーンショットでテキストを詰まらせることはもうありません。必要なメカニズムはすべて揃っています。



また、すべての変更をCRM（変更要求管理）システムにリンクしました。これで、何が行われたのか、なぜ、または逆に変更から対応する変更要求に移行するのかを確認できます（Webインターフェイスを備えたシステムが適しています）。



一般的に、バージョン管理システムをプラットフォームに統合すると、多くの便利なトリックを実行できます。 たとえば、リソース転送の可用性を監視します。 この構成にはロシア語と英語のサポートが付属しているため、すべてのリソースでそれぞれロシア語と英語への翻訳が必要です。 このチェックを行いました-変更のデフォルトブランチにプッシュするとき、すべてのリソースが翻訳されていない場合、開発者はメッセージを受け取ります。 これでは十分ではなかったため、Roslynプロジェクトを台無しにしてスクリプトを分析しました。 スクリプトに翻訳可能なリソースで置き換えられていない行がある場合、開発者もメッセージを受け取ります。



他に何-統合された統合された単体テスト、バージョン管理システム、およびチームシティ。



統合バージョン管理システムの実装により、内部開発プロセスが大幅に簡素化および自動化されました。

プラットフォームにバージョン管理システムを統合する合計：

1. スクリプトまたはメタデータ構造の同時変更により、エラーの数が大幅に減少しました。
2. 開発およびテストプロセスの透明性と予測可能性が向上しました（実装されている機能、機能の注文者などがわかっています）。
3. 緊急控訴の数は減少しました。

現在、組み込みのUNITテストメカニズム、開発者向けの個別バージョン、コメントの変更、タグ付けのタグがない場合、変更要求にバインドする変更はなく、混乱の悪夢として記憶されています。