開発と運用 （DevOps） は、アプリケーションのアーティファクトの変更をビルドマシンからテストシステム、そして本番稼働システムへと配布するまでの開発サイクルの一部です。

LANSA には、この DevOps サイクルの中で、ビルドされたオブジェクトを完全に動作するテスト・システムや実稼働システムに配布する機能が実装されています。これは、リポジトリ・リストでは、シンプルな "配布 (デプロイ) " というアクションとなっています。

この機能では、LANSA 配布ツールの技術を活用して、テーブルや Web ページの変更をパッケージ化し、ターゲット・システムにインストールします。ここで使用される転送メカニズムは Git リポジトリです。

以下の図は、IDE からターゲット・システムへの配布に Git が使用されていることを示しています。リポジトリはすべて Git のクローンです。IDE の配布アクションでは、まず最初に配布ツールを使ってテーブルと Web ページがパッケージ化されます。その後、現在の変更は Git にコミットされ、GitHub にプッシュされます。これらの作業はすべて配布アクションにより行われます。

そして、GitHub がターゲット・システムの Git Deploy Hub (ハブ) に Web フックを登録します。このハブは GitHub から変更を取得し、現在のブランチをチェックアウトした後、パッケージ・インストールを実行してテーブルと Web ページを配布します。サーバー・モジュールや再利用可能パーツなど、その他の LANSA オブジェクト・タイプはすべて、シンプルなファイル変更として Git が独自に処理します。

 |

サポートされるのは、64 ビットの Windows 環境のみです。

ここで使われている Git リポジトリは、実行可能なアーティファクトを配布するためのものであり、ソースコードではないことに注意してください。非常に効率的な転送メカニズムとして Git が使用されています。また、Git は非常に高いマーケットシェアを持っています。Windows 開発者で (GitHub のみということはあっても) Git リポジトリを使ったことがない人はほとんどいないと思います。ソースコードは別のリポジトリに保管されます。両者は完全に分離されており、実際、ソースコードのリポジトリが全く別のタイプの VCS に存在する場合もあります。

最新の Web 技術のみがサポートされており、WAM や古い技術はサポートされていませんが、古い技術が作動するように構成することは可能です。古い技術を使用したい場合は、LANSA とベータ契約を結ぶ必要があります。この詳細については、LANSA サポートにお問い合わせください。