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

原因

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

解決

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

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

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

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

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

 

サポートツールでは、CMS管理用の幾つかのツールが提供されております。

メイン画面

URL:http://host:port/CmsSupportTool/

プロセス照会

CMSシステムで発生していた各プロセス(インポート、ビルド、承認)の情報を照会できます。

アクティビティ検索

CMSシステムで作成されていたアクティビティを検索することができます。

トラック検索

指定ソフトウェアコンポーネント(SC）が取り込まれたトラックを検索することができます。

SC照会

指定トラックに取り込まれたソフトウェアコンポーネント(SC)の情報を照会できます

システムステート削除

システムステートを削除できます。

間違って追い越しして後のリリースが先に移送されてしまった場合、対象システムのシステムステートをクリアしておけば、古いリリースが再び移送可能になります。

このトピックでは、トラック内移送とトラック間移送に分けて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)

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

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

概述

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

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

構成

(source: SAP Help Portal)

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

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

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

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

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

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

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のアクティビティを取り上げて説明します。 

(このトピックは編集中です。)

概述

アクティビティ(英：Activity)はDTRへ対する変更の開発及び移送の管理単位です。ABAPスタックにおける変更依頼に相当します。

アクティビティはOpenとClosedとの二つのステータスがあります。

Open Activity 
変更中のアクティビティです、ここで行う任意の変更を元に戻すことができます。Closed Activity 
チェックインした後のアクティビティです。これらのアクティビティを変更することはできなくなります。ライフサイクル

このセクションはアクティビティ のライフサイクルを順次説明します。

作成変更の記録チェックイン有効化リリース照会

NWDSやWEB-UIからアクティビティ一覧を照会することができます。アクティビティ一覧からワークスペース全体の変更経緯を確認することができます。

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

目的

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

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

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

ファイル

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

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

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

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

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

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

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

外部リンク

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