NWDI:全体:開発の流れ
0 281

このトピックでは、 NWDI を使用した開発の流れを抜粋して説明します。

NWDIを使用した開発の流れは製品・リリース毎に設計、管理され、通常、開発準備→開発→移送及びテスト→本番稼働→運用保守などのフェーズに分けられます。
NWDIで開発流れは開発トラックで定義されます。
製品が本番稼働後、大きなアップグレードは別のリリースをとり、新しい開発流れを起こしますが、不具合修正やある程度の機能改善は、運用保守フェーズとして、同じ開発流れで対応するのが一般的です。

NWDIを使用した開発を始めるまえに、まず下記のようにNWDIの環境を整える必要があります。

  • 構成要素(DTR、CBS、CMS、SLDなど)のインストール
  • システムランドスケープに関する情報の更新

開発準備

開発準備は以下のステップがあり、基本は管理者の作業となります。

  1. ユーザ及びロールの登録 UMEAdmin
  2. 製品及びソフトウェアコンポーネントの作成 SLD
  3. 名称領域の予約 ネームサーバ
  4. CMSドメインの作成 CMS
  5. システム、トラック、開発設定の作成 CMS 
    トラックによって1つ以上のSCで構成されるリリースの開発フェーズが定義されます。 
    開発設定は、SCの特定のステータス(DEV、CONS)の開発に必要です。
  6. 必要なソフトウェアコンポーネントの確認とインポート CMS
  7. ローカル開発環境の設定 NWDS

開発

開発は、開発者の作業であり、ローカルのNWDSを使ってNWDI各サービスに接続して実施します。

開発作業は主に以下のステップになります。

  1. チェックアウト
  2. ソースの作成又は変更
  3. ビルド
  4. ローカルテスト
  5. チェックイン
  6. セントラルビルド、有効化
  7. デプロイ
  8. リリース

移送及びテスト

CMSを使用して、移送、テスト、アセンブリを行います。 
移送、アセンブリは管理者の作業であり、テストは開発者又はテスタが実施します。

本番稼働

CMSを使用してソフトウェアコンポーネントのバージョンを出荷します。

運用保守

運用保守フェーズで変更が発生するたびに、アクティビティ作成⇒修正⇒ローカルテスト⇒リリース⇒品証機移送⇒品質テスト⇒本番機移送という作業を繰り返します。

0 281
みんなのツイート (0)

関連サマリー


  • NWDI 0 Votes 88 閲覧数


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

    目的

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

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

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

    ファイル

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

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

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

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

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

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

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

    外部リンク

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


  • NWDI 0 Votes 176 閲覧数


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

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


  • NWDI 0 Votes 94 閲覧数



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

    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

  • NWDI 0 Votes 81 閲覧数


     

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

    メイン画面

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

    プロセス照会

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

    アクティビティ検索

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

    トラック検索

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

    SC照会

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

    システムステート削除

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

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


  • NWDI 0 Votes 104 閲覧数


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

    概述

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

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

    構成

    (source: SAP Help Portal)

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

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

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

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

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

  • NWDI 0 Votes 127 閲覧数


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

    原因

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

    解決

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

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

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

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

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


  • NWDI 0 Votes 93 閲覧数


    デザインタイムリポジトリ (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  

  • NWDI 0 Votes 197 閲覧数



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

    コンセプト

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

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

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

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