Skip to main content

 

 

DevOps

 

 

OutSystems

OutSystemsによる継続的デリバリーパイプラインの構築

継続的デリバリーとは、いつでも必要なときに安全に本番にリリースできるアプリケーションを開発するという原則です。これを実現するには、オペレータの作業を最小限に抑えながら、アプリケーションに対して行う変更の影響を(本番準備の観点から)すばやく評価することができ、アプリケーションを迅速に本番にデプロイすることができるデプロイパイプラインが必要です。

OutSystemsが提供するoutsystems-pipelineは、LifeTimeのビルトイン機能を拡張できるオープンソースのアクセラレータです。アプリケーションや環境の操作権限の管理やビルトインの影響分析を実行でき、環境全体の複雑なアプリケーションポートフォリオのデプロイを簡単かつ適切に行うことができます。このアクセラレータには、LifeTime API上で作成されたPythonスクリプト、パイプラインテンプレート、ドキュメントが含まれており、CI/CDプラットフォームとの連携を簡素化できます。OutSystemsはコミュニティの協力を受け、outsystems-pipelineの改良と強化を近日中に行います。このアクセラレータにより、以下の点を実現します。

  • リリースマネージャーは、完全に自動化されたパイプラインにより、人的ミスやリードタイムを減らすことができます。
  • 開発者は、変更のたびに行われる迅速なフィードバックループにより、高品質なソフトウェアを作成することができます。

以下の図は、5つの異なる環境で構成される継続的デリバリーパイプラインの例です。

OutSystemsの継続的デリバリーパイプライン

以下のセクションでは、推奨されるOutSystemsのパイプラインを段階ごとに詳細に説明しています。また、以下のガイドでは、例としてoutsystems-pipelineアクセラレータと代表的な2つのCI/CDプラットフォームを使用してパイプラインを構築する手順を説明しています。

開発

Development(DEV)は、OutSystemsアプリケーションの開発を行うメイン環境です。開発者は、新機能や変更要求の開発が完了すると、1つまたは複数のLifeTimeアプリケーションにタグ付けし、変更に基づいたわかりやすいバージョン番号と説明をそれぞれに付けて、リリース候補版を作成することができます。

LifeTimeでアプリケーションにタグ付けすると、パイプラインによる検証の対象となる変更のスコープを定義することになります。この作業はコミットステージと呼ばれる場合もあり、継続的デリバリーパイプラインの実行のトリガーになります。

回帰テスト

コミットステージの後、新しく作成されたLifeTimeのタグがRegression(REG)環境に自動的にデプロイされます。この環境では、自動回帰テストスイートが実行され、アプリケーションの最新コードバージョンのデプロイ可否が評価されます。この回帰テストスイートには開発フェーズで以前に記述された単体テストが含まれ、UIテスト(重要なエンドユーザーフローの場合)やコード分析の手順などの要素が含まれる場合もあります。

ローコード開発インフラで継続的デリバリーを適切に実施するため、テストのしやすさを念頭に置いて開発を行うことを強く推奨します。このため、開発に関するベストプラクティス(4-Layer Canvasなど)を遵守してアーキテクチャ内でビジネスコンセプトを適切に分離することに加え、開発者が開発作業の一環として単体テストを作成するようにしてください。

提案されている方法では、自動回帰テストの段階でBDD Framework Forgeコンポーネントを使用して記述された単体テストを利用します。このフレームワークによるテストの記述方法の詳細については、こちらの記事をご覧ください。また、ベストプラクティスとして、単体テストのコードがアプリケーションコードと一緒に本番環境にデプロイされることを防ぐため、単体テストのコードを別のLifeTimeアプリケーションに分離することも検討してください。

受け入れテスト

REGで回帰テストスイートが正常に実行された場合、リリース候補版がAcceptance(ACC)環境に自動的にデプロイされます。この環境でビジネス部門の代表者による承認を待ちます。その間、通常のローコード開発インフラのQuality Assurance環境と同じように、この環境でリリース候補版の手動テストや探索的テストを行うことができます。

本番前および本番

リリース候補版がビジネス部門の代表者により承認されたら、権限を持つユーザーが「押しボタン」方式でProduction(PRD)環境へのデプロイをトリガーします。つまり、(文字どおり)ボタンを押すとリリース候補版を本番環境にデプロイするために必要なアクションがすべて実行され、デプロイパイプラインを正常に完了することができます。

たとえば、新しいリリース候補版の自動回帰テストを行わずに承認段階に進んだり、本番環境に似た環境でのリハーサルを行わずに変更を本番環境にデプロイしたりするなど、提案より少ない環境数でデプロイパイプラインを構成することは技術的には可能ですが、その場合、デリバリープロセスに関連するリスクが高くなることに留意してください。

  • Was this article helpful?