チームの連携
目次
OutSystemsで開発したアプリはモジュールで構成されているため、多くの開発者を抱えるファクトリーの場合でも、チームの連携が円滑になります。モジュール型システムでは、複数の開発者が1つのアプリに対して作業することもありますが、複数のモジュールで構成されていることから、多くの場合は各々別のモジュールの作業をします。一方で、必要に応じて複数のチームが連携して同じモジュールに取り組むこともできます。
モジュール型アーキテクチャ
OutSystemsでは、開発者がモジュール型のアプリケーションアーキテクチャを構築するため、個々の開発者が作業する領域を分離することができます。このような「マルチモジュールソリューション」は、開発者間や開発ライフサイクル間で発生する様々な衝突を未然に防ぎます。他の開発者の作業に影響を与えるかもしれないという心配をせず、複数の開発者が別々のモジュールの作業をすることが可能なのです。アプリケーションおよびモジュールのすべてのバージョンは、パブリッシュされるたびに中央リポジトリに自動的に保存されます。関係するアプリケーションおよびモジュールのマイルストーンをタグ付けしたり、変更者や変更日時のわかるバージョン履歴を確認したり、任意のバージョンへのロールバックを容易にダウンロードしたりすることができます。
大規模組織の複数のチーム
大規模な組織で複数のチームが連携して作業を行いつつ、開発サイクルにおける衝突も大幅に減らせるよう、OutSystemsは以下の手段を用いて、各開発者が異なるモジュールに対して同時に作業を行えるようにします。
分離
OutSystemsでは、モジュール型のアプリケーションアーキテクチャを作成します。そのため、特定のアプリケーション変更を行うために開発者が作業をする領域を分離することができます。
さらに、様々なコンポーネントを利用してアプリケーションポートフォリオの健全性を保つことができます。
デプロイ計画におけるITコラボレーション
複数のチームが、OutSystemsが実現する速いペースで開発を行い、本番環境に変更を反映させていく場合、異なるチームが日々変更を加えるという開発サイクルになる場合があります。
デプロイ計画を共有すると、各チームがアプリケーションを追加し、その変更のデプロイを1回のオペレーションで別環境に同期させることができるため、こうした複雑なデプロイシナリオにも対応できます。
デプロイオペレーションは、すべて権限レベルで管理されます。適切な権限を持ったユーザーであれば、アプリケーションを計画に追加することができます。ただし計画を実行するには、計画にあるすべてのアプリケーションの権限が必要になります。
複雑なデプロイシナリオ向けのステージング管理
ポートフォリオが拡大し、アプリケーションやモジュールの数が増大すると、当然、アプリケーションやモジュールの開発やオペレーションのライフサイクルも変化してきます。ポートフォリオに何百ものアプリケーションやモジュールがある場合、アプリケーションやモジュールのどのバージョンを本番環境に移行するかについて、より具体的な管理が必要になってきます。さらに、デプロイの影響や所要時間を完全に把握することがとても重要になります。
OutSystemsでは、デプロイオペレーションをきめ細く管理できます。通常は、アプリケーションのバージョン全体をクリック1回で次の環境にパブリッシュします。しかし、移行するモジュールを個別に選択することも可能です。これにより、アプリ全体をデプロイするのではなく、小さなホットフィックスを実装することができます。さらにデプロイ計画を検証して、すべての依存関係に問題がなく、アプリの整合性が保たれるかの確認も行われます。
分散型ユーザー管理
OutSystemsでは、各ユーザーが1つのチームにつき1つのロールを持つことができます。そのロールは、そのチームに関連付けられているすべてのアプリケーションに自動で適用されます。チームに対するユーザーやアプリケーションの追加や削除も簡単です。
チームの管理は各チームの管理者に任せつつ、中央管理者が全体を管理するという分散型開発モデルをサポートするために、チームマネージャーやアプリケーションマネージャーという概念があります。あるアプリケーションでこうした権限を持つユーザーは、そのアプリケーションについて他のユーザーに付与する権限を管理することができます。
同様に、あるチームに対する権限を持っているユーザーは、管理者を介することなく、他のユーザーをそのチームに追加・削除することができます。
運用監査
システム運営者が問題のトラブルシューティングをしたり、システム利用状態を追跡したり、ユーザーのアクションを記録したり、悪意ある活動の調査に有益な状況を提供したりできるよう、企業がシステムやネットワークで発生した様々なイベントに関する情報を保存することは多いものです。
OutSystemsは、ユーザー管理、ロール管理、チーム管理、インフラ管理、アプリケーションライフサイクルオペレーションなど、インフラの状態を変化させるあらゆるアクティビティのログを作成します。このロギングは、ユーザー、ロール、チーム、アプリケーション、環境、インフラなどの上位オブジェクトすべてについて行われ、どのオペレーションを誰がどのオブジェクトに対していつ行ったかを特定する役に立ちます。
アプリの標準化とブートストラップに役立つスターターテンプレート
OutSystemsが提供する一連のテンプレートを使用すると、どのチームメンバーでも同じルックやウィジェット群を持つ新規アプリケーションを作成することができます。アプリをサービスやAPI参照の初期セットにブートストラップすると、アプリ外観の全体的な一貫性を実現できるだけでなく、企業の標準アーキテクチャへの準拠にも役立ちます。
OutSystems Forgeでテンプレートを入手したり共有したりすることで、OutSystemsコミュニティの仲間と互助関係を築くこともできます。
大規模なチームの連携に関する詳細な情報
大規模なチームの連携を可能にする各種機能の詳細については、こちらの記事をご覧ください。
同一モジュールにおけるチームの連携
複数の開発者が同一モジュールで作業することを想定し、OutSystemsは開発者間での継続的統合開発サイクルの実現に必要なあらゆる機能を備えています。
開発者は、複数のステージング環境のバージョン、リリース、デプロイ、およびコンポーネントすべての依存関係を中央コンソールで管理することができます。構成管理、ビルド管理そしてバージョン管理のために複雑なツール類をインストールする必要も、それらのセットアップにあたり専門家の助けを借りる必要もありません。
各環境のバージョンを容易に確認でき、1回のクリックでアプリケーションのバージョンを自動的にデプロイしたりロールバックしたりできます。
比較とマージ
OutSystemsの開発環境では、同一のモジュールに対して作業を行っている複数の開発者が、各自の作業内容をマージすることもできます。デフォルトではOutSystemsが差分を自動的にマージしますが、開発者が比較を行い、どれをマージするかを手動で決定してからパブリッシュするという選択肢もあります。
次の画像は、パブリッシュの前に作業内容を比較・マージする状況を示したものです。
状況は、以下のとおりです。ある開発者が、モジュールのバージョン4を自らの開発環境で開いて開発を始めました。一方、2人目の開発者もバージョン4の開発を開始しました。両者が自分の行った変更をパブリッシュします。この時点で、
- OutSystemsは、両者が開発の起点としたバージョン（バージョン4）に基づいて、統合すべき変更を判別します。
- 変更されたバージョンが検出され、最後にパブリッシュを行った開発者が比較とマージをすることができます。
- 2人目の開発者が比較を行い、マージすべき変更をチェックします。
- その後、マージしてパブリッシュします。
この画面は、開発者が2つの異なるバージョンを比較する場合の視覚的マージを示したものです。
衝突の解決
複数の開発者が同一モジュールに対して作業を行って同じ要素を変更した場合、OutSystemsは、衝突があればそれを指摘し、どちらの変更をマージしてパブリッシュすべきか選択肢を提示することにより衝突の解決を促します。
次の画像は、開発中に衝突が発生した場合を示したものです。
このケースでは、ある開発者が自らの開発環境でモジュールのバージョン4を開き（1）、開発作業をしています。同時に2人目の開発者が自分の開発環境でバージョン4を開き（2）、開発を行っています。その後、1人目の開発者は変更をバージョン4としてパブリッシュしました。一方、2人目の開発者は自分の変更をバージョン5としてパブリッシュしました（3）。このシナリオでは、
- OutSystemsがバージョン4とバージョン5の間でマージすべき変更があると判定します。
- 2人目の開発者は比較とマージを行い、衝突している変更のうちどちらを残すかを決定することができます（4）。
以下は、衝突が検出された場合の例です。
開発者用サンドボックス
OutSystemsには、開発者が開発作業用に使える個別のサンドボックスが存在します。これにより複数の開発者が、互いの作業に影響を与えることなく、同一の開発サーバーで作業することができます。
どのOutSystemsアプリケーションも、開発サーバーに共有領域と個別領域（サンドボックス）を持っています。あるOutSystemsアプリケーションの変更作業を行う場合、開発テストサイクル期間中の変更のデプロイ先は、開発者自らの個別領域に限定されます。機能が安定しチーム全体で共有できる状態になった段階で、開発者は自分のアプリケーションバージョンをパブリッシュし、共有領域のバージョンとマージすることができます。
バージョン管理
こうした連携用のすべての機能を支えるのが、OutSystemsにビルトインされているバージョン管理エンジンです。OutSystemsは、アプリケーションが最初に作成された時点から、アプリケーションがパブリッシュされるたびに、すべてのバージョン、コンポーネント、コネクタを、誰にもでも見える形で中央リポジトリに保存します。ユーザーは、すべてのバージョンを調べ、誰がいつパブリッシュしたかをチェックし、前のバージョンのダウンロードやロールバックを行うことができます。開発中はこれらが自動的に行われるため、時間と労力を削減できます。
以下は、あるモジュールのバージョン履歴の例です。1回のクリックで、前のどのバージョンでもダウンロードやロールバックすることができます。
デプロイのためのタグ付け
OutSystemsを使用すると、アプリケーションとその依存関係のスナップショットを取得し、それをバージョンにタグ付けしてデプロイに使用することができます。この例では、Vacationsアプリケーションに半日休暇の申請という新機能が追加されたため、それをタグ付けしたうえで、開発作業を継続しています。
アプリケーションへのタグ付けは、インフラの安定性および柔軟性を確保するうえで非常に重要です。タグ付けは、通常アプリケーションの開発が安定した段階やマイルストーンに到達した段階で行います。こうすることで、いつでもアプリケーションとモジュールの状態を元に戻すことができます。
開発チームは、取り組みの節目に到達するたびに、アプリケーションにタグ付けすることができます。その後、チームは新しい取り組みを開始し、アプリケーション開発を継続します。それと並行して、継続中のアプリケーション開発を中断させることなく、アプリケーションのタグ付けしたバージョンをQA環境へとデプロイすることができます。
