著者紹介
Gurpreet Bhadesh
Gurpreet Bhadesh
connect
Thomas Goldberger
Thomas Goldberger
connect

マイクロソフトのPower Platformのようなローコードプラットフォームは、イノベーションのルールを塗り替え、市民開発者により速いペースでアプリを構築する力を与えている。しかし、スピードには、コードの品質、シームレスな更新、効率的なデプロイメントを管理するという課題が伴う。そこでCI/CDの出番だ。CI/CDは従来のソフトウェア・デリバリに革命をもたらし、今ではローコード・クリエイターのための信頼性、スケーラビリティ、スピードの新しいレベルを解き放ちつつある。CI/CDがPower Platformをどのように変えるか、お分かりいただけましたか?さあ、飛び込んで、合理化された開発の未来を明らかにしましょう。

Thomas Goldberger Gurpreet Bhadesh が、Power Platform 開発における CI/CD
について、「Let's Talk DevOps」ビデオトークショーで探ります!

CI/CDとは?

CI/CDとは、Continuous Integration(CI)とContinuous Delivery/Deployment(CD)の略です。CI/CDは、ソフトウェア開発における統合、テスト、バージョン管理、ビルド、デプロイ、品質管理を自動化します。よりスムーズなワークフロー、より迅速な問題解決、より高品質なアプリケーションを実現する。これに加えて、手作業による介入の必要性がなくなるため、ユーザーからのフィードバックをより頻繁に、より速いペースで取り入れることができ、エンドユーザーや顧客が満足することが保証される。CI/CDは伝統的に開発者向けでしたが、ローコードプラットフォームの採用が増加していることから、CI/CDはローコード領域でますます重要性を増しています。

CI/CDはどのように機能するのか?

CI/CDのCIとは、継続的インテグレーションのことで、開発者がコードの変更を共有リポジトリに頻繁にマージできるようにするプロセスのことである。これらの更新が行われるたびに、コミットされたコードが信頼できるものであることを確認するための自動テストステップが起動する。

CIが成功すれば、開発者のアプリケーションへの変更がマージされ、アプリケーションのビルドを通じて自動的に検証され、変更がアプリを壊していないことを確認するために、さまざまなレベルの自動テストが実行できるようになる。典型的なテストには、単体テスト、統合テストがあり、この利点は、新しいコードと既存のコードとの間のコンフリクトの発見を通じて実現され、バグ修正を迅速なペースで提供することを可能にする。これに加えて、SonarQubeなどのツールを使用した静的コード解析も、コードの品質を検査しバグを検出するために利用される。このような低レベルのテストが実行時間5分を超えないようにすることが重要であり、これにより高速なフィードバック・ループが実現する。

CI/CDのCDとは、継続的デリバリーと継続的デプロイメントのことである。この2つの用語は同じ意味で使われるが、自動化がどれだけ進んでいるかを示すために別々に使われることもある。CIは、すべてのコード変更をテスト環境にデプロイし、後のステップで安定した品質保証された成果物を利用できるようにするため、継続的デリバリー/デプロイの前提条件となる。

継続的デリバリーは、継続的インテグレーションの延長と解釈することができる。ビルドステージの後に、すべてのコード変更をテスト環境またはプリプロダクション環境にデプロイするからだ。

継続的デプロイは、継続的デリバリーの上に構築され、プロダクションパイプラインのすべてのステージ(プロダクションパイプラインのすべてのステージを通過していることが条件)を自動的に顧客にリリースする。最終的に、継続的デリバリーと継続的デプロイのどちらを選択するかは、開発チームと運用チームのリスク許容度とニーズにかかっている。

成熟したCI/CDパイプラインの最終段階は、継続的デプロイである。これは、開発者の変更をリポジトリから本番環境に自動的にリリースし、顧客がそれを使用できるようにすることを指す。これにより、より迅速なフィードバックループが保証され、デプロイメントプロセスのリスクも軽減される。

CI/CD implementation.図1 - CI/CDとは?

なぜCI/CDが重要なのか?

CI/CDは当初、市民開発者にとって複雑さを増すように見えるかもしれませんが、新機能や迅速なバグ修正に対応するスケーラブルで自動化された開発フレームワークを提供します。時間をかけて、このプロセスは、開発者が継続的なフィードバックとテストによりリスクを低減しながら、より自信を持って効率的に作業することを可能にします。さらに、C-Suiteの利害関係者は、市場投入までの時間の短縮、イノベーションの実現、リスクの軽減といった高レベルの利益を得ることができる。

このように、開発者がワークフロー、品質、コラボレーションの改善を通じて利益を享受する一方で、C-suite のステークホルダーは、イノベーションの迅速化、コスト削減、ビジネスゴールとの整合性といった戦略的なメリットを得ることができます。どちらのグループも Power Platform CI/CD から利益を得ますが、それぞれの役割と優先順位に合わせた、明確に異なる方法で利益を得ます。

Power Platform で利用可能な CI/CD オプションは何ですか?

CI/CD はほとんどのソフトウェアデリバリオプションでは一般的かもしれませんが、Power Platform のようなローコードプラットフォームでは稀です。CI/CDが提供する利点を考慮すると、Power Platformもこれらを活用すべきだと考えます。このブログポストシリーズでは、以下の2つのCI/CDオプションを紹介します:

  • Power Platformのパイプライン
  • Azure DevOpsのためのMicrosoft Power Platformビルドツール

まず、Power Platformのパイプラインについて説明します。

Power Platformのパイプライン

Power Platformは常に「ビルドはプロッドで」という考え方を持っていましたが、時代とともにソリューションが導入され、最近ではパイプラインが導入されました。Power Platformのパイプラインは、ALMの自動化とCI/CDの機能をサービスに提供することで、アプリケーションライフサイクル管理(ALM)を実現することを目的としている。

Power Platformアプローチにおけるパイプラインの前提条件

  • 1つ以上のパイプラインが作成され、開発に使用された環境に関連付けられていること。
  • 開発環境にはMicrosoft Dataverseが必要です。
  • 開発者がパイプラインを実行するアクセス権を持っていること
  • ソリューションをターゲット環境にインポートするには、昇格した権限が必要です。
  • パイプラインホスト環境にPower Platform pipelinesアプリケーションがインストールされている必要があります。

Power Platformのパイプラインはどのように機能するのか?

非常にシンプルで使いやすいですが、その分機能が制限されます。Power Platformアプローチのパイプラインは、管理されていないソリューションを管理されたソリューションとして別の環境に移動するだけです。そのため、さらに改善や変更を加えたい場合、マネージド・ソリューションでは不可能です。ソリューションのバージョン管理はZIPファイルとして保存されます。つまり、テストの自動化、複雑なブランチ、別の環境にプッシュする前の管理者の承認などを追加したい場合、これは不可能ということです。

Pipelines in Power Platform

Power Platformのパイプライン

上の画像からわかるように、アップデートはボタンをクリックするだけで完了し、メンテナンスは最小限です。

Power Platformにおけるパイプラインの限界

Power Platformのパイプラインは一見シンプルで使いやすいように見えますが、その機能には限界があります。第一の制限は、機能がマネージド環境にしか適用されないことです。そのため、パイプラインを使用する前に、管理対象外のソリューション・パッケージを管理対象ソリューションに変更する必要がある。第二に、環境を以前にインストールしたバージョンにリストアする機能がない。第三に、リリース・パイプラインはバージョン・コントロールに接続できないため、ソリューション・パッケージをマネージド・ソリューションにする必要があり、それ以上変更が加えられないようにする必要がある。最後に、リリースプロセスに自作のワークフローを追加する機能はありません(例えば、テスターからの承認レシート、そして本番環境への自動リリース)。

結論

まとめると、Power Platform のパイプラインは、CI/CD 機能をローコード環境に導入するための重要なエントリーポイントを提供し、市民開発者がデプロイメントを簡単かつ効率的に管理できるようにします。手作業によるソリューションのインポートとエクスポートの必要性を減らすことで、これらのパイプラインは本番環境への変更のプッシュを容易にします。この利用しやすいアプローチにより、非技術系ユーザーもアプリケーション・ライフサイクル管理に参加できるようになり、より迅速なフィードバック・ループと迅速な機能展開が促進されます。しかし、より複雑な組織のニーズに対しては、バージョン管理統合、ロールバックオプション、承認ワークフローの欠如など、Power Platform のパイプラインには限界があるため、組織は追加のツールや高度な構成を求める必要があるかもしれません。

ローコードの採用が進み、アプリケーションがビジネスオペレーションにますます不可欠になるにつれて、Power Platform 内のより堅牢な CI/CD ソリューションへの需要は高まるでしょう。Power Platform のパイプラインの今後の拡張と ALM Accelerator のようなツールの追加は、プラットフォーム上でより洗練された ALM プロセスをサポートするという Microsoft のコミットメントを示すものです。これらの進歩は、現在のギャップに対処し、より広範な開発シナリオを可能にし、市民開発者と企業チームの両方が、より高い信頼性とスケーラビリティでアプリケーションを構築、デプロイ、および保守できるようにすることを約束します。

このブログポストの次のパートでは、Azure DevOpsのためのMicrosoft Power Platform Build Toolsと、Power Platformパイプラインの欠点にどのように対処できるかを探ります。

2025年5月22日にミュンヘンで開催されるInternational Software Quality Daysで 、当社のDevOpsエキスパートであるThomasとGurpreetが、ローコード/ノーコード開発のためのCI/CDを深く掘り下げて解説します!

著者紹介
Gurpreet Bhadesh
Gurpreet Bhadesh
connect
Thomas Goldberger
Thomas Goldberger
connect
このページはAI翻訳を使用しています。人間の助けが必要ですか? ご相談ください