このトピックでは、統合Conflictを取り上げて、その発生原因と解決策を説明します。

原因

ワークスペースを統合する際に、同じソースで、前回統合された後に、別々修正が発せしていれば、システムが判断できないため、
統合Conflictが発生します。
以下の図でそのイメージを示します。
(source:SAP Help Portal)

解決

統合Conflictが発生したときに、統合元のソースはActiveバージョン、統合先のソースはCollidingバージョンとして格納されます。同時にConflictフラグをワークスペースに立てられます。
解決方法は下記のようになります。

統合元のソースが正であれば、Activeバージョンを採用します。統合先のソースが正であれば、Collidingバージョンを採用します。各自の修正内容をマージする必要があれば、マージを取ります。

いずれにしても新たにアクティビティを起こして対応する必要があります。

対応の手順を簡単に示します。

統合Conflictビューを表示
差異を確認1)
対象DCを選択して、コンテキストメニューから対応方法を選択
ここでは統合元ノースを採用する
新たなアクティビティに記録
アクティビティをチェックイン
対応後のバージョングラフを確認(必須ではない)
外部リンク統合コンフリクトの解決 - SAP Help Portal

このトピックでは、それらのツールを取り上げてそれぞれ説明します。

DTR Client概述

DTR Clientは、Eclipse Perspectiveとして、NWDS環境に統合されています。
そこで、各DTRクライアントツールはeclipse viewとして多数用意されています。

各ツールClosed ActivitiesIntegration ConflictsOpen Activities

オープン中のActivity

ビューのツールバーメニューから全ユーザのActivityを照会することができます。

checkin(チェックイン)
Activityがチェックインされたら、ローカルの変更がすべてDTRのinactiveワークスペースに反映され、別の開発者も見えるようになります。
revert(変更を元に戻す)
PermissionsRepository Browser

ツリー構造で、Repositoryのリソースを照会することができます。

Version GraphyWEBを利用メイン画面

DTRのWEBツールのメイン画面は以下のようなURLからアクセスすることができます。

http://<host>:<port>/dtr/

ツールのアクセス

ツールバーにツールへアクセスするためのアイコンが並べられていますので、そちらを利用することができます。

また、リポジトリツリーの「system-tools」ノードよりも各ツールをアクセスすることも可能です。

各ツール

ファイルブラウザワークスペース比較

外部リンク DTRのブラウザベース設定とクエリツール - SAP Help Portal

デザインタイムリポジトリ (DTR) はファイルバージョン管理を提供するリポジトリ及びそのシステムです。
同じバージョン管理システムとして、オープンシステム開発系の世界では、以下のオープンソースソリューションがよく利用されています。

CVSSVNGit

歴史的には、最初はCVSがはやっていて、次はSVN、いまはGitが一番流行っているに間違いないです。

コンセプト

DTRはファイルバージョン管理を提供するリポジトリです。SAP のカスタマサイトやパートナサイト、および SAP 自社開発で使用されます。

DTRは以下のコンセプトがあります。

ソースコード及びバージョンを一元管理 
DTRでは、すべてのソースプログラム及びバージョンはセントラルデータベースで一元管理され、 標準DeltaVおよびWebDAVアクセスプロトコルによってDTR クライアントに階層ファイルシステムを公開されます。 
そのため、DTRはCVS、SVNと同じ、集中型バージョン管理システムといえます。変更を確実に管理 
ソースコードに改修が発生する時に、まず変更依頼を作成しておかないといけない、改修はすべて変更依頼に記録されます。 
これは本来プロジェクト管理システムの一部機能であり、よくチケットやチケット駆動開発と呼ばれています。DTRに統合されることにより、システムの変更がすべて確実に管理されることになります。ライフサイクルの各フェーズを統合的にサポート 
開発やテストの各フェーズの間にソースの変更と移送が一元管理されます。実現アーキテクチャ

(source: sap help portal)

ワークスペース

DTRリポジトリは、複数の論理開発ロケーション(仮想リポジトリ)から構成されます、その論理開発ロケーションはワークスペースと呼ばれます。

ワークスペースはDTR構造の基本要素であり、以下のような仕組みで機能しています。

ソフトウェアコンポーネント単位でワークスペースが分けられます。4システムランドスケープの中でDEVとCONSが異なるワークスペースを使用、TESTとPRODが持たないことが多い各システム(DEV、CONS）を無効と有効との二つのDTRワークスペースで表現。全ての変更は無効なワークスペースで実行し、ビルドが完了したソースのみが有効なワークスペースに格納されます。有効なワークスペースはCBSで利用可能なアーカイブと常に同期します。同じソースはワークスペースに跨ってDTR全体で一元管理されます。そういう意味で、ワークスペースはSVN、GITなどのような一般のバージョン管理システムにおけるブランチに相当するものと考えられます。DTRの構造

以下、DTRの構造のイメージです。 

system-tools -|administration -|reports --|Activity Search --|Conflict Search --|File/Folder Search --|Resource Lookup --|VersionSet Comparison --|Workspace Comparison --|Workspace Integrations ws -|track_1 --|sc1 ---|cons ----|active ----|inactive ---|dev  

このトピックでは、開発トラックを取り上げて説明します。

概述

開発トラックとは、1つの開発の流れを定義します。

開発トラックには、開発されるSCのさまざまな開発ステータスの開発設定及び実行時システムが含まれます。

構成

(source: SAP Help Portal)

セントラル開発システム(DEV)では、開発者のローカルPCで作成したソースを個々の開発者がさらにテストをします。

コンソリデーションシステム(CONS)は、特定の固定ステータスのSCの統合とそのSCの追加テストに使用されます。

その後、本稼働システム(PROD）へ適用する前に、テストシステム(TEST)でSCの新規バージョンを最終テストをします。

必要に応じて、これらの4つのシステムロールを実行時システムに割り当てることができます。実行時システムでは、インポート時に自動的にデプロイが実施されます。

外部リンク開発トラックを使用した作業 - SAP Help Porta

このトピックでは、DTRのバージョン管理の仕組みを取り上げて説明します。

目的

主に下記の二つあります。

変更歴史の記録 
バージョン間の変更点を確認したり、ふるいバージョンに戻したりすることができます。統合時の判断 
ソースファイルを統合する際に、バージョンを比較して統合できるかを判断できます。管理レベル

DTRはファイルとワークスペースと二つのレベルでバージョン番号を管理しています。

ファイル

ファイルはそれぞれ個別のRev No.(リビジョン番号)をもっています。 
Rev No.は、ワークスペース内で採番されます。1から始まり、ファイルが変更されるたびに一つずつあがっていきます。
ファイルのRev No.はNWDSで確認することができます。

対象ソースを指定、コンテキストメニューから「Revision History」を選択 
Revision一覧を表示 
ISNなども表示されますので、後ほどの説明に関わります。 
ワークスペース

ワークスペースレベルのバージョン番号は、ISN (Integration Sequence Number、統合順序番号)と呼ばれます。 
ワークスペースにチェックインされた変更には、そのワークスペース内で適用される一意なISN番号が割り当てられます。

ワークスペースへの変更は、アクティビティによるものと、伝播(Propagation)によるものがあります。

アクティビティ 
ローカルワークスペースで行った修正伝播
トラックに跨ってインポートされる変更統合

ワークスペースが統合されるときに、ファイルのバージョンが統合されます。

バージョングラフから、ワークスペースに跨ったファイルのバージョン歴史を確認することができます。 
そこで、ワークスペース間でどうな統合が発生したのか、次の統合にコンフリクトも確認できます。

外部リンク

セントラルソースファイル管理 - SAP Help Portal

変更管理サービス(CMS)は、ソフトウェア変更のシステム間の移送管理を行います。システムは開発設定と実行システムのどちらかまたは両方で構成することができます。
システムはシステム開発のフェーズ(開発、コンソリデーション、テスト、本稼働)に対応します。CMSはABAPシステムのCTSに相当します。

コンセプト

CMSはソフトウェアの変更を一元で管理可能にするサービスです、JavaシステムのCMSはABAPシステムのCTSと同等します。

CMSのコンセプトは主に以下になります。

ソースの改修を開発システムに限定します。手作業ミスをなくし、システムにより改修内容を確実に開発システム→テストシステム→本番システムの間に移送します。ソフトウェアの構築とデプロイを自動化可能にします。実現アーキテクチャ

構成要素開発ドメイン

開発ドメインは、システムランドスケープ全体の構成を定義します。

開発ドメインには複数の開発トラックを含めることができます。

開発トラック

開発トラックは一つの開発の流れを定義します。 
一つの開発トラックには、一つ以上のソフトウェアコンポーネントの開発、テスト、本稼働に必要な開発設定と実行時環境がすべて組み込まれます。

システム

CMSにおけるシステムは、厳密的にはシステムロールのことであり、開発設定と実行環境から構成され、各フェーズ(開発、コンソリデーション、テスト、本稼働)に対応します。 

システムロールは、開発設定のみ、または実行環境のみのものとしても定義することができます。

CBSはDTRと密接に連携しています。DTRからソースコードを取得して、ビルドします。アプリケーションサーバの設定があれば、ビルドできたアカイブ(ear,sdaファイルなど)をサーバへデプロイします。

コンセプト

CBSはシステムの構築作業を集中管理可能にして、 NWDIにおいて中心的な役割を果たしています。

実現アーキテクチャ画面機能

CBSは主に以下の機能を提供しています。

オンデマンドのビルド 
変更のセントラルビルドは依頼によりリアルタイムで発生します。変更がチェックインして有効化される際に自動的に依頼されることもあれば、管理者が明示的に指示することもあります。ビルド結果およびビルドツールの一元的な保管有効化コンセプトの保証 
開発オブジェクトの無効および有効ステータスが区別されます。無効ステータスのオブジェクトから有効ステータスのオブジェクトに変更を渡すには、これらを有効化しなければなりません。この前提条件は、変更された開発コンポーネントのセントラルビルドが正常に行われていることです。

 

このトピックでは、トラック内移送とトラック間移送に分けてNWDIにおける移送プロセスを説明します。

 トラック内移送

以下の図でトラック内移送の概要を示します。 

開発者側作業

開発者側の作業はすべてNWDSで実施されます。

1.有効化

開発者が作成又は変更したソースをチェックインしたら、該当ソースはDTRのinactiveワークスペースからactiveワークスペースに反映され、有効化されます。 
ソースが有効化すると、元開発者が保持したロックが解放されるため、同じ開発設定を使用するすべての開発者から再度修正をかけることができます。 
有効化されるソースは、CBSにより再ビルドされます。

2.リリース

有効化及び開発システムでのテストが正常に完了すると、開発者はアクティビティをリリースし、CMSに変更を転送します。 
これによって、開発者に選択された全てのアクティビティが一つのリリースに纏められ、コンソリデーションシステムのインポートキューに格納されます。

ABAPスタックの移送ディレクトリと異なり、インポートキューはファイルシステムではなくデータベースにされます。 
CMS_TQUEUE：インポートキュー 
CMS_THISTORY:インポート履歴 
CMS_RCHANGELIST: 変更依頼の割当

管理者側作業

管理者側の作業は、WEB画面のTransport Studioで実施されます。

3.インポート

インポートは、インポートキューに入っている変更依頼を選択してコンソリデーションシステムに取り込みします。 
CMSによって、自動ビルドと関連する実行時システムへの自動デプロイが行われます。

ログファイルです。 
CMS/log：　エクスポート及びインポートのログ 
CMS/archives:　エクスポート時に生成されるscaファイルおよびpraファイル 
CMS/CBS`: デプロイのためにCBSによって生成されるsdaファイル

4.アセンブリ

アセンブリは構築のことです。 
この間に変更依頼が収集され、それに基づいて、すべての変更依頼を含めたSCバージョンが作成されます。 
個々の変更依頼はこれ以降の転播に使用されません

5.承認

承認とは、テストシステムで検証が完了したSCを本稼働システムへの移送を許可することです。 
承認によって、本稼働システムのインポートキューにSCが格納されます。

6.出荷トラック間移送

現場レベルのシステム開発環境は通常、連続する複数の開発トラックで構成されます。以下の理由がよくあげられます。

複数の検証環境が存在するため、複数のトラックを定義する必要開発と保守を分けるため、複数のトラックを定義する必要ソフトウェアコンポーネントを別々開発するため、複数のトラックを定義する必要

(source:SAP Help Portal)

トラック間移送を行うには、トラック間の接続を設定しておく必要があります。