企業組織は、高品質で安全かつ将来性のあるアプリケーションを求めています。多くの企業組織が苦労しているのは、必要なツールが不足しているからではありません。実際、ソフトウェアの品質向上、セキュリティリスクの特定、標準の遵守、展開リスクの低減を目的としたプラットフォームに既に投資しています。彼らの課題は、これらのツールが展開プロセス自体とは切り離されていることが多い点です。開発者はリリースフローから離れ、手動でスキャンを実行し、結果を待ち、システムを切り替え、アプリケーションを次の環境に進めるかどうかを決定する必要があります。これらの作業は重要ですが、パイプラインの外で行われるため、遅延、一貫性の欠如、単純な人的ミスが発生しやすくなります。展開の決定が別の場所で行われる情報に依存する場合、組織は必要な手順を毎回確実に記憶し実行する人に頼らざるを得ません。

組織が成熟するにつれて、これは特に困難になります。品質チェックはより高度化し、セキュリティ要件は増加し、ガバナンス基準は拡大します。チームはこれらの責任を管理するために追加のツールを導入します。各ツールは貴重な洞察を提供できますが、リリースプロセス全体は断片化されがちです。ソフトウェアをデプロイするかどうかを判断するために必要な情報は、デプロイの決定が行われる場所では入手できなくなります。その代わりに、デプロイプロセスは、複数のシステムに分散した電話、メール、ダッシュボード、承認要求、スキャン、レポートによって中断されます。

POSTリクエストとGETリクエストの紹介

POST および GET リクエストは、この不整合に対処するためにパイプライン設計で構成できる新しいパイプライン ステップです。 Mendix ソフトウェアリリースプロセスの一環として、外部システムやツールと直接連携するパイプラインを構築できます。チームがパイプラインから離れて別の場所で作業を行い、結果を手動で解釈するのではなく、これらの作業を自動的にトリガーして検証することが可能になります。その結果、一貫性とガバナンスへの準拠が大幅に向上します。品質、セキュリティ、その他のプロセスは、デプロイメントが実行されるたびに会社のプロトコルに従って実行され、リリース決定に必要な情報を必要なときに取得できます。

Menditect Test Automation (MTA) を起動してアプリケーションをテストする

一般的な例として、自動テストが挙げられます。多くの組織は、リリースプロセスでアプリケーションをさらに進める前に、アプリケーションの動作を検証したいと考えています。Menditect は、自動化に使用されるプラットフォームの代表的な例です。 Mendix アプリケーションテストを実施し、ソフトウェアが期待どおりに動作することを確信できるようにします。このような統合を行う前は、 Mendix パイプラインでは、テスト実行を個別にトリガーし、外部で進捗状況を監視し、デプロイメントを続行できるかどうかを判断する前に結果を手動で確認する必要がある場合が多かった。このプロセスは機能するものの、組織が標準化をますます望んでいるワークフローに、余分な手動調整作業が加わることになる。

POSTおよびGETリクエストでは、 Mendix パイプラインは、そのテストフローの一部になり得ます。パイプラインは、Menditectのテスト実行をトリガーし、結果を取得し、その情報をより広範なリリースプロセスの一部として使用できます。チームは、テストをデプロイメントワークフローとは切り離されたアクティビティとして扱う必要がなくなります。代わりに、テストはデプロイメントの意思決定時に利用できる情報の一つになります。その価値は、テストが環境やリリースを問わず一貫して実行できる反復可能なプロセスの一部として実行されることです。このシナリオを実装しようとしている組織は、 Menditect固有の実装詳細およびAPI構成ガイダンスに関するドキュメント.

品質・セキュリティマネージャー（QSM）を使用してアプリケーションをスキャンする

2つ目の例は、Software Improvement Groupの品質・セキュリティ管理プラットフォーム（QSM）です。組織はQSMを利用して、アプリケーションの品質、保守性、セキュリティ特性に関する知見を得ます。これらの知見は、ソフトウェアが組織の標準や品質目標に合致しているかどうかをチームが理解するのに役立ちます。従来、こうした情報は独立した情報源として存在し、リリース計画時や本番環境への展開前に参照する必要がありました。

QSMを接続することで Mendix パイプラインを活用することで、組織は品質情報とセキュリティ情報をリリースプロセスにより近い段階で利用できるようになります。デプロイメントワークフローは、必要なアクティビティを開始し、結果として得られる評価を取得し、ソフトウェアのリリースを進めるかどうかを判断する際にその情報を組み込むことができます。品質に関する問題がリリース決定後に発見されるのではなく、意思決定プロセスの一部となるのです。これにより、組織はレポートの手動レビューから、より予測可能で再現性の高いリリースプロトコルの確立へと移行できます。

接続するためのツールがさらにたくさんあります

品質とセキュリティは最も一般的なシナリオですが、可能性はそれだけにとどまりません。一部の組織は、トレーサビリティと監査のために、構成管理データベースにデプロイメントを登録したいと考えています。また、デプロイメントの成功または失敗をMicrosoft TeamsやSlackを通じて運用チームに通知したいと考えている組織もあります。ソフトウェアの実行可否を判断するために、承認システム、変更管理プラットフォーム、ガバナンスソリューション、リスク管理プロセス、または社内開発サービスに依存している組織もあります。場合によっては、チームは本番稼働前にビジネス固有の条件を検証することさえあります。共通しているのは、重要なリリース情報が多くの場合、外部に存在するということです。 Mendix パイプライン。POSTおよびGET呼び出しは、組織が既に信頼し依存しているツールを放棄することなく、これらのシステムをリリースプロセスに接続する方法を提供します。

より広範な成果としては、ガバナンスの向上が挙げられます。ガバナンスは、ポリシー、コントロール、コンプライアンス要件と関連付けられることが多いですが、実際には一貫性が重要になります。組織がプロセスを定義するのは、予測可能な結果を​​得たいからです。品質チェックが毎回実行されること、セキュリティ検証が毎回実施されること、そして展開の決定が憶測ではなく事実に基づいて行われることを望んでいます。外部システムをデプロイメントワークフローに近づけることで、組織は手動による調整への依存を減らし、重要なリリース活動が確立された標準に従って行われるという確信を高めることができます。その結果、標準化しやすく、監査しやすく、大規模運用しやすいリリースプロセスが実現します。

今すぐ始めてみましょう

POSTおよびGETリクエストは、外部システムとの接続を開始したい組織向けに今日から利用可能です。 Mendix パイプライン。目標が Menditect による自動テスト、QSM によるアプリケーション品質の洞察、ガバナンス プロセス、リリース通知、組織固有の統合、またはちょっとした実験であっても、この機能は外部情報をデプロイメントの意思決定に取り込むための実用的な出発点となります。詳細については、 Mendix POSTおよびGETリクエストに関するドキュメント パイプラインの設計構成を正しく行うため。

今後を見据えると、これはより広範なオーケストレーションの道のりの第一歩に過ぎません。単一のパイプライン内で追加のPOSTリクエストやGETリクエストをサポートするなど、将来的な機能強化により、組織は複数のシステムを連携させ、ますます高度化する品質、セキュリティ、ガバナンス、リリース管理のシナリオに対応できるようになります。