PowerBuilderのための継続的インテグレーション

1. ローカルでユニットテストを実行

ユニットテストは、手動で実行することもできますが、テスト駆動開発の手法に基づいて記述し、自動化することもできます。

開発者の変更をメインリリースに組み込む前に、開発者のローカル環境ですべてのユニットテストに合格する必要があります。これにより、作業中のコードが他の開発者のコピーを壊してしまうことを防げます。

2. 変更のコミットとビルドの生成

開発者は、変更内容をリポジトリに提出し、そのブランチのコードをメインバージョンにマージバックします。

ビルドサーバーは、定期的に、あるいはコミットごとにコードをコンパイルし、その結果を開発者に報告します。

PowerBuilder 2025および2025 R2では、新しい高性能コンパイラ（CloudProエディションおよびProfessionalエディション）と簡素化された自動化プロセスにより、継続的インテグレーションが強化されています。

最近のPowerBuilderには、このプロセスを簡略化するさまざまな機能があります。

コンパイルツール PBAutoBuild

PBAutoBuildは、PowerBuilder 2021から提供されている、PowerBuilderのスタンドアロンのコマンドラインビルドツールです。IDEの外でプロジェクトをコンパイル・配布できるため、CI/CDワークフローの入り口となります。ビルドマシンにはPowerBuilder IDEもPowerBuilderライセンスも不要で、必要なのはPowerBuilder UtilitiesとPowerBuilder Runtimeのみです（PowerServerプロジェクトの場合はPowerServer Toolkitも必要）。

PBAutoBuildでビルドできるもの：

• クライアント/サーバーアプリケーション
• PowerClientプロジェクト
• PowerServerプロジェクト

PowerBuilder 2025では、PowerBuilder Compiler（PBC）がPBAutoBuild250.exeに統合されています。既存のPBCスクリプトは、/pbcパラメーターを追加するだけで引き続き動作します。また、PBAutoBuildには「Deploy only」（配布のみ）オプションが追加されています。

PowerBuilder 2019、2017をお使いの方は、こちらの記事を参考に、従来のツール「PowerBuilder Compiler」の使い方をご確認ください。

ソース管理システムとの統合

PowerBuilderは、GIT、SVN、外部のSCC準拠ソース管理システムなどのソース管理とネイティブに統合できます。これにより、共通バージョンのコードを共有したり、CI/CDのためにコードを取得したりすることが簡単になります。

注：SCC APIとPBNativeは従来のworkspace形式でのみ動作します。PowerBuilder 2025で導入されたsolution形式は、GitとSVNに対応しています。

ORCAScript言語

ORCAScript言語は、人の手を介さずにソース管理操作を行い、PowerBuilderのライブラリ、ワークスペース、実行ファイルを構築することを目的としています。

ORCAScriptによるコンパイルはworkspace形式にのみ適用されます。solutionはPBAutoBuildでビルドします。

3. コードの検証

コード検証では、静的解析を用いてソースコードをあらかじめ定義されたルールと照合し、セキュリティ上の脆弱性、バグ、パフォーマンスの問題、品質上の問題を特定します。CI/CDワークフローでは、その結果をもとに、チームがコードの品質を評価し、ビルドを配布できる状態かどうかを判断します。

AIアシスタントによってコード開発が加速する中、コードの品質を確保することはこれまで以上に重要になっています。コードを開発者が書いたかAIが生成したかにかかわらず、すべての変更を検証する必要があります。自動化された検証により、コードベース全体に対して一貫した独立したチェックを行えます。

しかし、欠陥の検出は最初のステップにすぎません。コードの品質を向上させるには、継続的なプロセスが必要です。コードを検証し、検出結果を確認して優先順位を付け、修正案の影響を評価し、修正を行い、再度検証して解決を確認します。

ビルドごとにコードを検証

CI/CDワークフローでは、検証をビルドごとに自動実行し、アプリケーションコードとデータベースコードの両方を対象として、ビルドを配布できるかどうかの判断に役立つ結果を出す必要があります。

たとえば、Visual Expertを使用して、PowerBuilderとデータベースのコードを検証できます。

• GIT、SVN、Azure DevOps Server（旧TFS）、Windowsフォルダ、Oracle、SQL Serverからソースコードを解析。 
• セキュリティ脆弱性、バグ、コード品質やパフォーマンスの問題、デッドコードを検出。
• 各解析結果を欠陥ダッシュボードにまとめ、アクティブ、新規、重大、解決済みの欠陥と、前回の解析からの変化を表示。これらの指標により、ビルドがリリース基準を満たしているかを評価できます。
• 各欠陥を命令レベルで特定する詳細なコードレビューレポートを提供。

欠陥ダッシュボード：解析ごとの品質指標と推移

検出から解決までの欠陥管理

アプリケーションが大きくなるにつれて、1回の検証で数百件の検出結果が報告されることもあります。体系的なプロセスがなければ、これらの結果の優先順位付けは難しく、担当者も不明確になり、修正の進捗も把握しにくくなります。そのため、チームには次のような手段が必要です。

• 優先順位付け：重大度に基づいて、最初に対処すべき欠陥や脆弱性を特定する
• 判定：誤検知や許容するリスクにマークを付け、その判断を以降の解析でも保持する
• 割り当て：修正作業をチームメンバーに振り分ける
• 追跡：各欠陥を解決まで追跡し、リリース前に重大な問題がクローズされていることを確認する
• モニタリング：一連の解析を通じてコード全体の品質を測定し、改善しているかを確認する

Visual Expertは、一連の解析を通じて欠陥、判断、ステータス、担当者、履歴を保持することで、このプロセスを支援します。

修正前に影響を評価

PowerBuilderやデータベースのアプリケーションでは、1つのオブジェクト、プロシージャ、テーブルが多くの場所で使われていることがよくあります。何が依存しているかを把握せずに変更すると、別の場所に新たな欠陥を生む可能性があります。

修正を適用する前に、チームはその変更が何に影響するかを把握する必要があります。たとえば、Visual Expertの影響分析では、変更対象のコードに依存するオブジェクト、プロシージャ、テーブルが表示されるため、変更の範囲と、その後に必要なテストを定義するのに役立ちます。

AIを活用した修正

AIの支援によって修正を迅速化できますが、提案された変更はすべて開発者が確認し、再度検証することが前提です。

たとえば、Visual Expert AIでは、検証結果の欠陥に対してSuggest a Solution（解決策の提案）を使用できます。Visual Expertは修正済みのコードを、インラインコメントと変更内容の説明とともに提示し、開発者が修正案を確認できるようにします。主導権は開発者にあり、提案を確認し、必要に応じて調整したうえで適用します。

なじみのないコードの場合は、Explain the Logic（ロジックの説明）で、関数やプロシージャの処理内容の要約を得ることもできます。

解決の確認

修正は、検証されて初めて完了します。新たな解析によって欠陥が検出されなくなったことを確認し、そのステータスと履歴が更新されます。ビルドごとにこの継続的な検証を繰り返すことで、リグレッションを早期に発見し、未解決の欠陥の蓄積を防ぎ、コードの品質とセキュリティを長期にわたって維持できます。

4. ビルドのテスト - 継続的テスト

継続的インテグレーションの目的は、検証作業と配布可能なビルドの生成を自動化し、これらを可能な限り頻繁に行うことです。

テストはこのプロセスにおいて不可欠なステップであり、この目標を達成するためにはテストの自動化が必要です。各ビルドは徹底的にテストされ、自動的に生成された指標によって、ビルドが配布可能かどうかを評価できます。

テストの自動化は生産的か？

前世代のツールは、テストの作成やメンテナンスに手間がかかり、生産性の向上という目的を達成できないという評判がありました。

それらは多くの場合、2つの戦略に基づいていました。

• テストを指定するスクリプトの開発 - 開発コストがかかります。
• 画面上でのテスト操作の記録 - 作成は簡単ですが、GUIの変更に弱く、メンテナンスにもコストがかかります。

最新のツールでは、オブジェクト認識に基づく別のアプローチを提供しています。

• コードをスキャンしてオブジェクトを識別
• オブジェクトとアクションの種類（ボタンをクリックする、フィールドに値を入力する…）を選択して、テストアクションを定義します。スクリプトを書くよりもはるかに簡単で、コーディングのスキルは必要ありません。
• オブジェクトは安定しているため、テストはUIの変更に強くなります。メンテナンスコストも、記録型のツールに比べて格段に低くなります。

続きを読む

• オブジェクトベースのテスト VS 記録ベースのテスト
• 自動テストとアプリケーションライフサイクル管理

自動テスト VS 手動テスト

両者の戦略を重要なKPIで比較してみましょう。

	手動	自動
精度	❌	✓	手動テストは、人為的なミスが発生する可能性があるため、精度が低くなります。 自動テストは、一貫性と信頼性があります。
生産性	❌	✓	多数の手動テストを実行するには、時間とコストがかかります。自動テストの方が高速です。 何度繰り返しても追加コストはかかりません。
テストの開始	✓	❌	手動テストはすぐに実行を開始できます。 自動テストでは、テストとアクションを事前に定義するための準備時間が必要です。
柔軟性	✓	❌	手動テストはより柔軟です。ランダムにテストを行ったり、特定の領域でより深いテストをその場で行ったりできます。 自動テストではそうはいきません。

自動テストは大きなメリットをもたらしますが、手動テストを完全に代替することはできません。

最良の戦略は、次のような条件に応じて、2つのアプローチを賢く組み合わせることです。

• テストの性質と安定性 
• 自動テストの作成にかけられる時間 
• 継続的インテグレーション・ワークフローの有無
• ...

さらに詳しく：

• 自動テストと連動した手動テストの構築
• CI/CDワークフローでの継続的テスト

PowerBuilderのための自動テスト

AscentialTestを使って、PowerBuilderやPowerServerのアプリケーションのテストを自動化できます。

• バージョン管理システムSVNとの統合。
• 欠陥追跡システムJIRAとの統合。
• Azure DevOps（旧TFSであるAzure DevOps Serverを含む）やJenkinsなどのオートメーションサーバーからテストを実行するためのコマンドライン。
• Jenkins用AscentialTestプラグインと、Azure DevOps用パイプラインタスク拡張機能。

5. アプリケーションのローカライズ

最新のツールを使えば、CI/CDワークフローのさまざまなタスクを自動化できます。多言語対応もその1つです。

アプリケーションを複数の国で展開している場合、ユーザーにより良いサービスを提供するために翻訳を行っていることでしょう。本番稼働後も、一貫したユーザー体験を維持するために、翻訳を体系的に更新していく必要があります。