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

このトピックでは、 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 165
みんなのツイート (0)

関連サマリー


  • NWDI 0 Votes 21 閲覧数


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

    コンセプト

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

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

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

    構成要素開発ドメイン

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

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

    開発トラック

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

    システム

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

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


  • NWDI 0 Votes 94 閲覧数



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

    コンセプト

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

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

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

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

     


  • NWDI 0 Votes 24 閲覧数


    このトピックでは、DTRのアクティビティを取り上げて説明します。 

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

    概述

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

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

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

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

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

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


  • NWDI 0 Votes 31 閲覧数


    このトピックでは、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 81 閲覧数


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


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

    原因

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

    解決

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

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

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

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

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


  • NWDI 0 Votes 35 閲覧数


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

    概述

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

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

    構成

    (source: SAP Help Portal)

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

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

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

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

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

  • NWDI 0 Votes 21 閲覧数



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

    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