整理されたクリーンな開発環境のベストプラクティス

モジュールバージョン

モジュールバージョンの管理は、アプリケーション開発の複数のタスク（モジュールを開く、参照の追加/削除、パブリッシュ）に影響を及ぼすため、最も関連性が高いアクションの1つです。

モジュールをパブリッシュするたびに、環境に新しいバージョンが作成されます。バージョンは、前の開発段階にロールバックする必要があるときに特に便利です。 しかし、アプリケーションは拡張し続けるため、パブリッシュを頻繁に行っているとすぐに数百または数千のバージョンができ、日常の開発タスクで速度の低下を感じ始めることがあります。

そのため、Development環境で不要になった古いモジュールバージョンを定期的にクリーンアップすることが重要です。古いモジュールバージョンを削除するには、Service Centerを使用して直接削除する方法と、データベース領域を解放する機能を提供するDbCleaner APIを使用する方法があります。

1. Service Center（https://<ご利用の環境>/ServiceCenter）に移動します
2. ［Factory］タブをクリックします
3. ［Modules］サブメニューオプションをクリックします。次に、［Check Old Module Versions to Delete］リンクをクリックします
4. 削除する期間を選択して、［Check Versions to Delete］ボタンをクリックします
5. モジュールバージョンのリストが表示されます（リストのレコード数は最大100件）
6. ［Delete Displayed Versions］をクリックして続行します

DbCleaner APIのアクションを使用して、より柔軟に古いモジュールをクリーンアップできる独自のソリューションを実装することもできます。

• ModuleVersion_ListOldest: データベース内に保存されている、指定された日時より前にパブリッシュされたモジュールバージョンのリストを返します。このアクションでは、現在パブリッシュされているモジュールバージョンと、アプリケーションまたはソリューションのタグ付けされたバージョンで使用されているモジュールバージョンは返されません。
• ModuleVersion_Delete: 指定されたモジュールの指定されたモジュールバージョンをデータベースから削除します。
• ModuleVersion_DeleteAll: 指定された日時より前にパブリッシュされたモジュールバージョンを削除します。このアクションでは、現在パブリッシュされているモジュールバージョンと、アプリケーションまたはソリューションのタグ付けされたバージョンで使用されているモジュールバージョンは削除されません。

ソリューションバージョン

ソリューションとは、環境内のモジュールのセットを集約したものです。作成したソリューションバージョンが不要になった場合は、Service Centerで削除できます。

1. Service Center（https://<ご利用の環境>/ServiceCenter）に移動します
2. ［Factory］タブをクリックします
3. ［Solutions］サブメニューオプションをクリックします
4. 特定のソリューションの詳細画面に移動します
5. ［Versions］タブで、削除するバージョンを選択します
6. ［Delete］ボタンをクリックして続行します

ソリューションバージョンを削除した後、「モジュールバージョン」セクションの説明に従って、そのバージョンに関連付けられたモジュールバージョンを削除することができます。

タグ付けされたアプリケーションバージョン

特定のタグ付けされたバージョンへのロールバックが不要であることが確実な場合、アプリケーションバージョンを削除することもできます。 LifeTime管理コンソール2019年2月リリース版以降、LifeTime Deployment API v2で「InUse」以外のアプリケーションバージョンを削除するためのメソッドが提供されています。

DELETE /lifetimeapi/rest/v2/applications/{ApplicationKey}/versions/{VersionKey}/

タグ付けされたアプリケーションバージョンを削除した後、「モジュールバージョン」セクションの説明に従って、そのバージョンに関連付けられたモジュールバージョンを削除することができます。

一時テストモジュール

チームでアプリケーションを開発しているときに、一時テストモジュールや概念実証（PoC）を作成する必要がある場合や、Forgeコンポーネントのデプロイやテストをよく行う場合があります。 これらのモジュールはどれも実装フェーズでは役立ちますが、すぐに使用しなくなり、開発環境で不要なコードになってしまいます。 ベストプラクティスでは、定期的な開発インフラ管理の一環として、これらのモジュールを環境から消去/削除します。アプリケーション全体または個別のモジュールを削除することができます。

1. Service Center（https://<ご利用の環境>/ServiceCenter）に移動します
2. ［Factory］タブをクリックします
3. ［Applications］サブメニューオプションをクリックします
4. 特定のアプリケーションの詳細画面に移動します
5. ［Delete］ボタンをクリックして続行します

1. Service Center（https://<ご利用の環境>/ServiceCenter）に移動します
2. ［Factory］タブをクリックします
3. ［Modules］サブメニューオプションをクリックします
4. 特定のモジュールの詳細画面に移動します
5. ［Delete Module］ボタンをクリックして続行します

アプリケーションデータ

アプリケーションデータは、基本的にアプリケーションのデータベースエンティティに保存されているすべての情報です。これには、単体テスト中に追加するデータのほか、データモデルの削除されたエンティティやアトリビュートが含まれます。

特に開発環境では、テスト/ダミーデータを保持しているのが一般的です。これは、開発者が開発中に行う様々な機能のテストの結果です。このデータは、アプリケーションを実行するうえでは重要ではありませんが、増加して不整合が生じる場合がよくあるため、定期的に消去することが有効です。 OutSystemsでは、これらの消去操作を実行する際にデータベースにアクセスする必要はありません。独自のデータ削除ロジックの実装の詳細については、「エンティティからのデータの削除」をご覧ください。

アプリケーションでエンティティやアトリビュートを削除しても、OutSystemsではデータベース内の対応するテーブルや列は削除されません。アプリケーションをロールバックするときに備え、データは安全に保存されます。エンティティやアトリビュートを使用する予定がない場合、ベストプラクティスではそれらを削除し、データベース領域を解放します。そのために、OutSystemsではDbCleaner APIメソッドが提供されています。

• Attribute_ListDeleted: モジュールのメタモデルからは削除されているものの、データベース内に物理的にまだ存在しているアトリビュートのリストとその情報を返します。
• Attribute_DropColumn: 指定されたエンティティアトリビュートに関連付けられたデータベーステーブルの列を物理的に削除します。エンティティアトリビュートがモジュールのメタモデル内にまだ存在している場合、削除操作は実行されません。
• Entity_ListDeleted: モジュールのメタモデルからは削除されているものの、データベース内に物理的にまだ存在しているエンティティのリストとその情報を返します。
• Entity_DropTable: 指定されたエンティティに関連付けられたデータベーステーブルを物理的に削除します。エンティティがモジュールのメタモデル内にまだ存在している場合、削除操作は実行されません。

プロセス

ビジネスプロセステクノロジー（BPT）プロセスがデータベース領域を無駄遣いしている場合もあります。開発中は、機能をテストするためにいくつかのプロセスを起動することが一般的です。 ログに記録された古いプロセスの情報をすべて消去するために、OutSystemsではBPT APIメソッドが提供されています。

• Process_Delete: 上位レベルのプロセスインスタンスのログ情報をすべて削除します。このプロセスインスタンスはターミネートまたは終了している必要があります。
• Process_BulkDelete: 指定された日付より前にターミネートまたは終了し上位レベルのプロセスのインスタンスのログ情報をすべて削除します。

これらを参照としてアプリケーションに追加し、それらを呼び出して古いインスタンスを削除します。

メール

プロセスと同様に、メールがデータベース領域を無駄に消費している場合もあります。メールは、時には1MBを超える巨大な添付ファイルを含まれることがあるため、特に関係があります。 メール情報を消去するために、OutSystemsではEmails APIが提供されています。これを使用すると、消去メカニズムを簡単に実装することができます。

ログ

ログ情報には、エンドユーザーまたは外部システムによるアプリケーションへのアクセスのライフサイクルが記録されます。以下に示す2種類のログがあります。

• 上位レベルのログ（Screen、Integration、Mobile Request、Cyclic Job）
• ドリルログ（Error、 General、Integration、Extension）

ログモデルは、アプリケーションの実行の妨げに極力ならないように設計されており、Development環境でもログのローテーションによって何らかの形で影響が制御されます（毎週、ログサービスがいずれかの週次テーブルを破棄してデータベースの領域を空け、そのテーブルを再利用する時期が来たら新しいログを挿入することができます）。

OutSystems 11以降ではログの削除アクションはサポートされていませんが、ログデータを別のデータベースに保存できます。これにより、アプリケーションデータにアクセスしている間のログ書き込み操作が実行中のアプリケーションに与える影響を減らすことができます。

その他の考慮事項

この記事では、Development環境のデータベース領域を使用する複数のコンポーネントを示し、データベース自体に直接アクセスすることなく不要なデータを消去できる方法について説明します。

これらのベストプラクティスは個別に適用することができ、制限はありませんが、オンプレミスインストールタイプの++++でも考慮する必要があり、今回限りの考慮事項ではないことに留意してください。