この記事では、IRIS環境におけるPythonプログラミングの基礎について紹介します。

本題に入る前に、重要なトピックである「Pythonの仕組み」について説明します。これは、IRIS環境でPythonを使用して作業する際に起こりうる問題や制限を理解するのに役立ちます。

すべての記事と例は、以下のgitリポジトリで確認できます: iris-python-article

Pythonの仕組み

インタープリター型言語

Pythonはインタープリター型言語であり、コードはランタイム時に1行ずつ実行されます。スクリプトをインポートする場合でも同様です。

これはどういうことでしょうか？ 以下のコードを見てみましょう。

# introduction.py

def my_function():
    print("Hello, World!")

my_function()

このスクリプトを実行すると、Pythonインタープリターはコードを1行ずつ読み取ります。 まず最初に関数 my_function を定義してから、その関数を呼び出すと、コンソールに「Hello, World!」と出力されます。

スクリプトを直接実行している例：

python3 /irisdev/app/src/python/article/introduction.py 

出力は以下のようになります。

Hello, World!

IRIS環境でこのスクリプトをインポートするとどうなるのでしょうか？

Class Article.Introduction Extends %RegisteredObject
{
    ClassMethod Run()
    {
        Set sys = ##class(%SYS.Python).Import("sys")
        do sys.path.append("/irisdev/app/src/python/article")

        do ##class(%SYS.Python).Import("introduction")
    }
}

実行しましょう。

iris session iris -U IRISAPP '##class(Article.Introduction).Run()'

出力が表示されます。

Hello, World!

これは、Pythonインタープリターがコードを解釈しながらインポートするためで、最初に関数を定義し、その後に関数を呼び出します。これはスクリプトを直接実行した場合と同じ動作ですが、実行しているのではなくインポートしています。

⚠️ 重要な注意事項：関数を呼び出さずにスクリプトをインポートしても、何も起こりません。 関数は定義されますが、明示的に呼び出さない限り実行されません。

分かりましたか？ Pythonインタープリターはファイル内のコードを実行しますが、関数を呼び出さなければ、その関数は実行されません。

呼び出さずにインポートする例：

# introduction1.py
def my_function():
    print("Hello, World!")

Pythonインタープリターで実行しましょう。

python3 /irisdev/app/src/python/article/introduction1.py 

出力：

# 関数は定義されていますが、呼び出されていないため、出力はありません

IRIS環境にこのスクリプトをインポートすると：

Class Article.Introduction1 Extends %RegisteredObject
{
    ClassMethod Run()
    {
        Set sys = ##class(%SYS.Python).Import("sys")
        do sys.path.append("/irisdev/app/src/python/article")
        do ##class(%SYS.Python).Import("introduction1")
    }
}

実行しましょう。

iris session iris -U IRISAPP '##class(Article.Introduction1).Run()'

関数は定義されていますが、呼び出されていないため、出力はありません。

🤯この微妙な違いが重要な理由

• Pythonスクリプトをインポートすると、そのスクリプトのコードが実行されます。
  • コードを実行したくない場合があります
• インポートするとスクリプトが実行されているように見えるかもしれませんが、実際には直接実行されているわけではないため、混乱を招く可能性があります。

インポートのキャッシュ

Pythonスクリプトをインポートすると、Pythonインタープリターがインポートされたスクリプトをキャッシュします。 つまり、同じスクリプトをもう一度インポートすると、そのスクリプトのコードは再実行されず、キャッシュされたバージョンが使用されます。

具体例による説明：

introduction.py スクリプトを再利用しましょう。

# introduction.py
def my_function():
    print("Hello, World!")

my_function()

次に、同じように Article.Introduction クラスを再利用しましょう。

Class Article.Introduction Extends %RegisteredObject
{
    ClassMethod Run()
    {
        Set sys = ##class(%SYS.Python).Import("sys")
        do sys.path.append("/irisdev/app/src/python/article")
        do ##class(%SYS.Python).Import("introduction")
    }
}

今度は、同じIRISセッション内で2回続けて実行します。

iris session iris -U IRISAPP 

IRISAPP>do ##class(Article.Introduction).Run()
Hello, World!

IRISAPP>do ##class(Article.Introduction).Run()

IRISAPP>

🤯一体どういうことでしょうか？

はい、「Hello, World!」は一度だけ出力されます！

⚠️ インポートされたスクリプトはキャッシュされています。 つまり、インポートした後にスクリプトを変更しても、IRSセッションが変更されるまで変更は反映されません。

IRISで language tag を使用する場合でも同じです。

Class Article.Introduction2 Extends %RegisteredObject
{

ClassMethod Run() [ Language = python ]
{
    import os

    if not hasattr(os, 'foo'):
        os.foo = "bar"
    else:
        print("os.foo already exists:", os.foo)
}

}

実行しましょう。

iris session iris -U IRISAPP

IRISAPP>do ##class(Article.Introduction2).Run()

IRISAPP>do ##class(Article.Introduction2).Run()
os.foo already exists: bar

なんと、os モジュールはキャッシュされ、foo 属性は存在しないことに再定義されていません。

まとめ

この入門編が、IRISでPythonを使用する際に、特にスクリプトのインポートやキャッシュ処理に関して、予期しない動作が発生する理由を理解する助けになれば幸いです。

IRISでPythonを使う際のポイント：

• Pythonスクリプトで変更を確認するには、IRISセッションを毎回変更する。
  • これはバグではなく、Pythonの仕様です。
• スクリプトをインポートするとそのコードが実行されることに気を付ける。

ボーナス

待って！ スクリプトをインポートするとキャッシュされる？つじつまが合いません。 language tag = python で作業していて、スクリプトを変更したのにIRISセッションを変更しなくてもうまく動作するのは何故でしょうか？

いい質問です。これは language tag の仕組みが関係しています。language tag は実行するたびにスクリプトをもう一度読み込み、ネイティブのPythonインタープリターで新しい行を入力するかのように、行ごとに実行します。language tag はスクリプトをインポートするわけではなく、Pythonインタープリターを再起動せずに直接スクリプトを実行しているのと同じ動作をします。

例：

Class Article.Introduction2 Extends %RegisteredObject
{
ClassMethod Run() [ Language = python ]
{
    import os

    if not hasattr(os, 'foo'):
        os.foo = "bar"
    else:
        print("os.foo already exists:", os.foo)
}
}

実行しましょう。

iris session iris -U IRISAPP
IRISAPP>do ##class(Article.Introduction2).Run()

IRISAPP>do ##class(Article.Introduction2).Run()
os.foo already exists: bar  

Pythonインタープリターだと、こんな感じになります。

import os

if not hasattr(os, 'foo'):
    os.foo = "bar"
else:
    print("os.foo already exists:", os.foo)

import os
if not hasattr(os, 'foo'):
    os.foo = "bar"
else:
    print("os.foo already exists:", os.foo)

出力：

os.foo already exists: bar # only printed once

いかがでしょうか。

今後の内容 :

• Pep8
• モジュール
• ダンダーメソッド
• IRISでPythonを動かす
• ...

説明

これは、ネイティブウェブアプリケーションとして IRIS にデプロイできる FastAPI アプリケーションのテンプレートです。

インストール

1. リポジトリをクローンする
2. 仮想環境を作成する
3. 要件をインストールする
4. docker-compose ファイルを実行する

git clone
cd iris-fastapi-template
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
docker-compose up

使用法

ベース URL は http://localhost:53795/fastapi/ です。

エンドポイント

• /iris - IRISAPP ネームスペースに存在する上位 10 個のクラスを持つ JSON オブジェクトを返します。
• /interop - IRIS の相互運用性フレームワークをテストするための ping エンドポイント。
• /posts - Post オブジェクトの単純な CRUD エンドポイント。
• /comments - Comment オブジェクトの単純な CRUD エンドポイント。

このテンプレートからの開発方法

WSGI 導入記事をご覧ください: wsgiサポートの概要。

概要: セキュリティポータルで DEBUG フラグをトグルすると、開発作業の過程で変更内容がアプリケーションに反映されるようになります。

コードの説明

app.py

これは FastAPI アプリケーションのメインのファイルです。 FastAPI アプリケーションとルートが含まれます。

from fastapi import FastAPI, Request

import iris

from grongier.pex import Director

# import models
from models import Post, Comment, init_db
from sqlmodel import Session,select

app = FastAPI()

# create a database engine
url = "iris+emb://IRISAPP"
engine = init_db(url)

• from fastapi import FastAPI, Request - FastAPI クラスト Request クラスをインポートします。
• import iris - IRIS モジュールをインポートします。
• from grongier.pex import Director: Flask アプリを IRIS 相互運用性フレームワークにバインドする Director クラスをインポートします。
• from models import Post, Comment, init_db - モデルと init_db 関数をインポートします。
• from sqlmodel import Session,select - Session クラスと sqlmodel モジュールの選択された関数をインポートします。
• app = FastAPI() - FastAPI アプリケーションを作成します。
• url = "iris+emb://IRISAPP" - IRIS ネームスペースの URL を定義します。
• engine = init_db(url) - sqlmodel ORM のデータベースエンジンを作成します。

models.py

このファイルには、アプリケーションのモデルが含まれます。

from sqlmodel import Field, SQLModel, Relationship, create_engine

class Comment(SQLModel, table=True):
    id: int = Field(default=None, primary_key=True)
    post_id: int = Field(foreign_key="post.id")
    content: str
    post: "Post" = Relationship(back_populates="comments")

class Post(SQLModel, table=True):
    id: int = Field(default=None, primary_key=True)
    title: str
    content: str
    comments: list["Comment"] = Relationship(back_populates="post")

説明することは特にありません。外部キーとリレーションによる単なるモデルの定義です。

init_db 関数は、データベースエンジンの作成に使用されます。

def init_db(url):

    engine = create_engine(url)

    # create the tables
    SQLModel.metadata.drop_all(engine)
    SQLModel.metadata.create_all(engine)

    # initialize database with fake data
    from sqlmodel import Session

    with Session(engine) as session:
        # Create fake data
        post1 = Post(title='Post The First', content='Content for the first post')
        ...
        session.add(post1)
        ...
        session.commit()

    return engine

• engine = create_engine(url) - データベースエンジンを作成します。
• SQLModel.metadata.drop_all(engine) - すべてのテーブルをドロップします。
• SQLModel.metadata.create_all(engine) - すべてのテーブルを作成します。
• with Session(engine) as session: - データベースを操作するためのセッションを作成します。
• post1 = Post(title='Post The First', content='Content for the first post') - Post オブジェクトを作成します。
• session.add(post1) - Post オブジェクトをセッションに追加します。
• session.commit() - 変更内容をデータベースにコミットします。
• return engine - データベースエンジンを返します。

/iris エンドポイント

######################
# IRIS Query example #
######################

@app.get("/iris")
def iris_query():
    query = "SELECT top 10 * FROM %Dictionary.ClassDefinition"
    rs = iris.sql.exec(query)
    # Convert the result to a list of dictionaries
    result = []
    for row in rs:
        result.append(row)
    return result

• @app.get("/iris") - /iris エンドポイントの GET ルートを定義します。
• query = "SELECT top 10 * FROM %Dictionary.ClassDefinition" - IRIS ネームスペースで上位 10 個のクラスを取得するクエリを定義します。
• rs = iris.sql.exec(query) - クエリを実行します。
• result = [] - 結果を保存する空のリストを作成します。
• for row in rs: - 結果セットを反復処理します。
• result.append(row) - 結果リストを行にアペンドします。
• return result - 結果リストを返します。

/interop エンドポイント

########################
# IRIS interop example #
########################
bs = Director.create_python_business_service('BS')

@app.get("/interop")
@app.post("/interop")
@app.put("/interop")
@app.delete("/interop")
def interop(request: Request):
    
    rsp = bs.on_process_input(request)

    return rsp

• bs = Director.create_python_business_service('BS') - Python ビジネスサービスを作成します。
  • ビジネスサービスの複数のインスタンスを防止するために、ルート定義の外に作成する必要があります。
• @app.get("/interop") - /interop エンドポイントの GET ルートを定義します。
• @app.post("/interop") - /interop エンドポイントの POST ルートを定義します。
• ...
• def interop(request: Request): - ルートハンドラーを定義します。
• rsp = bs.on_process_input(request) - ビジネスサービスの on_process_input メソッドを呼び出します。
• return rsp - レスポンスを返します。

/posts エンドポイント

############################
# CRUD operations posts    #
############################

@app.get("/posts")
def get_posts():
    with Session(engine) as session:
        posts = session.exec(select(Post)).all()
        return posts
    
@app.get("/posts/{post_id}")
def get_post(post_id: int):
    with Session(engine) as session:
        post = session.get(Post, post_id)
        return post
    
@app.post("/posts")
def create_post(post: Post):
    with Session(engine) as session:
        session.add(post)
        session.commit()
        return post

このエンドポイントは、Post オブジェクトで CRUD 操作を実行するために使用されます。

説明することは特にありません。すべての投稿を取得し、ID で投稿を取得し、投稿を作成するためのルートの定義です。

すべては sqlmodel ORM を使って行われます。

/comments エンドポイント

############################
# CRUD operations comments #
############################


@app.get("/comments")
def get_comments():
    with Session(engine) as session:
        comments = session.exec(select(Comment)).all()
        return comments
    
@app.get("/comments/{comment_id}")
def get_comment(comment_id: int):
    with Session(engine) as session:
        comment = session.get(Comment, comment_id)
        return comment
    
@app.post("/comments")
def create_comment(comment: Comment):
    with Session(engine) as session:
        session.add(comment)
        session.commit()
        return comment

このエンドポイントは、Comment オブジェクトで CRUD 操作を実行するために使用されます。

説明することは特にありません。すべてのコメントを取得し、ID でコメントを取得し、コメントを作成するためのルートの定義です。

すべては sqlmodel ORM を使って行われます。

トラブルシューティング

スタンドアロンモードで FastAPI アプリケーションを実行する方法

以下のコマンドを使用して、いつでもスタンドアロンの Flask アプリケーションを実行できます。

python3 /irisdev/app/community/app.py

注: このコマンドを実行するには、コンテナー内にいる必要があります。

docker exec -it iris-fastapi-template-iris-1 bash

IRIS でアプリケーションを再起動する

DEBUG モードでアプリケーションに複数の呼び出しを行うと、変更はアプリケーションに反映されます。

IRIS 管理ポータルへのアクセス方法

http://localhost:53795/csp/sys/UtilHome.csp に移動すると、IRIS 管理ポータルにアクセスできます。

このテンプレートをローカルで実行する

これには、マシンに IRIS がインストールされている必要があります。

次に、IRISAPP というネームスペースを作成する必要があります。

要件をインストールします。

IoP のインストール:

#init iop
iop --init

# load production
iop -m /irisdev/app/community/interop/settings.py

# start production
iop --start Python.Production

セキュリティポータルでアプリケーションを構成します。

説明

これは、ネイティブウェブアプリケーションとして IRIS にデプロイできる Flask アプリケーションのテンプレートです。

インストール

1. リポジトリをクローンする
2. 仮想環境を作成する
3. 要件をインストールする
4. docker-compose ファイルを実行する

git clone
cd iris-flask-template
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
docker-compose up

使用法

ベース URL は http://localhost:53795/flask/ です。

エンドポイント

• /iris - IRISAPP ネームスペースに存在する上位 10 個のクラスを持つ JSON オブジェクトを返します。
• /interop - IRIS の相互運用性フレームワークをテストするための ping エンドポイント。
• /posts - Post オブジェクトの単純な CRUD エンドポイント。
• /comments - Comment オブジェクトの単純な CRUD エンドポイント。

このテンプレートからの開発方法

WSGI 導入記事をご覧ください: wsgi-introduction。

概要: セキュリティポータルで DEBUG フラグをトグルすると、開発作業の過程で変更内容がアプリケーションに反映されるようになります。

コードの説明

app.py

これはアプリケーションのメインのファイルです。 Flask アプリケーションとエンドポイントが含まれます。

from flask import Flask, jsonify, request
from models import Comment, Post, init_db

from grongier.pex import Director

import iris

app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = 'iris+emb://IRISAPP'

db = init_db(app)

• from flask import Flask, jsonify, request: Flask ライブラリをインポートします。
• from models import Comment, Post, init_db: モデルとデータベース初期化関数をインポートします。
• from grongier.pex import Director: Flask アプリを IRIS 相互運用性フレームワークにバインドする Director クラスをインポートします。
• import iris: IRIS ライブラリをインポートします。
• app = Flask(__name__): Flask アプリケーションを作成します。
• app.config['SQLALCHEMY_DATABASE_URI'] = 'iris+emb://IRISAPP': データベース URI を IRISAPP ネームスペースに設定します。
  • iris+emb URI スキームは、埋め込み接続として IRIS に接続するために使用されます（別の IRIS インスタンスの必要はありません）。
• db = init_db(app): Flask アプリケーションでデータベースを初期化します。

models.py

このファイルには、アプリケーションの SQLAlchemy モデルが含まれます。

from dataclasses import dataclass
from typing import List
from flask_sqlalchemy import SQLAlchemy

db = SQLAlchemy()

@dataclass
class Comment(db.Model):
    id:int = db.Column(db.Integer, primary_key=True)
    content:str = db.Column(db.Text)
    post_id:int = db.Column(db.Integer, db.ForeignKey('post.id'))

@dataclass
class Post(db.Model):
    __allow_unmapped__ = True
    id:int = db.Column(db.Integer, primary_key=True)
    title:str = db.Column(db.String(100))
    content:str = db.Column(db.Text)
    comments:List[Comment] = db.relationship('Comment', backref='post')

説明することは特にありません。モデルはデータクラスとして定義されており、db.Model クラスのサブクラスです。

__allow_unmapped__ 属性は、comments 属性を使用せずに Post オブジェクトを作成できるようにするために使用する必要があります。

dataclasses はオブジェクトを JSON にシリアル化するのに使用されます。

init_db 関数は、Flask アプリケーションでデータベースを初期化します。

def init_db(app):
    db.init_app(app)

    with app.app_context():
        db.drop_all()
        db.create_all()
        # Create fake data
        post1 = Post(title='Post The First', content='Content for the first post')
        ...
        db.session.add(post1)
        ...
        db.session.commit()
    return db

• db.init_app(app): Flask アプリケーションでデータベースを初期化します。
• with app.app_context(): アプリケーションのコンテキストを作成します。
• db.drop_all(): データベースのすべてのテーブルをドロップします。
• db.create_all(): データベースのすべてのテーブルを作成します。
• アプリケーションの偽データを作成します。
• データベースオブジェクトを返します。

/iris エンドポイント

######################
# IRIS クエリ例 #
######################

@app.route('/iris', methods=['GET'])
def iris_query():
    query = "SELECT top 10 * FROM %Dictionary.ClassDefinition"
    rs = iris.sql.exec(query)
    # Convert the result to a list of dictionaries
    result = []
    for row in rs:
        result.append(row)
    return jsonify(result)

このエンドポイントは、IRIS データベースでクエリを実行し、IRISAPP ネームスペースに存在する上位 10 個のクラスを返します。

/interop エンドポイント

########################
# IRIS interop example #
########################
bs = Director.create_python_business_service('BS')

@app.route('/interop', methods=['GET', 'POST', 'PUT', 'DELETE'])
def interop():
    
    rsp = bs.on_process_input(request)

    return jsonify(rsp)

このエンドポイントは、IRIS の相互運用性フレームワークをテストするために使用されます。 ビジネスサービスオブジェクトを作成し、それを Flask アプリケーションにバインドします。

注: bs オブジェクトは有効な状態を維持するために、リクエストの範囲外にある必要があります。

• bs = Director.create_python_business_service('BS'): 'BS' というビジネスサービスオブジェクトを作成します。
• rsp = bs.on_process_input(request): リクエストオブジェクトを引数としてビジネスサービスオブジェクトの on_process_input メソッドを呼び出します。

/posts エンドポイント

############################
# CRUD operations posts    #
############################

@app.route('/posts', methods=['GET'])
def get_posts():
    posts = Post.query.all()
    return jsonify(posts)

@app.route('/posts', methods=['POST'])
def create_post():
    data = request.get_json()
    post = Post(title=data['title'], content=data['content'])
    db.session.add(post)
    db.session.commit()
    return jsonify(post)

@app.route('/posts/<int:id>', methods=['GET'])
def get_post(id):
    ...

このエンドポイントは、Post オブジェクトで CRUD 操作を実行するために使用されます。

dataclasses モジュールにより、Post オブジェクトは簡単に JSON にシリアル化できます。

以下では、すべての投稿を取得する sqlalchemy の query メソッドと、新しい投稿を作成するための add と commit メソッドを使用しています。

/comments エンドポイント

############################
# CRUD operations comments #
############################

@app.route('/comments', methods=['GET'])
def get_comments():
    comments = Comment.query.all()
    return jsonify(comments)

@app.route('/comments', methods=['POST'])
def create_comment():
    data = request.get_json()
    comment = Comment(content=data['content'], post_id=data['post_id'])
    db.session.add(comment)
    db.session.commit()
    return jsonify(comment)

@app.route('/comments/<int:id>', methods=['GET'])
def get_comment(id):
    ...

このエンドポイントは、Comment オブジェクトで CRUD 操作を実行するために使用されます。

Comment オブジェクトは外部キーによって Post オブジェクトにリンクされます。

トラブルシューティング

スタンドアロンモードで Flask アプリケーションを実行する方法

以下のコマンドを使用して、いつでもスタンドアロンの Flask アプリケーションを実行できます。

python3 /irisdev/app/community/app.py

注: このコマンドを実行するには、コンテナー内にいる必要があります。

docker exec -it iris-flask-template-iris-1 bash

IRIS でアプリケーションを再起動する

DEBUG モードでアプリケーションに複数の呼び出しを行うと、変更はアプリケーションに反映されます。

IRIS 管理ポータルへのアクセス方法

http://localhost:53795/csp/sys/UtilHome.csp に移動すると、IRIS 管理ポータルにアクセスできます。

このテンプレートをローカルで実行する

これには、マシンに IRIS がインストールされている必要があります。

次に、IRISAPP というネームスペースを作成する必要があります。

要件をインストールします。

IoP のインストール:

#init iop
iop --init

# load production
iop -m /irisdev/app/community/interop/settings.py

# start production
iop --start Python.Production

セキュリティポータルでアプリケーションを構成します。

CI/CD シリーズの新しい章へようこそ。ここでは、InterSystems テクノロジーと GitLab を使用したソフトウェア開発の様々な可能なアプローチを取り上げています。

今回は、相互運用性についてご紹介しましょう。

問題

アクティブな相互運用性プロダクションがある場合、2 つの個別のプロセスフローが存在します。メッセージを処理する稼動中のプロダクションと、コード、プロダクションの構成、およびシステムデフォルト設定を更新する CI/CD プロセスフローです。

明らかに、CI/CD プロセスは相互運用性に影響しますが、 本題は次にあります。

• 更新中には実際に何が起きているのか？
• 更新中の本番停止を最小限に抑えるか失くしてしまうには、どうすればよいのか？

用語

• ビジネスホスト（BH）- 相互運用性プロダクションの構成可能な要素: ビジネスサービス（BS）、ビジネスプロセス（BP、BPL）、ビジネスオペレーション（BO）。
• ビジネスホストジョブ（ジョブ）- ビジネスホストのコードを実行し、相互運用性プロダクションによって管理される InterSystems IRIS ジョブ。
• プロダクション - 相互に接続されたビジネスホストのコレクション。
• システムデフォルト設定（SDS）- InterSystems IRIS がインストールされている環境に固有の値。
• アクティブメッセージ - 1 つのビジネスホストジョブによって現在処理されているリクエスト。 1 つのビジネスホストジョブに対するアクティブメッセージは最大 1 つです。 アクティブメッセージのないビジネスホストジョブはアイドルです。

何が起きているのか？

プロダクションのライフサイクルから見てみましょう。

プロダクションの起動

まず初めに、プロダクションを起動できます。 ネームスペースあたり 1 つのプロダクションのみを同時に実行でき、一般に（作業内容や過程を十分に理解していない限り）、ネームスペースごとに実行するプロダクションは 1 つ限りです。 1 つのネームスペース内で 2 つ以上の異なるプロダクションを切り替えるのは推奨されません。 プロダクションを起動すると、そのプロダクションに定義されたすべての有効なビジネスホストが起動します。 一部のビジネスホストが起動に失敗してもプロダクションの起動には影響しません。

ヒント:

• システム管理ポータルから、または ##class(Ens.Director).StartProduction("ProductionName") を呼び出してプロダクションを起動します。
• OnStart メソッドを実装して、プロダクションの起動時に（ビジネスホストジョブが起動する前に）任意のコードを実行します。
• プロダクションの起動は監査可能なイベントです。 誰がいつ起動したかを必ず監査ログで確認できます。

プロダクションの更新

プロダクションが起動した後、Ens.Director は実行中のプロダクションを継続的に監視します。 プロダクションの状態は 2 つあります。プロダクションクラスとシステムデフォルト設定に定義された target state と、ジョブが作成されたときに適用された設定で現在実行しているジョブの running state です。 希望する状態と現在の状態が同一である場合はすべて良好ですが、異なる場合にはプロダクションを更新する必要があります。 通常、この場合には、システム管理ポータルのプロダクション構成ページに赤い「更新」ボタンが表示されます。

プロダクションを更新すると、現在のプロダクションの状態をターゲットプロダクションの状態に一致させることになります。

プロダクションを更新するために ##class(Ens.Director).UpdateProduction(timeout=10, force=0) を実行すると、各ビジネスホストにおいて以下が行われます。

1. アクティブな設定をプロダクション/SDS/クラスの設定と比較します。
2. (1) で不一致が生じた場合に限り、ビジネスホストは古いものとしてマークされ、更新が必要となります。

これを各ビジネスホストに対して実行した後、UpdateProduction は一連の変更をビルドします。

• ビジネスホストを停止
• ビジネスホストを起動
• プロダクション設定を更新

そしてその後で適用します。

このようにして、何も変更せずに設定を「更新」するとプロダクションが停止しません。

ヒント:

• システム管理ポータルから、または ##class(Ens.Director).UpdateProduction(timeout=10, force=0) を呼び出してプロダクションを更新します。 システム管理ポータルのデフォルトの更新タイムアウトは 10 秒です。 メッセージの処理がそれ以上かかることが分かっている場合は、タイムアウト時間がより長い Ens.Director:UpdateProduction を呼び出します。
• 更新タイムアウトはプロダクションの設定であり、より長い時間に値を変更できます。 この設定はシステム管理ポータルに適用されます。

コードの更新

UpdateProduction は古いコードで BH を更新することはありません。 これは安全を優先した動作ではありますが、根底にあるコードが変更した場合にすべての実行中の BH を自動的に更新する場合は、以下のように行います。

まず、以下のように読み込んでコンパイルします。

do $system.OBJ.LoadDir(dir, "", .err, 1, .load)
do $system.OBJ.CompileList(load, "curk", .errCompile, .listCompiled)

listCompiled には、u フラグにより、実際にコンパイルされたすべての項目が含まれます（読み込まれるセットを最小限に抑えるには、git diffs を使用します）。 この listCompiled を使用して、コンパイルされたすべてのクラスの $lb を取得します。

set classList = ""
set class = $o(listCompiled(""))
while class'="" { 
  set classList = classList _ $lb($p(class, ".", 1, *-1))
  set class=$o(listCompiled(class))
}

その後で、再起動が必要な BH のリストを計算します。

SELECT %DLIST(Name) bhList
FROM Ens_Config.Item 
WHERE 1=1
  AND Enabled = 1
  AND Production = :production
  AND ClassName %INLIST :classList

最後に、bhList を取得した後に、影響のあるホストを停止して起動します。

for stop = 1, 0 {
  for i=1:1:$ll(bhList) {
    set host = $lg(bhList, i)
    set sc = ##class(Ens.Director).TempStopConfigItem(host, stop, 0)
  }
  set sc = ##class(Ens.Director).UpdateProduction()
}

プロダクションの停止

プロダクションは停止可能です。つまり、すべての美自演すホストジョブにシャットダウンのリクエストを送信します（アクティブなメッセージがある場合はその処理が完了してから安全にシャットダウンされます）。

ヒント:

• システム管理ポータルから、または ##class(Ens.Director).StopProduction(timeout=10, force=0) を呼び出してプロダクションを停止します。 システム管理ポータルのデフォルトの停止タイムアウトは 120 秒です。 メッセージの処理がそれ以上かかることが分かっている場合は、タイムアウト時間がより長い Ens.Director:StopProduction を呼び出します。
• シャットダウンタイムアウトはプロダクションの設定です。 より長い時間に値を変更できます。 この設定はシステム管理ポータルに適用されます。
• OnStop メソッドを実装して、プロダクションの停止時に任意のコードを実行します。
• プロダクションの停止は監査可能なイベントであり、誰がいつ停止したのかを必ず監査ログで確認できます。

ここで重要なのは、プロダクションはビジネスホストの合計であることです。

• プロダクションを起動するとすべての有効なビジネスホストが起動します。
• プロダクションを停止するとすべての実行中のビジネスホストが停止します。
• プロダクションを更新すると、古いセットのビジネスホストが計算され、これらが先に停止されてからその直後にもう一度起動されます。 また、新たに追加されたビジネスホストは開始のみされ、プロダクションから削除されたビジネスホストは単に停止されます。

この流れで、ビジネスホストのライフサイクルに進みましょう。

ビジネスホストの起動

ビジネスホストは（プールサイズの設定値に応じて）同一のビジネスホストジョブで構成されています。 ビジネスホストを起動すると、すべてのビジネスホストジョブが起動します。 これらは並列して起動します。

個別のビジネスホストジョブは以下のように起動します。

1. 相互運用性はビジネスホストジョブになる新しいプロセスを JOB で起動します。
2. 新しいプロセスは相互運用性ジョブとして登録されます。
3. ビジネスホストコードとアダプターコードがプロセスメモリに読み込まれます。
4. ビジネスホストとアダプターに関連する設定がメモリに読み込まれます。 以下はその順序です。 a. プロダクション設定（システムデフォルトとクラス設定をオーバーライドします）。 b. システムデフォルト設定（クラス設定をオーバーライドします）。 c. クラス設定。
5. ジョブの準備が整い、メッセージを受け入れ始めます。

（4）が完了すると、ジョブは設定またはコードを変更できないため、新しい/同じコードと新しい/同じシステムデフォルト設定をインポートしても、現在実行中の相互運用性ジョブに影響しません。

ビジネスホストの停止

ビジネスホストジョブを停止すると、以下のようになります。

1. 相互運用性はジョブにメッセージ/入力の受け入れ停止を要求します。
2. アクティブなメッセージがある場合、ビジネスホストジョブにはそれを処理するための数秒のタイムアウトがあります（ジョブを完了、つまり BO の場合は OnMessage メソッド、BS の場合は OnProcessInput メソッド、BPL BP の場合は状態の S<int> メソッド、BP の場合は On*メソッドを終了します）。
3. アクティブなメッセージがタイムアウトと force=0 までに処理されていない場合、そのビジネスホストのプロダクションの更新は失敗します（SMP に赤い更新ボタンが表示されます）。
4. 以下のいずれかを満たす場合は停止します。
   • アクティブなメッセージがない
   • アクティブなメッセージは timeout の前に処理された
   • アクティブなメッセージはタイムアウト前に処理されなかったが force=1 で処理された
5. ジョブは 相互運用性から登録解除され停止します。

ビジネスホストの更新

ビジネスホストの更新では、ビジネスホストの現在実行中のジョブを停止し、新しいジョブを起動します。

ビジネスルール、ルーティングルール、DTL

すべてのビジネスホストは、新しいバージョンのビジネスルール、ルーティングルール、および DTL が利用できるようになると直ちにそれらを使用し始めます。 この状況では、ビジネスホストの再起動は不要です。

オフラインでの更新

とは言え、時にはプロダクションの更新には個別のビジネスホストの停止が必要です。

ルールは新しいコードで決まる

この状況を考えてみてください。 任意の基準に基づいてメッセージをビジネスプロセス A または B にルーティングする現在のルーティングルール X があるとします。 新しいコミットにおいて、以下を同時に追加します。

• ビジネスプロセス C
• メッセージを A、B、または C にルーティングする新しいバージョンのルーティングルール X

このシナリオでは、先にルールを読み込んでからプロダクションを更新することはできません。 新しくコンパイルされるルールは、InterSystems IRIS がまだコンパイルしていないかもしれないビジネスプロセス C に直ちにルーティングし始めるか、相互運用性がまだ使用できるように更新されていないためです。 この場合、ルーティングルールでビジネスホストを無効に子、コードを更新し、プロダクションを更新して、ビジネスホストをもう一度有効にする必要がります。

注意:

• プロダクションデプロイファイルを使用してプロダクションを更新する場合、影響されるすべての BH は自動的に無効化/有効化されます。
• InProc によって呼び出されたホストの場合、コンパイルによって呼び出し元が保持する特定のホストのキャッシュが無効になります。

ビジネスホスト間の依存関係

ビジネスホスト間の依存関係は重要です。 ビジネスプロセス A と B があり、A が B にメッセージを送信するとします。 新しいコミットにおいて、以下を同時に追加します。

• リクエストの新しいプロパティX を B に設定する新しいバージョンのプロセス A
• 新しいプロパティ X を処理できる新しいバージョンのプロセス B

このシナリオでは、プロセス B を先に更新してから A を更新する必要があります。 これは次のいずれかの方法で行えます。

• 更新の間、ビジネスホストを無効化する
• 更新を 2 つに分ける: まずプロセス B のみを更新してから、その後の別の更新で、プロセス A から B にメッセージを送信し始める。

新しいバージョンのプロセス A と B に古いバージョンとの互換性がない場合のより困難な状況では、ビジネスホストの停止が必要となります。

キュー

更新後に、ビジネスホストが古いメッセージを処理できないことが分かっている場合、ビジネスホストキューが更新前に空になっていることを確認する必要があります。 これを行うには、ビジネスホストにメッセージを送信するすべてのビジネスホストを無効化し、そのキューが空になるのを待ちます。

BPL ビジネスプロセスにおける状態の変更

はじめに、BPL BP の仕組みから簡単に説明します。 BPL BP をコンパイルした後、2 つのクラスが完全な BPL クラス名と同じ名前でパッケージに作成されます。

• Thread1 クラスはメソッド S1, S2, ... Sn を含み、BPL 内のアクティビティに対応します。
• Context クラスにはすべてのコンテキスト変数があり、BPL が実行する次の状態もあります（S5）・

また BPL クラスは永続であり、現在処理中のリクエストを格納します。

BPL は Thread クラスで S メソッドを実行し、それにおうじて BPL クラステーブル、Context テーブル、および Thread1テーブルを更新することによって機能します。ここで、「処理中」の 1 つのメッセージは BPL テーブル内の 1 行になります。 リクエストが処理されると、BPL は BPL、Context、および Thread エントリを削除します。 BPL BP は非同期であるため、1 つの BPL ジョブは S 呼び出しの間に情報を保存して異なるリクエストを切り替えることで、同時に多数のリクエストを処理できます。 たとえば、BPL は 1 つのリクエストが sync アクティビティに到達するまで処理し、BO からの応答を待ちます。 現在のコンテキストを %NextState プロパティ（Thread1 クラス）をレスポンスアクティビティ S メソッドに設定してディスクに保存し、BO が応答するまで他のリクエストを処理します。 BO が応答したら、BPL はコンテキストをメモリに読み込んで、%NextState プロパティに保存された状態に対応するメソッドを実行します。

では、BPL を更新したらどうなるでしょうか？ まず、少なくとも以下の 2 つの条件の 1 つを満たしていることをチェックする必要があります。

• 更新中に、Context テーブルが空である。つまり、処理中のアクティブなメッセージがない。
• 新しい状態は古い状態と同じであるか、新しい状態は古い状態の後に追加されている。

少なくとも 1 つの条件を満たしている場合は、問題ありません。 更新後 BPL が処理する更新前リクエストが存在しないか、状態が最後に追加される、つまり古いリクエストもそこに含まれることが可能です（更新前リクエストが更新後 BPL アクティビティと処理に互換していることが前提です）。

ただし、処理中のアクティブなリクエストが存在し、BPL が状態の順序を変更した場合はどうでしょうか？ 理想的には、待機できるのであれば、BPL 呼び出し元を無効にしてキューが空になるまで待機します。 Context テーブルが空であることも確認します。 キューには未処理のリクエストのみが表示され、Context テーブルは処理中のリクエストを格納することを覚えておきましょう。つまり、非常にビジーな BPL のキューサイズが 0 となる場合があり、それは正常です。 その後、BPL を無効にし、更新を実行して、以前に無効にしたすべてのビジネスホストを有効にします。

それが可能でない場合は（通常、非常に時間のかかる BPL がある場合。リクエストの処理に約 1 週間かかった BPL の更新ケースや更新ウィンドウが短すぎたケースを覚えています）、BPL バージョン管理を使用します。

または、更新スクリプトを書くことができます。 この更新スクリプトでは、更新された BPL が古いリクエストを処理できるように、古い次の状態を新しい次の状態にマッピングして、Thread1 テーブルで実行します。 もちろん更新期間中は BPL を無効にしておく必要があります。 とは言え、これは非常にまれな状況であり、通常は行う必要はありませんが、その必要性が生じた場合にはこれを使用することができます。

まとめ

相互運用性は、根底にあるコードが変更した後でプロダクションを最新状態にするために必要となるアクションを最小限に抑えるために、洗練されたアルゴリズムを実装します。 SDS の更新ごとに安全なタイムアウトで UpdateProduction を呼び出せます。 それぞれのコードの更新については更新ストラテジーを決定する必要があります。

git diffs を使ってコンパイルされるコードの量を最小限に抑えると、コンパイル時間の軽減に役立ちますが、コードをそのコード自体で「更新」して再コンパイルするか、同じ値で設定を「更新」するとプロダクションの更新はトリガーされないか不要となります。

ビジネスルール、ルーティングルール、および DTL を更新してコンパイルすると、プロダクションを更新せずにすぐにアクセス可能になります。

最後に、プロダクションの更新は安全な操作であり、通常、停止は必要ありません。

リンク

• Ens.Director
• git diff のビルド
• システムデフォルト設定

この記事の執筆において貴重な支援を提供してくださった @James MacKeith、@Dmitry Zasypkin、および @Regilo Regilio Guedes de Souza に感謝申し上げます。

コミュニティの皆さんこんにちは。

突然ですが、皆さんはIRISの機能にある「ユニットテスト」は利用されているでしょうか。
筆者はまだ実装まで行えていませんが、各関数の品質保証を担保するため導入を検討している段階です。

現状、IRISのユニットテストには下記２点の対応すべき点があると考えています。

1. テスト結果の可読性が低い(先日vscodeで拡張機能が出ていましたが、やはり見ずらいと感じました)
2. ユニットテストを自動で実行する手段がない

特にテストが継続的に自動で実施されないと、ユニットテスト自体が次第に陳腐化し、実行されなくなり忘れ去られる恐れがあると考えます。
ただし、意味もなく定期的にテストを実行しても効果がありません。
そこで、Gitのpushのタイミングで行おうと考えました。

次にテスト環境です。
テスト環境の構築は、テスト自動化の観点からみるとCI/CDツール等を利用するのが一般的だと思います。
ただ今回は、テスト環境の構築を簡易にすませたいと考え、IRISの既存技術を組み合わせて構築しようと考えました。

そこで運用幅の広いInteroperabilityとユニットテストを組み合わせて、テストの自動化が可能か考察していきたいと思います。

【ユニットテスト全体概要】

【全体の流れ】

　■ユーザの開発環境

　　①ユーザは改修したクラスをGitへpushする

　■Git用のサーバ

Git を使用してIRIS でソリューションを構築することは、素晴らしいことです！ 単にローカルの git リポジトリにVSCodeを使用し、サーバーに変更をプッシュする... それは非常に簡単です。

でも、次の場合はどうでしょうか。

• 共有リモート開発環境で他の開発者と共同作業を行い、同じファイルの同時編集を回避したい場合
• BPL、DTL、ピボット、ダッシュボードなどにおいて管理ポータルに基づくエディターを使用しており、 作業に簡潔なソース管理を使用したい場合
• 一部の作業においては引き続き Studio を使用しているかたまに VSCode から Studio に戻っているか、チームがまだ VSCode を完全に採用しておらず、一部のチームメンバーが Studio の使用を希望している場合
• 同じネームスペースで同時に多数の独立したプロジェクト（InterSystems Package Manager を使って定義された複数のパッケージなど）に取り組んでおり、（多数の個別のプロジェクトではなく）1 つの isfs 編集ビューからすべてのプロジェクトの作業を行い、適切な git リポジトリで変更を自動的に追跡する場合

開発者の皆さん、こんにちは！

多くの方が、Open Exchange と GitHub で InterSystems ObjectScript ライブラリを公開しています。

でも、開発者がプロジェクトの使用とコラボレーションを簡単に行えるようにするにはどうしていますか？

この記事では、ファイルの標準セットをリポジトリにコピーするだけで、ObjectScript プロジェクトを簡単に起動して作業する方法をご紹介します。

では始めましょう！

概要 - 以下のファイルをこちらのリポジトリからお使いのリポジトリにコピーしてください。

Dockerfile

docker-compose.yml

Installer.cls

iris.script

settings.json{#9f423fcac90bf80939d78b509e9c2dd2-d165a4a3719c56158cd42a4899e791c99338ce73}

.dockerignore{#f7c5b4068637e2def526f9bbc7200c4e-c292b730421792d809e51f096c25eb859f53b637}
.gitattributes{#fc723d30b02a4cca7a534518111c1a66-051218936162e5338d54836895e0b651e57973e1}
.gitignore{#a084b794bc0759e7a6b77810e01874f2-e6aff5167df2097c253736b40468e7b21e577eeb}

すると、プロジェクトを起動して共同作業する標準的な方法が得られます。 以下は、この仕組みと動作する理由についての記事です。

注意: この記事では、InterSystems IRIS 2019.1 以降で実行可能なプロジェクトを対象としています。

InterSystems IRIS プロジェクトの起動環境の選択

通常、開発者には、プロジェクト/ライブラリを試して、素早く安全な方法であることを確認していただきたいと思っています。

私見としては、新しいものを素早く安全に起動するには、Docker コンテナが理想的だと考えています。起動、インポート、コンパイル、計算するあらゆるものがホストマシンにとって安全であり、いかなるシステムやコードも破壊されたり損なわれたりすることがないことを開発者に保証できるためです。 何らかの問題が発生した場合は、コンテナを止めて削除するだけで済みます。 アプリケーションが膨大なディスクスペースを占有するのであれば、コンテナを削除すれば、容量を解放できます。 アプリケーションがデータベース構成を破損するのであれば、破損した構成のあるコンテナを削除するだけです。 このように単純で安全なのです。

Docker コンテナでは、安全と標準化を得られます。

バニラ InterSystems IRIS Docker コンテナを実行するには、IRIS Community Edition イメージを実行するのが最も簡単です。

1. Docker デスクトップをインストールします。 

2. OS のターミナルで以下を実行します。

docker run --rm -p 52773:52773 --init --name my-iris store/intersystems/iris-community:2020.1.0.199.0

3. 次に、ホストブラウザで管理ポータルを開きます。

http://localhost:52773/csp/sys/UtilHome.csp

4. または IRIS へのターミナルを開きます。

   docker exec -it my-iris iris session IRIS

5. IRIS コンテナが不要になれば、それを停止します。

   docker stop my-iris

さて、 IRIS を Docker コンテナで実行しますが、 開発者にはコードを IRIS にインストールして、いくらかの設定を行ってほしいと考えているとします。 以下ではこれについて説明します。

ObjectScript ファイルのインポート

最も単純な InterSystems ObjectScript プロジェクトには、クラス、ルーチン、マクロ、グローバルなどの一連の ObjectScript ファイルが含めることができます。 命名規則とフォルダ構造の提案についての記事をご覧ください。

問題は、このコードをどのようにして IRIS コンテナにインポートするかです。

ここで役立つのが Dockerfile です。これを使用して、バニラ IRIS コンテナを取得し、リポジトリから IRIS にすべてのコードをインポートして、必要に応じて IRIS で設定を行います。 リポジトリに Dockerfile を追加する必要があります。

ObjectScript テンプレートリポジトリから取得した Dockerfile を調べてみましょう。

ARG IMAGE=store/intersystems/irishealth:2019.3.0.308.0-community
ARG IMAGE=store/intersystems/iris-community:2019.3.0.309.0
ARG IMAGE=store/intersystems/iris-community:2019.4.0.379.0
ARG IMAGE=store/intersystems/iris-community:2020.1.0.199.0
FROM $IMAGE

USER root

WORKDIR /opt/irisapp
RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp

USER irisowner

COPY  Installer.cls .
COPY  src src
COPY iris.script /tmp/iris.script # run iris and initial 

RUN iris start IRIS \
    && iris session IRIS < /tmp/iris.script

最初の ARG の行は $IMAGE 変数を設定しており、それを FROM で使用します。 これは、$IMAGE 変数を変更するために FROM の前の最後の行が何であるかだけを切り替えて、さまざまな IRIS バージョンでコードをテスト/実行するのに適しています。 

以下のコードがあります。 

ARG IMAGE=store/intersystems/iris-community:2020.1.0.199.0

FROM $IMAGE

これは、IRIS 2020 Community Edition ビルド 199 を使用するということです。

リポジトリからコードをインポートするため、リポジトリのファイルを Docker コンテナにコピーする必要があります。 以下の行はそれを行います。

USER root

WORKDIR /opt/irisapp
RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp

USER irisowner

COPY  Installer.cls .
COPY  src src

USER root - ここで、ユーザーをルートに切り替えて、フォルダを作成してファイルを Docker にコピーします。

WORKDIR /opt/irisapp - この行では、ファイルをコピーする workdir をセットアップしています。

RUN chown ${ISC_PACKAGE_MGRUSER}:${ISC_PACKAGE_IRISGROUP} /opt/irisapp   -  ここでは、irisowner ユーザーと IRIS を実行するグループに権限を付与しています。

USER irisowner - ユーザーを root から irisowner に切り替えます。

COPY Installer.cls .  - workdir のルートに Installer.cls をコピーしています。 このピリオドを忘れないでください。

COPY src src - ソースファイルをリポジトリの src フォルダから Docekr の workdir の src フォルダにコピーします。

次のブロックでは、初期スクリプトを実行し、インストーラーと ObjectScript コードを呼び出します。

COPY iris.script /tmp/iris.script # run iris and initial 
RUN iris start IRIS \
    && iris session IRIS < /tmp/iris.script

COPY iris.script / - iris.script をルートディレクトリにコピーします。 コンテナをセットアップするために呼び出す ObjectScript が含まれます。

RUN iris start IRIS</span>  - IRIS を起動します。

&& iris session IRIS < /tmp/iris.script - IRIS ターミナルを起動し、それに最初の ObjectScript を入力します。

以上です！ Docker にファイルをインポートする Dockerfile ができました。 installer.cls と iris.script の 2 つのファイルが残っています。ではそれらを詳しく見てみましょう。

Installer.cls

Class App.Installer
{

XData setup
{
<Manifest>
  <Default Name="SourceDir" Value="#{$system.Process.CurrentDirectory()}src"/>
  <Default Name="Namespace" Value="IRISAPP"/>
  <Default Name="app" Value="irisapp" />

  <Namespace Name="${Namespace}" Code="${Namespace}" Data="${Namespace}" Create="yes" Ensemble="no">

    <Configuration>
      <Database Name="${Namespace}" Dir="/opt/${app}/data" Create="yes" Resource="%DB_${Namespace}"/>

      <Import File="${SourceDir}" Flags="ck" Recurse="1"/>
    </Configuration>
    <CSPApplication Url="/csp/${app}" Directory="${cspdir}${app}"  ServeFiles="1" Recurse="1" MatchRoles=":%DB_${Namespace}" AuthenticationMethods="32"
       
    />
  </Namespace>

</Manifest>
}

ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 3, pInstaller As %Installer.Installer, pLogger As %Installer.AbstractLogger) As %Status [ CodeMode = objectgenerator, Internal ]
{
  #; Let XGL document generate code for this method. 
  Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "setup")
}

}

率直に言って、ファイルのインポートに Installer.cls は必要ありません。 これは 1 行で実行可能です。 ただし、コードをインポートするほかに、CSP アプリのセットアップ、セキュリティ設定の追加、データベースとネームスペースの作成を行わなければなりません。

この Installer.cls では、 IRISAPP という名前で新しいデータベースとネームスペースを作成し、このネームスペースのデフォルトの /csp/irisapp アプリケーションを作成します。

すべては、<Namespace> 要素で行います。

<Namespace Name="${Namespace}" Code="${Namespace}" Data="${Namespace}" Create="yes" Ensemble="no">

    <Configuration>
      <Database Name="${Namespace}" Dir="/opt/${app}/data" Create="yes" Resource="%DB_${Namespace}"/>

      <Import File="${SourceDir}" Flags="ck" Recurse="1"/>
    </Configuration>
    <CSPApplication Url="/csp/${app}" Directory="${cspdir}${app}"  ServeFiles="1" Recurse="1" MatchRoles=":%DB_${Namespace}" AuthenticationMethods="32"
       
    />
  </Namespace>

そして、Import タグを使って、SourceDir からすべてのファイルをインポートします。

<Import File="${SourceDir}" Flags="ck" Recurse="1"/>

この SourceDir は変数であり、現在のディレクトリ/src フォルダに設定されています。

<Default Name="SourceDir" Value="#{$system.Process.CurrentDirectory()}src"/>

これらの設定を含む Installer.cls によって、src フォルダから任意の ObjectScript コードをインポートするわかりやすい新しいデータベース IRISAPP を作成できるという確信を持つことができます。

iris.script

ここに、IRIS コンテナを起動する初期の ObjectScript セットアップコードを挿入してください。

例: 開発にはパスワードのプロンプトは不要であるため、ここでは、installer.cls を読み込んで実行してから、パスワードの初回変更リクエストを回避するために、UserPasswords を永久にしています。

; run installer to create namespace
do $SYSTEM.OBJ.Load("/opt/irisapp/Installer.cls", "ck")
set sc = ##class(App.Installer).setup()  zn "%SYS"
Do ##class(Security.Users).UnExpireUserPasswords("*") ; call your initial methods here
halt

docker-compose.yml

docker-compose.yml はなぜ必要なのでしょうか。Dockerfile と同様に、イメージをただビルドして実行するだけではいけないのでしょうか。 もちろん、そうすることは可能です。 ただし、docker-compose.yml を使用すれば作業が単純になります。

通常、docker-compose.yml は、1 つのネットワークに接続された複数の Docker イメージを起動するために使用されます。

docker-compose.yml は、多数のパラメーターを処理する場合に、1 つの Docker イメージの起動をより簡単にするためにも使用できます。 これを使用すれは、ポートのマッピング、ボリューム、VSCode 接続パラメーターなどを Docker に渡すことができます。

version: '3.6' 
services:
  iris:
    build: 
      context: .
      dockerfile: Dockerfile
    restart: always
    ports: 
      - 51773
      - 52773
      - 53773
    volumes:
      - ~/iris.key:/usr/irissys/mgr/iris.key
      - ./:/irisdev/app

ここでは、サービス iris を宣言しています。これは Dockerfile を使用し、IRIS の 51773、52773、53773 ポートを公開するサービスです。 また、このサービスは、ホストマシンのホームディレクトリの iris.key と期待される IRIS フォルダ、およびソースコードのルートフォルダと /irisdev/app フォルダの 2 つのボリュームのマッピングも行います。

docker-compose によって、セットアップされるパラメーターに関係なく、イメージをビルドして実行するためのコマンドをより短く、統一することができます。

いずれの場合でも、以下のようにしてイメージをビルドします。

$ docker-compose up -d

 そして以下のようにして IRIS ターミナルを開きます。

$ docker-compose exec iris iris session iris

Node: 05a09e256d6b, Instance: IRIS

USER>

また、docker-compose.yml では、VSCode ObjectScript プラグインの接続もセットアップできます。

.vscode/settings.json

ObjectScript アドオン接続設定に関連しているのは、以下の部分です。

{
    "objectscript.conn" :{
      "ns": "IRISAPP",
      "active": true,
      "docker-compose": {
        "service": "iris",
        "internalPort": 52773
      }
    }     

}

ここにあるのは設定です。VSCode ObjectScript プラグインのデフォルトの設定とは異なります。

ここでは、IRISAPP ネームスペース（Installer.cls で作成）に接続すると述べています。

"ns": "IRISAPP",

そして、docker-compose の設定があります。これは、サービス「iris」内の docker-compose ファイルで、VSCode が 52773 がマッピングされているポートに接続すると書かれています。

"docker-compose": {
        "service": "iris",
        "internalPort": 52773
      }

52773 について調べたところ、これはマップされたポートが 52773 に対して定義されていないことがわかります。

ports: 
      - 51773
      - 52773
      - 53773

つまり、ホストマシンのポートで利用できるランダムなポートが取得され、VSCode は自動的にランダムなポートを介して、docker 上でこの IRIS に接続するということです。

これは非常に便利な機能です。IRIS を使用して任意の量の Docker イメージをランダムなポート上で実行し、VSCode をそれらのポートに自動的に接続するオプションが提供されるためです。

他のファイルはどうでしょうか？

以下のファイルもあります。

.dockerignore  - 作成した Docker ファイルにコピーしない不要なホストマシンのファイルをフィルターするために使用できるファイル。 通常、.git や .DS_Store は必須です。

.gitattributes - git の属性。ソース内の ObjectScript ファイルの行末を統一します。 Windows と Mac/Ubuntu オーナーがリポジトリで共同作業する場合に非常に便利です。

.gitignore - Git で変更履歴を追跡しないファイル。 通常、.DS_Store などの非表示の OS レベルのファイルです。

以上です！

リポジトリを Docker 実行可能にし、コラボレーションしやすくするにはどうすればよいでしょうか。

1. このリポジトリをクローンします。

2. 以下のファイルをすべてコピーします。

Dockerfile

docker-compose.yml

Installer.cls

iris.script

settings.json{#9f423fcac90bf80939d78b509e9c2dd2-d165a4a3719c56158cd42a4899e791c99338ce73}

.dockerignore{#f7c5b4068637e2def526f9bbc7200c4e-c292b730421792d809e51f096c25eb859f53b637}
.gitattributes{#fc723d30b02a4cca7a534518111c1a66-051218936162e5338d54836895e0b651e57973e1}
.gitignore{#a084b794bc0759e7a6b77810e01874f2-e6aff5167df2097c253736b40468e7b21e577eeb}

上記をリポジトリにコピーしてください。

Dockerfile のこの行を IRIS にインポートする ObjectScript のあるリポジトリ内のディレクトリに一致するように変更します（in /src フォルダにある場合は変更しません）。

それだけです。 すべての人（あなた自身も含む）が、新しい IRISAPP ネームスペースでコードをインポートできるようになります。

プロジェクトの起動方法

IRIS で ObjectScript プロジェクトを実行するためのアルゴリズムは以下の通りです。

1. プロジェクトをローカルに Git clone します。

2. プロジェクトを実行します。

$ docker-compose up -d

$ docker-compose exec iris iris session iris

Node: 05a09e256d6b, Instance: IRIS

USER>zn "IRISAPP"

**開発者によるプロジェクトへの貢献方法 **

1. リポジトリをフォークして、フォークされたリポジトリをローカルに Git clone します。

2. VSCode でフォルダを開きます（Docker と ObjectScript の拡張機能が VSCode にインストールされている必要があります）。

3. docker-compose.yml を右クリックし、再起動します。VSCode ObjectScript が自動的に接続され、編集/コンパイル/デバッグできるうようになります。

4. リポジトリに変更をコミット、プッシュ、およびプルリクエストします。

以下は、この仕組みを説明する簡単な Gif です。

以上です！ それでは、コーディングをお楽しみください！

開発者のみなさん、こんにちは。

vscode上で動作するObjectScriptエクステンションがリリースされ、vscodeを開発環境として使用できるようになり、GitHubリポジトリと連携できるようになりました。その一方で、使い慣れたIRISやCacheのスタジオからGitHubを扱いたいという要望は根強くあり、GitHubと連携するツールがOpen Exchange上にいくつか公開されています。

そこで、Open exchangeに収録されているツールの中で新しい「git for shared development environment」を使い、環境を作成してみましたので、その手順をお伝えします。

ご利用される際のご参考になれば幸いです。

Git for windows のインストール

Git for windows のサイト よりキットをダウンロードし、そのexeファイル (git-2.xx.xx xx-bit.exe) を起動します。ライセンスの確認画面が表示されますので、「Install」ボタンをクリックします。

SSHキーペアの作成

コマンドプロンプトを起動し、ssh-keygen コマンドを実行します。

こんにちは、皆さま。
業務でIRISを用いて開発を行っている者です。

技術文書ライティングコンテストという事で、私からはAWS環境を用いたCI/CDの仕組みについてご紹介します。

CI/CDとは「Continuous Integration（継続的インテグレーション）/ Continuous Delivery（継続的デリバリー）」の略称で、
詳細はネットをググると色々出てくると思いますが、私としてはリポジトリに格納されたものを自動で品質保証して、
問題なければ自動でデプロイしてくれる一連の仕組みだと理解しています。

という事で、その第一歩はIRISのソースコードをgitで管理することです。
pythonで作成したテストプログラムを用意しました。

開発者の皆さん、こんにちは！

ご存知のように、InterSystems IRIS インターオペラビリティソリューションには、プロダクション、ビジネスルール、ビジネスプロセス、データ変換、レコードマッパーなどの様々なエレメントが含まれています。 また、UI ツールを使用してこれらの要素を作成し、変更することもあります。  もちろん、UI ツールで行った変更をソース管理する便利で堅牢な方法も必要です。

長い間、これは手動（クラス、エレメント、グローバルなどのエクスポート）か面倒な設定作業手順によって行われてきました。そのため、ソース管理 UI の自動化で節約された時間は、設定のセットアップとメンテナンスの時間で相殺されていました。

現在では、この問題はなくなりました。 パッケージファースト開発と @Timothy Leavitt の git-source-control という IPM パッケージの使用という 2 つのアプローチによる結果です。

詳細は以下のとおりです！

免責事項: これは、インターオペラビリティのプロダクションのエレメントがリポジトリ内のファイルである場合の、クライアント側の開発アプローチに関連しています。

よって、ソリューションは非常に単純であるため、この記事は長くありません。

Docker で開発しており、IRIS を使って開発環境の Docker イメージをビルドしたら、ソリューションを IPM モジュールとして読み込んでいるとします。 これは、「パッケージファースト」開発と呼ばれ、関連する動画や記事が存在する手法です。 基本的には、開発環境の Docker イメージを IRIS でビルドすると、クライアントのサーバーにデプロイされるときに、ソリューションがパッケージとして読み込まれるという考え方になります。

ソリューションのパッケージファースト開発環境を作るには、module.xml をリポジトリに追加し、そのすべての要素を記述して、Docker イメージのビルドフェーズで「zpm load "repository/folder"」コマンドを呼び出します。

この考え方を、サンプルテンプレートの IRIS Interoperability template とそれに使用する module.xml を使って示しましょう。 パッケージは、Docker ビルド中に以下のように読み込まれています。

zpm "load /home/irisowner/irisdev/ -v":1:1

ソース 

パッケージソース管理を読み込む前に配置された以下の 2 行を見てください。 これにより、ソース管理はパッケージ内のすべての相互運用性要素に対して自動的に動作し始め、適切なフォルダに適切な形式でエクスポートされます。

zpm "install git-source-control"do##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

ソース

仕組み

最近、git-source-control アプリは、開発モードで読み込まれるソース管理用の IPM パッケージをサポートするようになりました。 エクスポートするフォルダを読み取り、module.xml からソースの構造をインポートします。 詳細は、@Timothy Leavitt が説明できます。

ターミナルで、環境がビルドされた後の IPM モジュールのリストを確認すると、読み込まれたモジュールが実際に開発モードになっているのが分かります。

USER>zpm=============================================================================
|| Welcome to the Package Manager Shell (ZPM).                             ||
|| Enter q/quit to exit the shell. Enter ?/help to view available commands ||
=============================================================================
zpm:USER>list
git-source-control      2.1.0
interoperability-sample 0.1.2 (DeveloperMode)
sslclient               1.0.1
zpm:USER>

では試してみましょう。 

このリポジトリをクローンし、VSCode で開いてイメージをビルドしました。 以下では、相互運用性 UI とソース管理をテストしています。 UI に変更を加えるとすぐに、ソースと差分に表示されます。

できました！ それだけです！ 

まとめると、プロジェクトで相互運用性 UI 要素のソース管理を行うには、以下を行います。

1. Docker イメージをビルド中に、iris.script に 2 行を追加します。

zpm "install git-source-control"do##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

その後、以下のようにして、ソリューションをモジュールとして読み込みます。

zpm "load /home/irisowner/irisdev/ -v":1:1

2. または、Interoperability template からリポジトリを作成して新規に始めることもできます。

お読みいただきありがとうございました！ コメントやフィードバックをお待ちしています！

皆さんこんにちは！

この記事でご紹介する「開発環境テンプレート」は、最近 医療 IT で注目を集めている 医療情報交換標準規格  FHIRを体験できるコンテナです。

一式は、こちら（https://github.com/Intersystems-jp/IRIS-FHIR-Oximeter-Template）で公開しています。

コンテナビルド時、InterSystems IRIS for Health コミュニティエディションを使用した FHIR R4 リソースリポジトリの用意と、REST 用エンドポイントが用意されます。

作成されるエンドポイントに対して、REST クライアントから直接 FHIR R4 リソースリポジトリへアクセスすることもできますし（使用例はこちら／ビデオの解説はこちら）、Patient リソースと Observation リソースの操作体験が行えるサンプル Web アプリケーション（使用例はこちら／ビデオの解説はこちら）もコンテナに含まれていますので、お好みの方法で操作を体験できます。

この開発環境テンプレートでは、さらに！ FHIR  サーバーサイドアプリケーション（＝プロダクション）のサンプルも用意しています（図例はこちら）。

プロダクションは、新生児につけたパルスオキシメーターの測定値が定期的に送信されてくることを仮定して作られています。

開発者の皆さん、こんにちは！

この記事では、【GettingStarted with IRIS】シリーズの MQTT アダプタを簡単に試せるサンプルの利用方法についてご紹介します！

（MQTTブローカーはインターネット上に公開されているテスト用ブローカーを利用しています）​​

サンプルは、こちら👉https://github.com/Intersystems-jp/Samples-MQTT-EKG-Devices　（コンテナで動作します）

IRIS／IRIS for Health のバージョン2020.1から、IoT の世界でよく利用される MQTT プロトコルに対応できる MQTT アダプタが追加されました。

MQTTインバウンドアダプタでは、メッセージの Subscribe が行え、MQTTアウトバンドアダプタでは、メッセージの Publish が行えます。

サンプルでは、MQTT を使った遠隔モニタリングをテーマに、患者さんに装着した心電図から心拍数（BPM）をリアルタイムに近い状態で取得し、モニタ画面に患者さん毎の心拍数を表示します（IRIS の MQTT インバウンドアダプタを利用したメッセージの Subscribe をご体験いただけます）。

Publish されるトピックについて

サンプルでは、演習環境毎にユニークになるようにコンテナ開始時に以下の形式でトピックを作成しています（末尾の # はワイルドカードの指定です）。

/Student_4629/acmeHospital/EKG/#

実際に Publish されるトピックは患者さんに装着した心電図のデータになるので、# の部分は、Patient-1 や Patient-2 などのように患者さんを特定できる文字列が入ります。

サンプルのシナリオは、1つの医療機関の患者情報を取得する流れにしています（本来であれば複数の医療機関の患者情報をモニタできるようにしたほうが良いのですがシンプルに試すため、1つの医療機関の患者情報を取得する流れにしています）。

トピックの流れ

サンプルには1つHTMLファイルが用意されています。このファイルをブラウザで開くと MQTT ブローカーに接続し、データ（心拍数）を1秒ごとにブローカーへ Publish します。

IRIS は、MQTTブローカーから指定のトピックを Subscribe します。

​​​

MQTT ブローカーを Subscribe する設定を行った IRIS のサービスは、ブローカーからトピックを取得します。

実際の設定は以下の通りです。

受信したトピックは IRIS の中では​​​メッセージ（EnsLib.MQTT.Message）として扱われ、次のコンポーネントであるプロセス（図では Process_MQTT_Request）に渡します。

プロセスでは、受信した MQTT 用メッセージからモニタ表示に利用するデータ（Solution.HeartRate）に変換するため、データ変換を呼び出します。

プロセスエディタの開き方と、中で行われているデータ変換の呼び出しの設定を確認する方法は以下の通りです。

患者ごとの測定値を参照する流れ

MQTT ブローカーから Subscribe した心拍数をリアルタイムに近い状態で画面表示するため、データ変換で作成された Solution.HeartRate から1秒ごとに患者ごとの心拍数を収集し、画面に表示しています。

この表示を行うため、1秒間隔で Solution.HeartRate に対するSELECT文が実行されています。

このクエリを実行しているのが、メトリックと呼ぶクラスです。プロダクションでは以下の場所に設定されています。

メトリックでは、指定の呼び出し間隔で Solution.HeartRate から患者ごとの BPM を収集しています。詳細はソースコードをご参照ください。

リモートや在宅での勤務が一般化しつつあります。

そのため、今までの集中型、オンサイトの開発体制を見直し、分散型の開発体制への移行を進めておられるユーザさんも多いのではないかと思います。

VSCodeを使用したIRISアプリケーションの開発が、コミュニティーを中心に広まり始めて久しいですが、Gitとの相性が良いこの開発ツールが今後さらに浸透していくことは間違いありません。あちらこちらで、その使いまわし方が語られていますが、ここでは、ソースコントロールとの関連を中心にご紹介したいと思います。

ObjectScript Extensionの使い方の基本については、こちらやこちらをご覧ください。

 VSCode InterSystems ObjectScript Extensionのプロダクションリリース(V1.0.x)の配布が始まりました。  

これに合わせて、今までのコミュニティーサポートに加え、InterSystemsによる公式サポートもアナウンスされています。よりいっそう安心してご利用いただけるようになりました。

目的

開発者のみなさん、こんにちは！

インターシステムズは、2020年7月21日（火）に オンラインにて開催された開発者向けイベント「Developers Summit 2020 Summer」（主催：翔泳社）に協賛し、セミナーで IRIS プログラミングコンテストについてご紹介しました。

ご紹介内容は、コンテストに限らず、コンテナを使用した開発環境の整備にも使えますので、セミナーを見逃された方もぜひご覧ください！

もくじ

※　YouTubeでご覧いただくと目次の秒数にジャンプできます。

0:00～　InterSystems が開催しているプログラミングコンテストの概要

2:38～　本セッションの目標

4:21～　≪腕試しの準備その1≫開発環境の「テンプレート」で何が提供されるか

8:26～　テンプレート起動迄の手順（各コンテスト共通）

10:02～　優勝作品のご紹介（2020年5月分開催　Native APIの回）

• Banzaiさんの作品
• OpenExchangeトップページ

11:40～　≪腕試しの準備その２≫ご応募までの実際の流れ
　RESTサーバ作成用のテンプレート

13:00～　テンプレートで準備されるREST サーバ作成環境について

16:47～　テンプレートの中身解説＋コンテナの開始とサンプルコードの実行（実演）

23:02～　GET要求　/test で動作する testMethod()の追加と実行

​​​​​​この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けていくつかの可能性のあるアプローチを紹介し、説明したいと思います。以下のようなトピックについて取り上げます。

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 
• コンテナを使用する理由 
• コンテナインフラストラクチャ 
• コンテナを使用したCD 
• ICMを使用したCD 
• コンテナアーキテクチャ 

この記事では、独自のコンテナを構築してデプロイ展開する方法について説明します。 

Durable %SYS 

コンテナは一時的なものなので、アプリケーションデータを保存するべきではありません。Durable %SYS の機能により設定、構成、 %SYSデータなどをホストボリュームに保存することができます。

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けていくつかの可能性のあるアプローチをを紹介し、議論したいと思います。 今回は以下のようなトピックを取り上げます。 

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 
• コンテナを使用する理由 
• コンテナインフラストラクチャ 
• コンテナを使用したCD 
• ICMを使用したCD 

この記事では、InterSystems Cloud Managerを使用して継続的デリバリーを構築ドします。 ICMは、InterSystems IRISをベースとしたアプリケーション用のクラウドプロビジョニングおよびデプロイメントソリューションです。これにより、 必要なデプロイ構成を定義することができ、ICMが自動的にプロビジョニングします。 詳細については、First Look: ICM をご覧ください。

 ワークフロー

継続的デリバリーの構成では、次のようになります。

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 
• コンテナを使用する理由 
• コンテナインフラストラクチャ 
• コンテナを使用したCD 

第1回の記事では、Gitの基本、Gitの概念を高度に理解することが現代のソフトウェア開発にとって重要である理由、Gitを使用してソフトウェアを開発する方法について説明しています。

第2回の記事では、ソフトウェアのライフサイクルの完全なプロセスであるGitLabワークフローについて説明しています。

第3回の記事では、GitLabのインストールと構成ならびに利用環境のGitLabへの接続について説明しています。

第4回の記事では、CDの構成を説明しています。

第5回の記事では、コンテナとその使用方法（および使用する理由）について説明しています。

第6回の記事では、コンテナを使用して継続的デリバリーのパイプラインを実行する必要がある主なコンポーネントと、それらすべての連携の仕組みについて説明しています。  

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。 

誰もがテスト環境を持っています。  
本番環境とは完全に独立した実行環境を持てるほど幸運な人もいます。  
-- 作者不明 

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。 

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• GitLab CI/CD 
• CI/CDとコンテナ 

この最初のパートでは、最新のソフトウェア開発の基礎であるGitバージョン管理システムとさまざまなGitフローを扱います。 

Git 101  

これから説明する主なトピックでは、後の概念をより良く理解できるようにするため、ソフトウェア開発全般とGitlabがその取り込みにどのように役立っているのか、Git、あるいはもっと厳密に言えば重要なGit設計の基礎となる複数の高度な概念を取り上げます。 

そして、Gitは以下のようなアイデア（他にもたくさんありますが、これらが最も重要なアイデアです）に基づいたバージョン管理システムです。 

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。 

• Git 101 
• Git Flow（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 
• コンテナを使用する理由 
• コンテナインフラストラクチャ 
• コンテナを使用するGitLab CI/CD 

第1回の記事では、Gitの基本、Gitの概念を高度に理解することが現代のソフトウェア開発にとって重要である理由、Gitを使用してソフトウェアを開発する方法について説明しています。

第2回の記事では、アイデアからユーザーフィードバックまでの完全なソフトウェアライフサイクルプロセスであるGitLabワークフローについて説明しています。

第3回の記事では、GitLabのインストールと構成ならびに利用環境のGitLabへの接続について説明しています。

第4回の記事では、CDの構成を作成しています。

第5回の記事では、コンテナとその使用方法（および使用する理由）について説明しています。

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。 

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 

第1回の記事では、Gitの基本、Gitの概念を高度に理解することが現代のソフトウェア開発にとって重要である理由、Gitを使用してソフトウェアを開発する方法について説明しました。 

第2回の記事では、アイデアからユーザーフィードバックまでの完全なソフトウェアライフサイクルプロセスであるGitLabワークフローについて説明しました。 

第3回の記事では、GitLabのインストールと構成ならびに利用環境のGitLabへの接続について説明しました。 

この記事では、最終的にCDの構成を作成します。 

計画 

環境 

まず、いくつかの環境とそれに対応するブランチが必要です。

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。 

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 

第1回の記事では、Gitの基本、Gitの概念を高度に理解することが現代のソフトウェア開発にとって重要である理由、Gitを使用してソフトウェアを開発する方法について説明しています。

第2回の記事では、アイデアからユーザーフィードバックまでの完全なソフトウェアライフサイクルプロセスであるGitLabワークフローについて説明しています。 

この記事では以下について説明します。 

• GitLabのインストールと構成 
• 利用環境のGitLabへの接続 

GitLabのインストール 

GitLabをオンプレミス環境にインストールします。 GitLabのインストール方法は多彩で、ソースやパッケージからインストールしたり、コンテナーにインストールしたりできます。 ここではすべての手順を実際に説明するつもりはありませんが、そのためのガイドを紹介します。 ただし、それでもいくつか注意すべき点があります。 

前提条件： 

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。 

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 
• コンテナを使用する理由 
• コンテナを使用するGitLab CI/CD 

第1回の記事では、Gitの基本、Gitの概念を高度に理解することが現代のソフトウェア開発にとって重要である理由、Gitを使用してソフトウェアを開発する方法について説明していますました。 

第2回の記事では、アイデアからユーザーフィードバックまでの完全なソフトウェアライフサイクルプロセスであるGitLabワークフローについて説明しています。 

第3回の記事では、GitLabのインストールと構成ならびに利用環境のGitLabへの接続について説明しています。 

第4回の記事では、CDの構成を作成しています。 

この記事では、コンテナとその使用方法（および使用する理由）について説明します。 

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。 

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 

前の記事では、Gitの基本、Gitの概念を高度に理解することが現代のソフトウェア開発にとって重要である理由、Gitを使用してソフトウェアを開発する方法について説明しました。 なお、前の記事ではソフトウェア開発の実装部分を中心に取り扱っていましたが、このパートでは以下を取り扱います。 

• GitLabワークフロー - アイデアからユーザーフィードバックまでの完全なソフトウェアライフサイクルプロセス。 
• 継続的デリバリー - チームが短いサイクルでソフトウェアを作成し、ソフトウェアをいつでも確実にリリースできるようにするソフトウェアエンジニアリング手法です。 この手法はソフトウェアの構築、テスト、リリースをより速く、より頻繁に行うことを目指しています。 

GitLabワークフロー 

GitLabワークフローは、ソフトウェア開発プロセスのライフサイクル全体で実行可能な操作を論理的に並べたものです。