Page History

変更された LANSA オブジェクトを自動的に構築

まず最初に、配布用の LANSA オブジェクトを構築するためには、別の LANSA インストールが必要になります。LANSA では、これをビルド・マシンと呼びますが、同じマシンに他の LANSA がインストールされていても構いません。主な要件は、このマシンが常に電源が入っていて、GitLab のソースコード・リポジトリに送信された変更がビルドできる状態になっていることです。

1.      以前開発者用に行った際と同様の手順で、Visual LANSA をインストールしす。

2.      自身のブランチに対して変更がコミットされた時に、ソースコード・リポジトリからソースコードが引き出せるように、GitLab Runner を設定します。このリポジトリは、LANSA のコンパイル済みオブジェクトをターゲット・システムに配布するために使用するリポジトリとは異なることに注意してください。

3.      ソースコード変更時に自動的にコンパイルされるように、Visual LANSA IDE を設定します。

4.      ソースコード・リポジトリのルート・ディレクトリに gitlab-ci.yml ファイルを作成します。配信用のリポジトリで使用しているものをベースにしても構いません。このファイルはソースコードであり、必要な処理は、Git リポジトリをプルすることだけなので、before_script と after_script は必要ありません。

5.      IDE を起動した状態にしておきます。ソースコード・リポジトリの origin に変更がプッシュされると、自動的に IDE にプルされます。

6.      テストのターゲット・システムを更新したい場合、ビルド・マシンの Visual LANSA IDE からボタンをクリックするだけで、手動で「アプリケーションの配布」を行うことができます。

監視されている Git リファレンスの変更

ターゲットシステム上のレジストリ設定  HKLM\Software\LANSA\APP1\ENG\GITREPOBRANCH は、GitLab Runner がどの Git リファレンスを監視するかを制御します。デフォルトでは、masterに設定されています。ブランチまたはタグを指定することができます。レジストリ設定は、ターゲット・システムの設定時に作成され、手動で変更することもできます。

master 以外のブランチを指定した場合は、自身の開発環境で .gitlab-ci.yml ファイルを修正する必要があります。このファイルはアプリケーションのその他の部分とともに配布されます。以下に示されるように、deploy_branch_job セクションと validate_branch_job セクションで、only の値と tags の値を監視したいブランチに変更します。

を以下に変更します。

タグを指定した場合は、さらに必要なステップがあり、ファイル .gitlab-ci.yml を修正する必要があります。以下のように、deploy_tag_job セクションと validate_tag_job セクションで、only の値と tags の値を監視したいタグに変更してください。

を以下に変更します。

また、ターゲット・システムに GitLab Runner をインストールする場合、tags 属性に新しい値を追加する必要があります。この作業を行わないと、ジョブが stuck し、動かなくなってしまいます。

デフォルト設定の微調整

デフォルトの gitlab-ci.yml ファイルは、簡単に実行でき、さまざまなオプションも示されていますが、不必要なものが含まれている場合もあります。たとえば、master ブランチの配信とともに、test-tag が定義されています。通常、master はテスト環境に配布されるため、test-tag は必要ありません。

この場合、gitlab-ci.yml ファイルを編集し、 validate_test_job と deploy_test-tag_job という名前のジョブを削除します。また、Runner のインストールからも test-tag を削除します。

実稼働ターゲット・システムの導入

「テストおよび実稼働システムの GitLab 設定 （単一のターゲット・インスタンス)」 には、実稼働のターゲット・システムがありません。そこに配布された Git リファレンスが master、test-tag、prod-tag、のいずれであっても、同じアプリケーション構成にインストールされます。これは単にデモンストレーションのためです。

まず、最初のテスト・システムとなるターゲット・システムを設定する時は、ターゲット・システムに GitLab Runner をインストールし、 tag-list パラメータの master だけを指定します。すでにデフォルト設定でインストールしている場合は、GitLab のユーザー・インターフェイスでランナーの構成を変更し、タグのパラメータを master にします。

次に、「ターゲット・システムの設定」の手順で、同様のシステムを設定し、 AutomateDeploymentTarget.ps1 スクリプトの実行時に app1branch パラメータに prod-tag を指定します。そして、ターゲット・システムに GitLab Runner をインストールし、tag-list パラメータに prod-tag を指定します。

最後に、 gitlab-ci.yml を微調整して、上記で説明したように、test-tag のジョブを削除します。この作業が完了するまでは、test-tag がどの Runner にも割り当てられていないため、パイプラインでは stuck (動かない) 状態が報告されます。

実稼働ターゲット・システムへの配布

実稼働のターゲット・システムへの配布は、Git リポジトリに直接適用されるアクションです。以下の例では、master ブランチに test-tag をタグ付けします。そして、これを origin にプッシュします。

別のコミットにタグ付けするには、別のブランチやコミット自身の参照など、Git tree 的な参照を利用します。2 回目以降のタグ付けでは、すでにタグが存在していて、これが上書きされるので、強制的にプッシュが行われます。

スケーラブルなスタックでターゲット・システムに配布

アプリケーションのアップデートを複数のターゲット・システムに配布しなければならない場合もあります。これは、ターゲット・システムが固定されている場合にのみ機能します。アプリケーションがスケーラブル・スタック上で実行されている場合、負荷に応じてマシンが作成されたり終了したりする可能性があるため、この方法は使用できません。この場合、次を使用する必要があります。

テストおよび実稼働システムの設定 （ターゲット: AWS の LANSA スタック)

...

各ターゲットシステムには独自の Runner がインストールされます。Gitlab の制限は、Git リポジトリにコミットがプッシュされたときに、1 つの　Runner だけが実行されるということです。その Runner は、このコミットの参照を受け入れる最初の　Runner となります。Runner は、特定の　Git タグのみを使用するように設定することができます。これは、配布先のターゲット・システムごとに、個別のタグのコミットが必要になることを意味しています。