# 2 – SAP 変更の欠点を減らし、修正を簡単にし、フローを改善する
**どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか?** リファクタリング、品質についてのすばやいフィードバック、バグ修正を可能にし、本番環境への変更のフローを改善するアプローチを採用します。これらにより、本番環境に採用される有益な変更を加速させ、デプロイされた問題を制限できます。またデプロイアクティビティを通じて挿入された問題をすばやく特定し、修復できます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-2.html)
詳細については、以下のリンクと情報を参照してください。
+ AWS 動画: [Ops を考慮に入れて設計する](https://youtu.be/uh19jfW7hw4?ref=wellarchitected)
+ AWS ドキュメント: [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/?ref=wellarchitected)
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/what-is-launch-wizard-sap.html#:~:text=AWS%20Launch%20Wizard%20for%20SAP%20is%20a%20service%20that%20guides,deploy%20SAP%20applications%20on%20AWS.)
+ SAP on AWS ブログ: [DevOps for SAP – Driving Innovation and Lowering Costs (SAP 向け DevOps – イノベーションの促進とコストの削減)](https://aws.amazon.com/blogs/awsforsap/devops-for-sap-driving-innovation-and-lowering-costs/)
# ベストプラクティス 2.1 - バージョン管理と設定管理を使用する
Configuration Management システムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。そうすることで、変更の追跡、新しいバージョンのデプロイ、既存バージョンへの変更の検出、以前のバージョンの回復 (障害が発生する場合に、その前の良好な状態に戻すなど) をサポートします。設定管理システムのバージョン管理機能を SAP 全体のすべての手順 (インフラストラクチャ、データベース、アプリケーション、SAP カスタムコードと開発) に統合します (例えば、ABAP、Java、UI5/JavaScript)。
各タイプの設定に異なるバージョン管理システムを検討しますが、メトリクスをセントラルリリース計画ツールに統合します。非トランスポータブル設定とバイナリバージョニングを環境全体で管理する方法を検討します。(例: SAP カーネルバージョンが環境全体で整合していることをどのように確認しますか?)。
**提案 2.1.1 - SAP 開発コードとバージョン管理に SAP 変更管理またはその他のサードパーティー製ツールを実装する**
すべての開発アプローチと SAP アプリケーション (ABAP、Java、UI5/JavaScript) およびその他の拡張機能やスクリプティングエリアをサポートするカスタムコードを実装していることを確認します。複数の SAP デプロイパターンですべての SAP アプリケーションとコードデプロイをオーケストレートする方法を検討します (例えば、AWS と SAP ビジネステクノロジープラットフォームでホストされている関連した開発を同時にリリースする方法)。
+ AWS サービス: [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html?ref=wellarchitected)
+ AWS 動画: [AWS CodeCommit の紹介](https://youtu.be/46PRLMW8otg?ref=wellarchitected)
+ SAP on AWS ブログ: [SAP 用の AWS DevOps ツール、パート 1: Cloud Foundry アプリケーション](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-1-cloud-foundry-apps/)
+ SAP on AWS ブログ: [AWS DevOps tools for SAP, Part 2: SAP Fiori Apps (SAP 向け AWS DevOps ツール、パート 2: SAP Fiori アプリ)](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-2-sap-fiori-apps/)
+ SAP ドキュメント: [SAP 変更制御管理](https://help.sap.com/viewer/8b923a2175be4939816f0981b73856c7/LATEST/en-US/2b614e1cb8204f35b477eac703073589.html)
+ SAP ドキュメント: [SAP BTP のベストプラクティス - ライフサイクル管理](https://help.sap.com/viewer/df50977d8bfa4c9a8a063ddb37113c43/Cloud/en-US)
**提案 2.1.2 - SAP アプリケーションの設定管理システムを実装する**
ABAP、Java、およびその他の SAP テクノロジーに設定管理ツールを実装し、非トランスポータブル設定とバイナリバージョニングを環境全体で管理する方法を検討します。(例: SAP カーネルバージョンが環境全体で整合していることをどのように確認しますか?)。SAP Solution Manager を使用して、設定とバージョン変更を計画し、SAP アプリケーションに実装します。
+ SAP ドキュメント: [Enhanced Change & Transport System (CTS\$1) (拡張された変更および転送システム (CTS\$1))](https://support.sap.com/en/tools/software-logistics-tools/enhanced-change-and-transport-system.html)
+ SAP ドキュメント: [SAP Solution Manager: Planning Landscape Changes (SAP Solution Manager: 環境変更の計画)](https://www.sap.com/germany/documents/2016/08/8ea1d93a-857c-0010-82c7-eda71af511fa.html)
**提案 2.1.3 - オペレーティングシステムの設定管理システムを実装する**
AMI ベーキングまたは Ansible、Chef または Puppet などのインプレース設定管理ソフトウェアを使用して、SAP ワークロード オペレーティングシステム全体の設定管理を整合します。脆弱性のアラートを発し、オペレーティングシステムにパッチを適用して強化するように促す、セキュリティに重点を置いた設定管理ツールを検討します。
+ AWS ドキュメント: [AWS Systems Manager State Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html)
+ AWS ドキュメント: [Configuration management in Amazon EC2 (Amazon EC2 での構成管理)](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/configuration-management.html)
+ AWS ドキュメント: [AWS OpsWorks とは?](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html?ref=wellarchitected)
+ AWS ドキュメント: [Amazon Inspector とは](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html)
**提案 2.1.4 - データベースの設定管理システムを実装する**
データベースソフトウェアベンダーと連携して、使用しているデータベースの設定管理アプローチを理解します。
+ SAP ドキュメント: [SAP HANA Platform Lifecycle Management (SAP HANA プラットフォームライフサイクル管理)](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/LATEST/en-US/571d0bb4b1b2402f8e7caf0fe0290b61.html)
**提案 2.1.5 - インフラストラクチャの設定管理システムを実装する**
Infrastructure as Code (IaC) アプローチを使用して SAP ワークロードをサポートする AWS リソースをプロビジョンおよび管理します。AWS CloudFormation と AWS Cloud Development Kit は、AWS リソースでプログラムにより設定をプロビジョニングして管理できるツールです。ルールとポリシーを作成して定期的にインフラストラクチャを評価し、コンプライアンスを評価して問題があれば解決できる、設定監査と管理ツールを検討します。
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
+ AWS ドキュメント: [AWS Systems Manager インベントリ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html)
+ AWS ドキュメント: [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)
+ SAP on AWS ブログ: [Infrastructure as Code Example: Terraform and SAP on AWS (Infrastructure as Code の例: Terraform と SAP on AWS)](https://aws.amazon.com/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/)
+ SAP Lens [信頼性]: [ベストプラクティス 11.3 - サービスの可用性を復元するためのアプローチを定義する](best-practice-11-3.md)
# ベストプラクティス 2.2 – コード品質の向上のためにプラクティスを実装する
コード品質の向上のためにプラクティスを実装し、欠陥を最小限に抑えます。例えば、テスト駆動型デプロイ、コードレビュー、標準の導入などがあります。少なくとも SAP Code Inspector ツールを使用します。
**提案 2.2.1 - コード品質の向上のためにプラクティスを実装する**
例えば、テスト駆動型デプロイ、ペアプログラミング、コードレビュー、規約の導入などがあります。
**提案 2.2.2 - SAP 開発用 Code Amazon Inspector ツールを使用して、このプロセスを CI/CD パイプラインに統合する**
SAP ワークロードでの自動コード検査とリンティングに以下のツールを検討してください。
+ AWS ドキュメント: [Amazon CodeGuru - AWS Java および Python 開発用](https://aws.amazon.com/codeguru/)
+ SAP ドキュメント: [SAP Code Inspector for ABAP and SAP-specific development (ABAP と SAP 固有の開発向け SAP Code Inspector)](https://help.sap.com/viewer/ba879a6e2ea04d9bb94c7ccd7cdac446/LATEST/en-US/49205531d0fc14cfe10000000a42189b.html)
# ベストプラクティス 2.3 – 構築およびデプロイ管理システムを使用する
構築およびデプロイ管理システムを使用します。ABAP 変更および転送システム (CTS)、ウェブ IDE または SAP ツールなど SAP 認定ビルドとデプロイシステムを使用していることを確認します。これらのシステムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。
**提案 2.3.1 - SAP 構築およびデプロイシステムを実装する**
ABAP 変更および転送システム (CTS)、ウェブ IDE、SAP BTP 継続的デリバリーサービスまたはその他の SAP ツールなど SAP 認定ビルドとデプロイシステムを実装します。
+ AWS 動画: [ソフトウェア開発のための継続的インテグレーションのベストプラクティス](https://www.youtube.com/watch?v=GEPJ7Lo346A&ref=wellarchitected)
+ SAP on AWS ブログ: [AWS DevOps tools for SAP, Part 2: SAP Fiori Apps (SAP 向け AWS DevOps ツール、パート 2: SAP Fiori アプリ)](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-2-sap-fiori-apps/)
+ SAP ドキュメント: [Enhanced Change & Transport System (CTS\$1) (拡張された変更および転送システム (CTS\$1))](https://support.sap.com/en/tools/software-logistics-tools/enhanced-change-and-transport-system.html)
+ SAP ドキュメント: [Deploying Applications to BTP (BTP へのアプリケーションのデプロイ)](https://help.sap.com/viewer/825270ffffe74d9f988a0f0066ad59f0/LATEST/en-US/4478283a220b46d9a46bb28d6a9140e8.html)
# ベストプラクティス 2.4 – 複数の環境を使用する
複数の SAP 環境を使用して、ワークロードの実験、開発、テストを行います。環境が本稼働環境に近づくにつれて増加するコントロールレベルを使用して、デプロイ時にワークロードが意図したとおりに運用するように確信を強化します。通常、SAP 環境には、開発、テスト、製造の 3 層環境が最小要件です。
**提案 2.4.1 - 実験に一時的な環境を使用する**
テクノロジーテストおよびデベロッパーチームに、実験とリスクの軽減を有効にするための最小のコントロールを備えた、サンドボックスまたは一時的な環境を提供します。
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
+ SAP on AWS ブログ: [Infrastructure as Code Example: Terraform and SAP on AWS (Infrastructure as Code の例: Terraform と SAP on AWS)](https://aws.amazon.com/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/)
**提案 2.4.2 - 並行して作業し、俊敏性を向上させられるように開発環境を整備する**
並行作業ができるように非本番稼働環境を提供し、開発とテストの俊敏性を高めます。開発者が必要なイノベーションの手段を利用できるように、本番に近い環境でより厳格なコントロールを実装します。通常、SAP 環境には、開発、テスト、本番稼働の 3 層環境が最小要件です。
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
**提案 2.4.3 - リリース品質を向上させるため、できる限り本番稼働を再現する統合テスト環境を整備する**
テストとステージング環境では、本番稼働環境のインターフェイス、セキュリティ、回復性、パフォーマンスの特性をできる限り忠実にミラーリングして、リリースする前にアーキテクチャとコードインタラクションの問題を特定する必要があります。この環境のコスト効率を向上させるために使用されていない場合、クラスターのセカンダリリソースをシャットダウンすることまたは環境のアプリケーションサーバーのパフォーマンスを (水平的および垂直的に) スケールダウンすることを検討します。
+ SAP on AWS ブログ: [SAP システムの起動停止自動化を AWS Systems Manager で実現](https://aws.amazon.com/blogs/awsforsap/automate-start-or-stop-of-distributed-sap-hana-systems-using-aws-systems-manager/)
**提案 2.4.4 - Infrastructure as Code (IaC) と設定管理システムを使用して一貫性のある環境をデプロイする**
Infrastructure as Code (IaC) を使用したり、構成管理システムを使用したりして本番環境に存在するコントロールに準拠して設定された環境をデプロイし、システムがデプロイ時に予想どおりに動作することを確認します。タグ付けとリソースグループを使用して環境メタデータにラベル付けを行い強化し、オートメーションとコンプライアンスの目的に使用できるようにします。
+ SAP on AWS ブログ: [Infrastructure as Code Example: Terraform and SAP on AWS (Infrastructure as Code の例: Terraform と SAP on AWS)](https://aws.amazon.com/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/)
+ SAP on AWS ブログ: [Tagging Recommendations for SAP on AWS (SAP on AWS のタグ付けレコメンデーション)](https://aws.amazon.com/blogs/awsforsap/tagging-recommendations-for-sap-on-aws/)
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
+ AWS ドキュメント: [AWS リソースグループとは何ですか。](https://docs.aws.amazon.com/ARG/latest/userguide/welcome.html)
**提案 2.4.5 - 使用していないときは非本番稼働環境をオフにする**
環境を使用しない場合は、オフにして、アイドル状態のリソース (夜間や週末の開発システムなど) に関連するコストを避けることができます。
+ SAP on AWS ブログ: [SAP システムの起動停止自動化を AWS Systems Manager で実現](https://aws.amazon.com/blogs/awsforsap/automate-start-or-stop-of-distributed-sap-hana-systems-using-aws-systems-manager/)
# ベストプラクティス 2.5 – 変更をテストし、検証する
すべてのライフサイクルステージ (開発、テスト、本番環境など) で変更をテストし、その結果を検証してください。テスト結果を使用して、新機能を確認し、失敗したデプロイのリスクと影響を緩和します。テストと検証を自動化し、レビューの一貫性を確保し、手動プロセスによって発生するエラーとそれにかかる労力を減らすことができます。
**提案 2.5.1 - すべてのライフサイクルステージ (開発、テスト、本番環境など) で変更をテストし、その結果を検証する**
**提案 2.5.2 - 変更および主要なプロジェクトをリリースするときに比較するための、機能テスト、パフォーマンス、回復性にまたがるテスト結果のベースラインを維持する**
**提案 2.5.3 - 異なるレベルの変更にどのレベルのテストが必要かを理解する。例えば、フルスイートのテストとマイナーな更新のための対象を絞った回帰テスト。テストの定義と、本番稼働にリリースするためにテストが必要な変更の範囲について合意する。**
**提案 2.5.4. - サードパーティー製ツールとテストハーネスにより可能な箇所でテストを自動化する。まずは定期的な変更タイプと頻繁なリリースに重点を置く。**
# ベストプラクティス 2.6 – 小規模かつ可逆的な変更を頻繁に行う
頻繁に、小さく、可逆的な変更を行うことで、変更の範囲と影響を減らします。多数の SAP NetWeaver ソリューションは、「パッチフォワード」アプローチのみをサポートしますが、ロールバックを可能にするカスタム開発での機能トグルの使用を検討します。これにより、トラブルシューティングが容易になり、修復がすばやくできるようになります。また変更を元に戻すこともできます。
**提案 2.6.1 - 可能な場合、開発とリリースを頻繁かつ小規模な変更に分割する**
**提案 2.6.2 - 多数の SAP ソリューションは、「パッチフォワード」アプローチのみをサポートする (そして可逆的転送を許可しない) ため、カスタム開発で機能トグルを使用して、ロールバック/撤回ではなく機能の無効化を許可する**
**提案 2.6.3 - 不可逆的な SAP の変更については、システム全体のスナップショット、データベースのバックアップ、復元オプションなど、ロールバックオプションの追加を検討する**
+ AWS ドキュメント: [Amazon EBS クラッシュコンシステントスナップショット](https://aws.amazon.com/blogs/storage/taking-crash-consistent-snapshots-across-multiple-amazon-ebs-volumes-on-an-amazon-ec2-instance/)
+ AWS ドキュメント: [AWS Backint for SAP HANA](https://aws.amazon.com/backint-agent/)
# ベストプラクティス 2.7 – 変更のテスト、統合、デプロイを自動化する
ワークロードのビルド、デプロイ、テストを自動化します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力を減らすことができます。
**提案 2.7.1 - 構築、テスト、デプロイ、検証を通じたコードのチェックインから統合とデプロイのパイプラインを完全自動化する**
**提案 2.7.2 - アプリケーション変更のデプロイパイプラインにエンドツーエンドの構築をオーケストレートするために SAP Solution Manager ChaRM、Focused Build またはサードパーティー製の変更・リリース管理ツールを実装する**
+ SAP ドキュメント: [SAP Solution Manager Change Request Management (SAP Solution Manager 変更リクエストの管理)](https://help.sap.com/viewer/8b923a2175be4939816f0981b73856c7/LATEST/en-US/4c3acb82b50843b4e10000000a42189e.html)
+ SAP ドキュメント: [SAP Focused Build](https://support.sap.com/en/alm/focused-build.html)
+ AWS Marketplace: [DevOps 向け製品とツール](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=sap&category=45c68cc2-ccd6-426b-94bd-92a791004dc2)
+ AWS Marketplace - [テスト用の製品とツール](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=sap&category=b1cf3403-729a-4df1-908d-51105b3574a3)
+ SAP on AWS ブログ: [SAP 用の AWS DevOps ツール、パート 1: Cloud Foundry アプリケーション](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-1-cloud-foundry-apps/)