InterSystems IRIS、InterSystems IRIS for Health 和 HealthShare Health Connect 的最新扩展维护版本现已发布。
版本 2024.1.3 修复了 2024.1.x 上一版中的 bug，包括针对最近发布的以下提醒的修复 – 提醒：在执行特定的操作时，数据库和日志文件中引入了无效数据…。
您可以在以下页面上找到详细的变更列表和升级核对清单：
软件以经典安装包和容器镜像两种形式提供。有关可用安装程序和容器镜像的完整列表，请参阅支持的平台网页。
InterSystems IRIS 和 InterSystems IRIS for Health 的完整安装包可从本 WRC 的 InterSystems IRIS 数据平台完整套件页面获取。 HealthShare Health Connect 套件可从 WRC 的 HealthShare 完整套件页面获取。
容器镜像可通过 InterSystems 容器注册表获取。
这些版本中的所有套件和容器的编号为：
✓ 一月有 24 位新成员加入
✓ 所有时间发布了 2,349 篇帖子
✓ 所有时间有 2,123 位成员加入
✓ 2024 年有 476 位成员加入开发者社区
✓ 总共发布了 2,342 篇帖子
✓ 总共有 17,544 位成员加入
InterSystems 已更正导致在使用特定 $LIST 语法时引入无效数据库和日志记录的缺陷。 遇到此缺陷的可能性非常低，但它对操作的影响可能会很大。
受影响的产品
该问题仅影响 Unicode 安装。
使用以下语法在 global 中向列表附加新元素时，会出现此问题：
SET $LIST(<global reference>, *+1) = value.
当此调用的结果列表超出最大字符串长度时，正确的行为是返回 <MAXSTRING> 错误。此错误会出现在 InterSystems IRIS、InterSystems IRIS for Health 和 Health Connect 2023.3 之前的版本中。 在 2023.3 及后续版本中，无效值会保存到数据库而不是生成 <MAXSTRING> 错误.
任何后续引用 global 节点的尝试都会导致出现 <MAXSTRING> 错误。
global 更新也会产生日志记录（假设对此 global 的更新通常都会记录）。任何尝试应用生成的日志记录（包括启动时恢复、日志恢复和镜像操作）都会失败并出现 <MAXSTRING> 错误，同时停止对日志文件的进一步处理。
如果此缺陷给您带来了影响，请联系全球响应中心 (WRC) 寻求帮助。
此缺陷的更正标识为 DP-437169 。在从 InterSystems IRIS、InterSystems IRIS for Health 和 Health Connect 2024.1.3 与 2025.1.0 开始的未来所有版本中，都将包含此更正。 您也可以通过临时分发获取。 HealthShare Unified Care Record 2025.1 版与产品套件会在发布时包含该更正，但在先前版本的维护版中将不包含该更正。 如果您对此提醒有任何疑问，请联系全球响应中心。
2024 年 12 月 4 日，系统警报和监视 (SAM) 已从 InterSystems 下载网站、容器注册表和文档网站移除。
InterSystems 去年宣布停止进一步开发 SAM，并同时将其标记为已弃用。InterSystems 将继续按照与超出最低支持版本窗口的产品版本相同的方式为使用此技术的现有客户提供支持。
Intersystems 发现，大多数对 SAM 提供的可观察性类型感兴趣的客户已选择将 InterSystems IRIS 指标 API 和结构化日志记录连接到其组织现有的可观察性平台，以便更全面地了解其运行平台。
如果您对 SAM 当前的使用方式或今后的使用计划有任何疑问，请联系您的客户团队或 dbpprodmgrs@intersystems.com。
我们已经有一段时间没有在开发者社区上发表关于嵌入式 Git 的文章了，我想借此机会更新一下今年我们完成的大量工作以及未来的工作计划。
如果您要在 IRIS 上构建解决方案，并想要使用 Git，那就太棒了！ 只需将 VSCode 与本地 Git 仓库结合使用，并将更改推送到服务器上即可，就是这么简单。
但在以下使用场景中该怎么办：
在以上任何情况下，您都非常需要嵌入式源代码控制。 您可能听说过“服务器端源代码控制”或“源代码控制挂钩”这类叫法，它们的含义相同，都表示可在所有编辑器（包括 IDE 和图形编辑器）中对 IRIS 实例实现一致的源代码控制行为。 所有控制操作都是针对与您的 IRIS 实例位于同一位置的源代码控制仓库执行的，该仓库可能位于远程服务器上、您自己的机器上，甚至可能位于容器中。
如果您希望开始使用 Git 进行嵌入式源代码控制，可以先从嵌入式 Git (https://github.com/intersystems/git-source-control) 着手。 嵌入式 Git 不是 InterSystems 支持的产品，但得到了 InterSystems 内我的团队（应用程序服务团队）和广大用户社区的大力支持。 我们始终欢迎大家提出 PR 和 GitHub 议题，我们会监控开发者社区活动（特别是使用相对较新的“嵌入式 Git”标签）。
2024 年初，我曾向已能轻松使用 Git 并愿意在必要时进行深入研究、更偏向技术型的用户推荐嵌入式 Git。 现在，我极力推荐所有人使用嵌入式 Git。 为了展示我们对此工具倾注的心血以及我们在 2024 年取得的飞跃，下方是过去几年的提交量图：
.png)
如果您想了解我们的最新动态，可以查看版本或我们的变更日志，但下面是对要点的总结：
下一个版本 (2.8.0) 预计在两周内发布，其中将包含我们历经数月开发出的“生产分解”功能。 互操作性生产通常以单个文件的形式进行源代码控制，由于一次只能由一人编辑生产，这会导致并发问题。 共享开发环境中还存在一些合并问题，这些问题几乎一定会出现，虽然我们可以通过智能化方式解决它们，但在某些分支工作流中，这些问题很可能会继续出现。 利用生产分解功能，每个业务主机（服务、进程或操作）在源代码控制中都会以单个文件的形式表示。 如果您有兴趣尝试此功能，请联系我们！
进入 2025 年，我们将继续保持嵌入式 Git 的发展势头，重点关注其他身份验证方法并支持其他常见部署模式。 您可以访问 2025 H1 里程碑了解我们的大致计划（其中包括几次版本发布；我们通常会每月发布次要版本，并根据需要发布补丁版本修复重要错误）。
如果您有兴趣深入了解开发细节/获取最新开发信息，欢迎加入我们每周五召开的利益相关者会议。 此会议也成为了嵌入式 Git 的一种“办公时间”。 请随时留言告诉我您的电子邮件地址，我会邀请您加入会议。
借助 InterSystems 行业标准认证考试，您和您的团队可以获得认证，以验证您的技能并证明您拥有 InterSystems 技术方面的专业知识。 查找适合您的角色的考试！
您知道吗？如果公司中有四或五名员工获得认证，该公司可以获得组织认证！
请发送电子邮件至 certification@intersystems.com 或访问 InterSystems 认证网站获取更多信息。
2024.3 版 InterSystems IRIS® 数据平台、InterSystems IRIS® for Health 和 HealthShare® Health Connect 现已正式发布 (GA)。
在此版本中，您可以期待一系列激动人心的更新，包括：
请通过开发者社区分享您的反馈，与我们共同打造更好的产品。
请访问以下链接了解所有亮点功能的详细信息：
此外，请查看此版本的升级信息。
目前提供多个 EAP。 请查看此页面并注册您感兴趣的计划。
像往常一样，持续交付 (CD) 版本包含适用于所有受支持平台的经典安装包，以及 Docker 容器格式的容器镜像。
安装包可从 WRC 的 InterSystems IRIS、InterSystems IRIS for Health 和 Health Connect持续交付版本页面获取。此外，还可以在评估服务网站获取套件。
此版本提供适用于所有受支持平台的经典安装包，以及 Docker 容器格式的容器镜像。有关完整列表，请参阅“支持的平台”文档。
安装包和预览版密钥可从 WRC 的预览版下载网站或通过评估服务网站获取。
此持续交付版本的版本号为：2024.3.0.217.0。
容器镜像可通过 InterSystems 容器注册表获取。 容器带有 2024.3 或 latest-cd 标签。
InterSystems IRIS® 数据平台、InterSystems IRIS® for Health 和 HealthShare® Health Connect 2025.1 的首个开发者预览版已发布到 WRC 开发者预览网站。容器可在我们的容器注册表中找到，并已添加 latest-preview 标签。
这些开发者预览版包含用于迁移到 IBM Open XL C/C++ for AIX 17.x 编译器的功能，从而在旧版编译器接近支持终止时确保与未来的 AIX 版本兼容。 此迁移侧重于 aixopenssl30 目标，支持 AIX 7.2 和 7.3 上的 SSL3。
可以在以下链接中找到初始文档：
此版本提供适用于所有受支持平台的经典安装包。有关完整列表，请参阅“支持的平台”文档。
安装包和预览版密钥可从 WRC 的预览版下载网站或通过评估服务网站（勾选“Show Preview Software”（显示预览软件）框）获取。
各位社区成员，大家好
🎉 2024 年已接近尾声，是时候庆祝大家的贡献了！ 请在开发者社区上查看您的个性化 2024 年回顾，了解您今年的成就、活动和影响。
深入了解您产生的影响！ 💫
.jpg)
每位成员都可以访问自己的个性化 2024 年活动总结 – 其中概括了他们的贡献，包括帖子数量、评论数量、浏览量、最热门和收藏的帖子/标签等！
您可以直接通过主页访问您的年度回顾（点击“Dive deep!”（深入了解！））：
.png)
您将在其中获得您在开发者社区上的活动总结，并且可以将它分享给您的朋友和同事：
选择您喜爱的社交网络并分享您的年度成就：
.png)
.png)
希望您喜欢您的年度回顾，并在评论中分享您的身份！
✓ 十二月有 29 位新成员加入
✓ 所有时间发布了 2,316 篇帖子
✓ 所有时间有 2,100 位成员加入
✓ 十一月有 32 位新成员加入
✓ 所有时间发布了 2,284 篇帖子
✓ 所有时间有 2,071 位成员加入
各位社区成员，大家好！
我们很高兴推出一种全新的方式让您展示创造力和技能！ 这次，我们邀请您参加我们首次发起的视频挑战：
请在 2024 年 10 月 21 日到 11 月 10 日提交与 InterSystems IRIS 产品或服务相关的任何主题的视频。
🎁 人人有礼 + 主要奖品！
.jpg)
🔍 挑战内容
制作一段短视频（最长 15 分钟），演示 InterSystems 技术的独特运用。无论是创新解决方案、创意项目，还是酷炫的使用案例，都可以参加本次挑战！
📢 参赛方式：
要参加挑战，您需要填写表单，并按照表单要求上传您的视频。 将您的视频上传到开发者社区 YouTube 后，我们将在这篇帖子的评论中发布链接，您可以在任何位置使用此链接。
参与资格：除 InterSystems 员工以外的任何开发者社区成员（欢迎承包商参加挑战。）创建帐户！
注意： 我们的专家小组将根据质量和相关性等标准对视频是否符合参赛资格做出最终决定。 他们的决定是最终决定，不得申诉。
📝 10 月 21 日 - 11 月 10 日：在此期间制作视频并填写表单。开发者社区成员可为参加社区奖项评选的已发布视频投“赞”票。
📝 11 月 11 日 - 17 日：专家投票时间
📝 11 月 18 日：宣布优胜者
奖品
1. 每位参赛者都是获胜者！所有参与者都将获得我们特别准备的礼品：
🎁 耐克高尔夫 Dri-FIT Swoosh 穿孔帽
2. 专家奖项 – 视频将由 InterSystems 专家进行评审：
🥇 第 1 名：10.9 英寸 iPad，Wi‑Fi 版，64GB / 索尼 WH-1000XM5 无线耳机
🥈 第 2 名：Moleskine 15" 立式设备包 //乐高 NASA Artemis 太空发射系统
🥉 第 3 名：具有主动降噪功能的 AirPods 4 / 乐高霍格沃茨™城堡：大厅
作为替代方案，任何优胜者均可从低于自己奖品级别的奖品中选择一个奖品。
3. 开发者社区奖项 – 获得赞数最多的视频。优胜者将可以选择下列奖品之一：
🎁 具有主动降噪功能的 AirPods 4 / 乐高霍格沃兹™城堡：大厅
注意：作者在比赛的每个类别中只能获奖一次（最多可获得两个奖品：一个专家奖，一个社区奖）。 如果出现票数相同的情况，则以专家票数作为决胜标准。
下面列出了可以帮助您赢得奖品的额外奖励！ 请欢迎：
| 奖励 | 提名人数 | 详细信息 |
主题奖励 | 3 | 从下方的建议主题列表中选择一个主题即可获得此奖励。 |
文章奖励 | 3 | 撰写一篇全新的说明性文章为您的视频提供支持，并在其中使用标签 #Video。 |
应用程序奖励 | 5 | 将您视频中的应用程序上传到 Open Exchange。 |
翻译奖励 | 2 | 将您的视频翻译为我们地区社区所使用的语言之一（西班牙语、葡萄牙语、日语、中文、法语），并使用相同格式上传视频；在描述中提及此视频为翻译版，并提供原始视频的 YouTube 链接。 |
YouTube Shorts 奖励 | 2 | 为您的视频制作 YouTube 短视频（纵向视频，最长 60 秒）。 |
LinkedIn 奖励 | 1 | 在您的 LinkedIn 上分享视频，提及您正在参加 InterSystems 技术视频挑战，并添加开发者社区 LinkedIn 页面标签。 |
建议的主题
下面列出了将为您的文章提供额外奖励的建议主题：
✔️ 使用 AI / GenAI / RAG
✔️ 在实现互操作性时使用嵌入式 Python
✔️ 使用外部语言（C#、Java、Python）
✔️ 使用数据架构 / 数据湖 / 数据仓库 / 数据网格
✔️ 使用 FHIR
✔️ 使用 REST
✔️ IKO 通用部署
---
准备闪耀光芒，并使用您的技术技能激励他人！ 我们迫不及待欣赏您的作品。✨
备注 1：参加比赛，即表示您同意将您的视频上传到开发者社区 YouTube。
备注 2：奖品的送达因国家/地区而异，某些国家/地区可能无法送达。 要索取有限制的国家/地区列表，请联系 @Liubka Zelenskaia
一个实例上的最大命名空间数量是 2047. 但是，要使用这么大量的命名空间，你需要相应地配置好内存。
一个实例里可以创建的数据库的最大数量（包括远程数据库） 15998. 根据授权的类型，可能会有所限制。具体细节请参考以下文档。
Database Configuration [IRIS]
Database Configuration
我们最近在向量搜索抢险体验计划中提供了新版的 InterSystems IRIS，新版本采用了新的基于分层可导航小世界 (HNSW) 索引算法的近似最近邻索引。 这一新增功能可对大型向量数据集进行高效的近似最近邻搜索，从而显著提高查询性能和可扩缩性。
HNSW 算法旨在通过构建基于图形的结构来优化高维数据的向量搜索，从而更快地在大型向量集合中找到近似邻。 无论您使用的是推荐系统、自然语言处理，还是其他机器学习应用，HNSW 都能显著缩短搜索时间，同时允许您调整准确度水平，但准确度提高的代价是查询时间变慢。
HNSW 的主要优点包括：
• 即使数据集规模不断扩大，也能加快搜索速度
• 减少内存占用，同时保持高准确度
• 与现有的 IRIS 向量搜索功能无缝集成
最新版本现已通过向量搜索抢先体验计划提供。 要参与，请在此处注册，下载新版本并开始测试。 我们正在持续增强向量搜索的功能，因此您的反馈至关重要！
我们鼓励您探索性能改进方法，并与社区分享您的想法。 如果您在抢先体验阶段遇到任何问题或有任何反馈，请联系我。
祝您编码愉快！
✓ 九月有 47 位新成员加入
✓ 所有时间发布了 2,208 篇帖子
✓ 所有时间有 2,024 位成员加入
欢迎来到我的 CI/CD 系列的下一个章节，我们将探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。
今天，我们来谈谈互操作性。
当您有一个有效的互操作性生产时，您有两个独立的流程：一个是处理消息的可以正常运行的生产流程，另一个是更新代码、生产配置和系统默认设置的 CI/CD 流程。
显然，CI/CD 流程会影响互操作性。 但问题是：
我们从生产生命周期开始。
首先，可以启动生产。 每个命名空间只能同时运行一个生产，通常而言（除非您真正知道自己在做什么以及为什么这样做），每个命名空间内只能运行一个生产。 不推荐在一个命名空间中于两个或多个不同的生产之间来回切换。 启动生产会启动生产中定义的所有已启用的业务主机。 某些业务主机启动失败不会影响生产启动。
提示：
##class(Ens.Director).StartProduction("ProductionName")OnStart 方法可以在生产启动时（在启动任何业务主机作业之前）执行任意代码在生产启动后，Ens.Director 会持续监视正在运行的生产。 生产存在两种状态：目标状态，在生产类和系统默认设置中定义；以及_运行状态_ – 当前运行的作业及其创建时应用的设置。 如果所需状态与当前状态相同，则一切正常；但如果有差异，就可以（也应该）更新生产。 通常，您会在系统管理门户的“生产配置”页面上看到一个红色的 Update 按钮。
更新生产意味着尝试使当前生产状态与目标生产状态匹配。
当您运行 ##class(Ens.Director).UpdateProduction(timeout=10, force=0) 以更新生产时，它会为每个业务主机执行以下操作：
为每个业务主机运行此操作后，UpdateProduction 会构建一组更改：
然后，应用这些更改。
通过这种方式，“更新”设置而不更改任何内容不会导致生产停机。
提示：
##class(Ens.Director).UpdateProduction(timeout=10, force=0)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 差异来尽可能减小加载集）。 使用此 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)Ens.Director:StopProduction 并设置更长的超时。OnStop 方法可以在生产停止时执行任意代码重要的一点是，生产是业务主机的总和：
这会将我们带到业务主机的生命周期。
业务主机由相同的业务主机作业组成（根据池大小设置的值）。 启动业务主机意味着启动所有业务主机作业。 它们会并行启动。
单个业务主机作业的启动方式如下：
在完成 (4) 后，作业无法更改设置或代码，因此当您导入新的/相同的代码和新的/相同的系统默认设置时，它不会影响当前正在运行的互操作性作业。
停止业务主机作业意味着：
OnMessage 方法，BS 的 OnProcessInput，BPL BP 的状态 S<int> 方法以及 BP 的 On* 方法）。force=0，则生产更新会在该业务主机上失败（您会在 SMP 中看到一个红色的 Update 按钮）。timeout 之前处理完force=1业务主机更新意味着停止当前运行的业务主机作业并启动新作业。
所有业务主机会在新版本的业务规则、路由规则和 DTL 可用时立即开始使用它们。 在这种情况下，不需要重启业务主机。
不过，有时生产更新需要单个业务主机停机。
考虑接下来的情况。 您有一个当前的路由规则 X，它根据任意标准将消息路由到业务流程 A 或 B。 在新提交中，您同时添加：
在此场景下，您不能先加载规则，然后再更新生产。 原因在于，新编译的规则会立即开始将消息路由到业务流程 C，而 InterSystems IRIS 可能尚未编译该规则，或者互操作性尚未更新以供使用。 在这种情况下，您需要禁用包含路由规则的业务主机，更新代码，更新生产，然后再次启用业务主机。
注：
业务主机之间的依赖关系至关重要。 假设您有业务流程 A 和 B，其中 A 向 B 发送消息。 在新提交中，您同时添加：
在此场景中，我们必须首先更新流程 B，然后更新流程 A。 您可通过以下两种方式之一完成此操作：
这个主题一个更具挑战性的变体是，新版本的流程 A 和流程 B 与旧版本不兼容，这需要业务主机停机。
如果您知道更新后某个业务主机将无法处理旧消息，则需要确保在更新前该业务主机队列为空。 为此，请禁用所有向该业务主机发送消息的业务主机，并等到其队列变空。
首先，简单介绍一下 BPL BP 的运作方式。 在您编译 BPL BP 后，会在与完整 BPL 类同名的软件包中创建两个类：
Thread1 类包含方法 S1、S2、... SN，对应于 BPL 中的活动Context 类包含所有上下文变量，以及 BPL 将执行的下一个状态（即 S5）此外，BPL 类是持久类，可以存储当前正在处理的请求。
BPL 的工作方式是在 Thread 类中执行 S 方法并相应地更新 BPL 类表、Context 表和 Thread1 表，其中一条“正在处理”的消息是 BPL 表中的一行。 请求处理完后，BPL 会删除 BPL、Context 和 Thread 条目。 由于 BPL BP 是异步的，通过在 S 调用之间保存信息并在不同请求之间切换，一个 BPL 作业可同时处理多个请求。
例如，BPL 处理一个请求，直至其到达 sync 活动 – 等待来自 BO 的回答。 它会将当前上下文保存到磁盘中，同时将 %NextState 属性（位于 Thread1 类中）设置为响应活动 S 方法，并在 BO 回答前继续处理其他请求。 BO 回答后，BPL 会将上下文加载到内存中，并执行与 %NextState 属性中保存的状态对应的方法。
现在，当我们更新 BPL 时会发生什么？ 首先，我们需要检查是否至少满足以下两个条件之一：
如果至少满足一个条件，我们就可以开始更新。 要么没有需要更新后 BPL 处理的更新前请求，要么状态是在结束时添加的，这意味着旧请求也可以进入其中（假设更新前请求与更新后 BPL 活动和处理兼容）。
但是，如果您有正在处理的有效请求，而 BPL 更改了状态顺序，该怎么办？ 理想情况下，如果您可以等待，则禁用 BPL 调用方并等待队列为空。 验证上下文表是否也为空。 请记住，队列只显示未处理的请求，而上下文表存储正在处理的请求，因此您可能会遇到一个非常繁忙的 BPL 显示零队列大小的情况，这是正常的。 之后，禁用 BPL，执行更新并启用所有之前禁用的业务主机。
如果无法实现（通常是在 BPL 非常长的情况下，例如，我记得我更新过一个花了大约一周时间处理请求的 BPL，或者更新窗口太短），请使用 BPL 版本控制。
或者，您也可以编写一个更新脚本。 在此更新脚本中，将旧的后续状态映射到新的后续状态并在 Thread1 表上运行，以便更新的 BPL 可以处理旧请求。 当然，在更新期间必须禁用 BPL。
也就是说，这是一种极为罕见的情况，通常您不必这样做，但如果您需要这样做，方法就是如此。
为了将底层代码更改后实现生产所需的操作数降到最低，互操作性实现了一种复杂的算法。 每次 SDS 更新时，调用具有安全超时的 UpdateProduction。 对于每次代码更新，您都需要决定一种更新策略。
通过使用 git 差异减少编译的代码量有助于缩短编译时间，但利用自身“更新”代码并重新编译它或使用相同的值“更新”设置不会触发或要求进行生产更新。
更新和编译业务规则、路由规则和 DTL 可使它们在未进行生产更新的情况下立即可用。
最后，生产更新是一项安全操作，通常不需要停机。
在本文撰写期间，@James MacKeith、@Dmitry Zasypkin 和 @Regilo Regilio Guedes de Souza 提供了宝贵的帮助，作者对此深表感谢。
经过将近四年的停顿，我的 CI/CD 系列又回来了！ 这些年来，我与多个 InterSystems 客户合作，为不同的用例开发 CI/CD 管道。 希望本文中提供的信息对您有所帮助。
此系列文章探讨了使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。
我们有一系列激动人心的话题要讨论：但今天，我们来谈谈代码之外的事情 – 配置和数据。
之前我们探讨过代码提升，这在某种程度上是无状态的 – 我们总是从一个（大概）空实例到完整的代码库。 但有时，我们需要提供数据或状态。 不同的数据类型包括：
我们来探讨所有这些数据类型，以及如何先将它们提交到源代码控制工具中，然后进行部署。
系统配置分布在许多不同的类中，但 InterSystems IRIS 可以将大多数类导出为 XML。 首先是一个安全软件包，其中包含以下信息：
所有这些类都提供 Exists、Export 和 Import 方法，允许您在不同的环境之间移动它们。
一些注意事项：
另外值得注意的是，除了导出/导入，您还可以使用 %Installer 或 Merge CPF 来创建这些条目中的大多数。 这两个工具还支持创建命名空间和数据库。 Merge CPF 可以调整系统设置，例如全局缓冲区大小。
%SYS.Task 类存储任务并提供 ExportTasks 和 ImportTasks 方法。 您还可以查看上面的实用类，以逐个导入和导出任务。 请注意，当您导入任务时，如果 StartDate 或其他与计划相关的属性在过去的时间里，则可能会遇到导入错误 (ERROR #7432: Start Date and Time must be after the current date and time)。 解决方案是将 LastSchedule 设置为 0，InterSystems IRIS 会将新导入的任务重新安排为在不久的将来运行。
互操作性生产包含：
前两个可以在 Ens.Config 软件包中通过 %Export 和 %Import 方法获取。 使用上面的实用类导出凭据和查找表。 在最近的版本中，查找表可以通过 $system.OBJ 类导出/导入。
系统默认设置 – 是环境特定设置的默认互操作性机制：
系统默认设置的目的是简化将生产定义从一个环境复制到另一个环境的过程。 在任何生产中，一些设置的值作为生产设计的一部分确定；通常而言，这些设置在所有环境中都应相同。 不过，其他设置必须根据环境进行调整；这些设置包括文件路径、端口号等。
系统默认设置应仅指定特定于安装 InterSystems IRIS 的环境的值。 相比之下，生产定义应指定在所有环境中都应当相同的设置值。
我强烈建议在生产环境中使用它们。 使用 %Export 和 %Import 传输系统默认设置。
您的应用程序可能也使用设置。 在这种情况下，我建议使用系统默认设置。 虽然这是一种互操作性机制，但可以通过以下方式访问设置：%GetSetting(pProductionName, pItemName, pHostClassName, pTargetType, pSettingName, Output pValue)（文档）。 您可以编写一个包装器来设置您不关心的默认值，例如：
ClassMethod GetSetting(name, Output value) As %Boolean [Codemode=expression]
{
##class(Ens.Config.DefaultSettings).%GetSetting("myAppName", "default", "default", , name, .value)
}
如果您想要更多类别，还可以公开 pItemName 和/或 pHostClassName 参数。 可以通过导入、使用系统管理门户、创建 Ens.Config.DefaultSettings 类的对象或设置 ^Ens.Config.DefaultSettingsD 全局进行初始设置。
我的主要建议是将设置放在一个地方（可以是系统默认设置或自定义解决方案），应用程序必须仅通过提供的 API 获取设置。 这样，应用程序本身不知道环境，剩下的工作是为集中式设置存储提供环境特定的值。 为此，在您的仓库中创建一个包含设置文件的设置文件夹，文件名称与环境分支名称相同。 随后在 CI/CD 阶段，使用 $CI_COMMIT_BRANCH环境变量加载正确的文件。
DEV.xml
TEST.xml
PROD.xml
如果每个环境有多个设置文件，请使用以环境分支命名的文件夹。 要从 InterSystems IRIS 内获取环境变量值，请使用$System.Util.GetEnviron("name")。
如果您想让一些数据（引用表、目录等）可用，可以通过几种方式实现此目标：
xml.gz 文件进行改进，$system.OBJ 方法会根据需要自动（取消）归档 xml.gz 文件。 这种方式的主要缺点是数据无法被人类阅读，即使是 XML 也是如此 – 大部分采用 base64 编码。选择哪种格式取决于您的用例。 这里我按存储效率顺序列出了各个格式，但如果您没有大量数据，那就不必担心。
状态为您的 CI/CD 部署管道增加了额外的复杂性，但 InterSystems IRIS 为此提供了大量管理工具。
在这一系列文章中，我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题：
在本文中，我们将讨论如何构建并部署您自己的容器。
由于容器是临时的，它们不应存储任何应用程序数据。 持久化 %SYS 功能让我们能够实现这一点 – 将设置、配置、%SYS 数据等存储到主机卷上，即：
另一方面，我们需要将应用程序代码存储在我们的容器内，以便在需要时进行升级。
这一切使我们实现了如下所示的架构：
为了在构建过程中实现这一点，我们至少需要创建一个额外的数据库（用于存储应用程序代码）并将其映射到我们的应用程序命名空间。 在我的示例中，我将使用 USER 命名空间来保存应用程序数据，因为它已经存在且是持久化的。
基于上述内容，我们的安装程序需要执行以下任务：
Class MyApp.Hooks.Local
{
Parameter Namespace = "APP";
/// See generated code in zsetup+1^MyApp.Hooks.Local.1
XData Install [ XMLNamespace = INSTALLER ]
{
<Manifest>
<Log Text="Creating namespace ${Namespace}" Level="0"/>
<Namespace Name="${Namespace}" Create="yes" Code="${Namespace}" Ensemble="" Data="IRISTEMP">
<Configuration>
<Database Name="${Namespace}" Dir="/usr/irissys/mgr/${Namespace}" Create="yes" MountRequired="true" Resource="%DB_${Namespace}" PublicPermissions="RW" MountAtStartup="true"/>
</Configuration>
<Import File="${Dir}Form" Recurse="1" Flags="cdk" IgnoreErrors="1" />
</Namespace>
<Log Text="End Creating namespace ${Namespace}" Level="0"/>
<Log Text="Mapping to USER" Level="0"/>
<Namespace Name="USER" Create="no" Code="USER" Data="USER" Ensemble="0">
<Configuration>
<Log Text="Mapping Form package to USER namespace" Level="0"/>
<ClassMapping From="${Namespace}" Package="Form"/>
<RoutineMapping From="${Namespace}" Routines="Form" />
</Configuration>
<CSPApplication Url="/" Directory="${Dir}client" AuthenticationMethods="64" IsNamespaceDefault="false" Grant="%ALL" Recurse="1" />
</Namespace>
</Manifest>
}
/// This is a method generator whose code is generated by XGL.
/// Main setup method
/// set vars("Namespace")="TEMP3"
/// do ##class(MyApp.Hooks.Global).setup(.vars)
ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 0, pInstaller As %Installer.Installer) As %Status [ CodeMode = objectgenerator, Internal ]
{
Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "Install")
}
/// Entry point
ClassMethod onAfter() As %Status
{
try {
write "START INSTALLER",!
set vars("Namespace") = ..#Namespace
set vars("Dir") = ..getDir()
set sc = ..setup(.vars)
write !,$System.Status.GetErrorText(sc),!
set sc = ..createWebApp()
} catch ex {
set sc = ex.AsStatus()
write !,$System.Status.GetErrorText(sc),!
}
quit sc
}
/// Modify web app REST
ClassMethod createWebApp(appName As %String = "/forms") As %Status
{
set:$e(appName)'="/" appName = "/" _ appName
#dim sc As %Status = $$$OK
new $namespace
set $namespace = "%SYS"
if '##class(Security.Applications).Exists(appName) {
set props("AutheEnabled") = $$$AutheUnauthenticated
set props("NameSpace") = "USER"
set props("IsNameSpaceDefault") = $$$NO
set props("DispatchClass") = "Form.REST.Main"
set props("MatchRoles")=":" _ $$$AllRoleName
set sc = ##class(Security.Applications).Create(appName, .props)
}
quit sc
}
ClassMethod getDir() [ CodeMode = expression ]
{
##class(%File).NormalizeDirectory($system.Util.GetEnviron("CI_PROJECT_DIR"))
}
}
为了创建非持久化数据库，我会使用 /usr/irissys/mgr 的一个子目录，它不是持久的。 请注意，调用 ##class(%File).ManagerDirectory() 会返回持久化目录的路径，而不是内部容器目录的路径。
查看第 7 部分以了解完整信息，但我们需要做的就是在现有配置中添加这两行（加粗）代码。
run image:
stage: run
environment:
name: $CI_COMMIT_REF_NAME
url: http://$CI_COMMIT_REF_SLUG.docker.eduard.win/index.html
tags:
- test
script:
- docker run -d
--expose 52773
--volume /InterSystems/durable/$CI_COMMIT_REF_SLUG:/data
--env ISC_DATA_DIRECTORY=/data/sys
--env VIRTUAL_HOST=$CI_COMMIT_REF_SLUG.docker.eduard.win
--name iris-$CI_COMMIT_REF_NAME
docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME
--log $ISC_PACKAGE_INSTALLDIR/mgr/messages.logvolume 参数将主机目录挂载到容器中，ISC_DATA_DIRECTORY 变量告诉 InterSystems IRIS 使用哪个目录。 引用文档内容：
当您使用这些选项运行 InterSystems IRIS 容器时，会发生以下情况：
当应用程序演进并发布新版本（容器）时，有时您可能需要运行一些代码。 这可能是预编译/后编译挂钩、架构迁移、单元测试，但归根结底，您需要运行任意代码。 这就是为什么您需要一个管理应用程序的框架。 在之前的文章中，我概述了这种框架的基本结构，但它当然可以大幅度扩展以满足特定应用程序的需求。
创建容器化应用程序需要一些思考，但 InterSystems IRIS 提供了几个功能，可以让此流程更加轻松。
在这一系列文章中，我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题：
在本文中，我们将使用 InterSystems Cloud Manager 构建持续交付。 ICM 是一个面向基于 InterSystems IRIS 的应用程序的云配置和部署解决方案。 它允许您定义所需部署配置，ICM 会自动提供这些配置。 有关详情，请参阅 ICM 概述。
在我们的持续交付配置中，我们将完成以下任务：
也可以用示意图形式表示此流程：
如您所见，基本操作是相同的，不过我们将使用 ICM 而不是手动方式来管理 Docker 容器。
在我们开始升级容器之前，需要对它们进行配置。 因此，我们需要定义 defaults.json 和 definitions.json 来描述我们的架构。 我将为 LIVE 服务器提供这 2 个文件，TEST 服务器的 definitions 是相同的，defaults 只在 Tag 和 SystemMode 值上有所不同。
{
"Provider": "GCP",
"Label": "gsdemo2",
"Tag": "LIVE","SystemMode": "LIVE",
"DataVolumeSize": "10",
"SSHUser": "sample",
"SSHPublicKey": "/icmdata/ssh/insecure.pub",
"SSHPrivateKey": "/icmdata/ssh/insecure",
"DockerImage": "eduard93/icmdemo:master",
"DockerUsername": "eduard93",
"DockerPassword": "...",
"TLSKeyDir": "/icmdata/tls",
"Credentials": "/icmdata/gcp.json",
"Project": "elebedyu-test",
"MachineType": "n1-standard-1",
"Region": "us-east1",
"Zone": "us-east1-b",
"Image": "rhel-cloud/rhel-7-v20170719",
"ISCPassword": "SYS",
"Mirror": "false"
}
[
{
"Role": "DM",
"Count": "1",
"ISCLicense": "/icmdata/iris.key"
}
]在 ICM 容器内部，/icmdata 文件夹从主机挂载，并且：
获取所有必需的密钥后：
keygenSSH.sh /icmdata/ssh keygenTLS.sh /icmdata/tls
并将必需的文件放置在 /icmdata 中：
调用 ICM 来配置您的实例：
cd /icmdata/test icm provision icm run cd /icmdata/live icm provision icm run
这将为每个 TEST 和 LIVE 服务器配置一个独立的 InterSystems IRIS 实例。
有关更详细的指南，请参阅 ICM 概述。
首先，我们需要构建镜像。
我们的代码通常存储在仓库中，CD 配置位于 gitlab-ci.yml 中，但为了提高安全性，我们会在构建服务器上存储几个服务器特定的文件。
许可证密钥。 或者，它可以在容器构建过程中下载，而不是存储在服务器上。 将密钥存储在仓库中非常不安全。
包含默认密码的文件。 将这类文件存储在仓库中也非常不安全。 此外，如果您在单独的服务器上托管生产环境，它可能有不同的默认密码。
初始脚本，它执行以下任务：
set dir = ##class(%File).NormalizeDirectory($system.Util.GetEnviron("CI_PROJECT_DIR"))
do ##class(%SYSTEM.OBJ).Load(dir _ "Installer/Global.cls","cdk")
do ##class(Installer.Global).init()
halt请注意，第一行有意留空。
与之前的示例相比，有几个不同之处。 首先，我们没有启用操作系统身份验证，因为 ICM 会与容器交互而不是直接与 GitLab 交互。 其次，我使用安装程序清单来初始化我们的应用程序，以展示不同的初始化方式。 有关安装程序的更多信息，请参阅这篇文章。 最后，我们将在 Docker Hub 中以私有仓库的形式发布我们的镜像。
我们的安装程序清单如下所示：
<Manifest>
<Log Text="Creating namespace ${Namespace}" Level="0"/>
<Namespace Name="${Namespace}" Create="yes" Code="${Namespace}" Ensemble="" Data="IRISTEMP">
<Configuration>
<Database Name="${Namespace}" Dir="${MGRDIR}/${Namespace}" Create="yes" MountRequired="true" Resource="%DB_${Namespace}" PublicPermissions="RW" MountAtStartup="true"/>
</Configuration>
<Import File="${Dir}MyApp" Recurse="1" Flags="cdk" IgnoreErrors="1" />
</Namespace>
<Log Text="Mapping to USER" Level="0"/>
<Namespace Name="USER" Create="no" Code="USER" Data="USER" Ensemble="0">
<Configuration>
<Log Text="Mapping MyApp package to USER namespace" Level="0"/>
<ClassMapping From="${Namespace}" Package="MyApp"/>
</Configuration>
<CSPApplication Url="/" Directory="${Dir}client" AuthenticationMethods="64" IsNamespaceDefault="false" Grant="%ALL" />
<CSPApplication Url="/myApp" Directory="${Dir}" AuthenticationMethods="64" IsNamespaceDefault="false" Grant="%ALL" />
</Namespace>
</Manifest>它实现了以下更改：
现在，继续持续交付配置：
build image:
stage: build
tags:
- master
script:
- cp -r /InterSystems/mount ci
- cd ci
- echo 'SuperUser' | cat - pwd.txt load_ci_icm.script > temp.txt
- mv temp.txt load_ci.script
- cd ..
- docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t eduard93/icmdemo:$CI_COMMIT_REF_NAME .这里会执行哪些操作？
首先，由于 docker build 只能访问基础构建目录（在我们的示例中为仓库根目录）的子目录，我们需要将我们的“秘密”目录（其中包含 iris.key、pwd.txt 和 load_ci_icm.script）复制到克隆的仓库中。
接下来，首次终端访问需要用户名/密码，因此我们会将这些信息添加到 load_ci.script 中（这也是 load_ci.script 开头一行留空的原因）。
最后，我们会构建 docker 镜像并适当地为其添加标签：eduard93/icmdemo:$CI_COMMIT_REF_NAME
其中，$CI_COMMIT_REF_NAME 是当前分支的名称。 请注意，镜像标签的第一部分应与 GitLab 中的项目名称相同，这样才能在 GitLab 的“注册表”标签页中看到它（“注册表”标签页中提供了关于添加标签的说明）。
构建 docker 镜像是通过 Dockerfile 完成的，具体如下：
FROM intersystems/iris:2018.1.1-released ENV SRC_DIR=/tmp/src ENV CI_DIR=$SRC_DIR/ci ENV CI_PROJECT_DIR=$SRC_DIR COPY ./ $SRC_DIR RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ \ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ \ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt \ && iris start $ISC_PACKAGE_INSTANCENAME \ && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script \ && iris stop $ISC_PACKAGE_INSTANCENAME quietly
我们从基本的 iris 容器开始。
首先，我们将仓库（和“秘密”目录）复制到容器中。
接下来，我们将许可证密钥复制到 mgr 目录中。
然后，我们将密码更改为 pwd.txt 中的值。 请注意，此操作会删除 pwd.txt。
之后，实例启动并执行 load_ci.script。
最后，iris 实例停止。
请注意，我使用的是 GitLab Shell 执行器，而不是 Docker 执行器。 当您需要从镜像内部提取某些内容时，将使用 Docker 执行器，例如在 Java 容器中构建 Android 应用程序并且只需要一个 apk 时。 在我们的示例中，我们需要整个容器，因此需要使用 Shell 执行器。 因此，我们通过 GitLab Shell 执行器运行 Docker 命令。
现在，我们将镜像发布到 Docker Hub
publish image:
stage: publish
tags:
- master
script:
- docker login -u eduard93 -p ${DOCKERPASSWORD}
- docker push eduard93/icmdemo:$CI_COMMIT_REF_NAME注意 ${DOCKERPASSWORD} 变量，它是 GitLab 的秘密变量。 我们可以在“GitLab > 项目 > 设置 > CI/CD > 变量”中添加它们：
作业日志中也不包含密码值：
Running with gitlab-runner 10.6.0 (a3543a27)
on icm 82634fd1
Using Shell executor...
Running on docker...
Fetching changes...
Removing ci/
HEAD is now at 8e24591 Add deploy to LIVE
Checking out 8e245910 as master...Skipping Git submodules setup$ docker login -u eduard93 -p ${DOCKERPASSWORD}
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded
$ docker push eduard93/icmdemo:$CI_COMMIT_REF_NAME
The push refers to repository [docker.io/eduard93/icmdemo]
master: digest: sha256:d1612811c11154e77c84f0c08a564a3edeb7ddbbd9b7acb80754fda97f95d101 size: 2620
Job succeeded
在 Docker Hub 中，我们可以看到新镜像：
我们有了镜像，接下来在我们的测试服务器上运行它。 脚本如下。
run image:
stage: run
environment:
name: $CI_COMMIT_REF_NAME
tags:
- master
script:
- docker exec icm sh -c "cd /icmdata/test && icm upgrade -image eduard93/icmdemo:$CI_COMMIT_REF_NAME"使用 ICM，我们只需要运行一个命令 (icm upgrade) 即可升级现有部署。 我们通过运行“docker exec icm sh -c”来调用它，这会在 icm 容器内执行指定的命令。首先，我们进入 /icmdata/test，这里定义了我们为 TEST 服务器准备的 ICM 部署定义。 之后，我们调用 icm upgrade 将当前存在的容器替换为新容器。
我们来运行一些测试。
test image:
stage: test
tags:
- master
script:
- docker exec icm sh -c "cd /icmdata/test && icm session -namespace USER -command 'do \$classmethod(\"%UnitTest.Manager\",\"RunTest\",\"MyApp/Tests\",\"/nodelete\")' | tee /dev/stderr | grep 'All PASSED' && exit 0 || exit 1"
同样，我们在 icm 容器内执行一条命令。 icm 会话在一个已部署的节点上执行命令。 该命令运行单元测试。 之后，它将所有输出传输到屏幕，同时也传输给 grep 以查找单元测试结果，并成功退出进程或以出错方式退出。
生产服务器上的部署与测试服务器上的部署完全相同，只是为 LIVE 部署定义使用了另一个目录。 如果测试失败，此阶段将不会被执行。
deploy image:
stage: deploy
environment:
name: $CI_COMMIT_REF_NAME
tags:
- master
script:
- docker exec icm sh -c "cd /icmdata/live && icm upgrade -image eduard93/icmdemo:$CI_COMMIT_REF_NAME"在这一系列文章中，我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题：
在第一篇文章中，我们介绍了 Git 基础知识、深度理解 Git 概念对现代软件开发至关重要的原因，以及如何使用 Git 开发软件。
在第二篇文章中，我们介绍了 GitLab 工作流 – 一个完整的软件生命周期流程，并介绍了持续交付。
在第三篇文章中，我们介绍了 GitLab 安装和配置以及将环境连接到 GitLab
在第四篇文章中，我们编写了 CD 配置。
在第五篇文章中，我们讨论了容器以及使用容器的方式（和原因）。
在第六篇文章中，我们将探讨运行包含容器的持续交付管道所需的主要组件以及这些组件如何协同运行。
在这篇文章中，我们将构建上一篇文章中探讨的持续交付配置。
在持续交付配置中，我们会：
也可以用示意图形式表示此流程：
我们开始吧。
首先，我们需要构建镜像。
我们的代码通常存储在仓库中，CD 配置位于 gitlab-ci.yml 中，但为了提高安全性，我们会在构建服务器上存储几个服务器特定的文件。
包含 CD 挂钩代码。 该代码是在上一篇文章中开发的，并在 GitHub 上提供。 这是一个小型库，用于加载代码、运行各种挂钩以及测试代码。 作为更好的替代方案，您可以使用 git 子模块将此项目或类似项目包含到您的仓库中。 最好选择子模块，因为子模块更容易保持最新状态。 另一个替代方案是在 GitLab 上为版本添加标签，并使用 ADD 命令加载这些版本。
许可证密钥。 或者，它可以在容器构建过程中下载，而不是存储在服务器上。 将密钥存储在仓库中非常不安全。
包含默认密码的文件。 将这类文件存储在仓库中也非常不安全。 此外，如果您在单独的服务器上托管生产环境，它可能有不同的默认密码。
初始脚本，它执行以下任务：
set sc = ##Class(Security.System).Get("SYSTEM",.Properties)
write:('sc) $System.Status.GetErrorText(sc)
set AutheEnabled = Properties("AutheEnabled")
set AutheEnabled = $zb(+AutheEnabled,16,7)
set Properties("AutheEnabled") = AutheEnabled
set sc = ##Class(Security.System).Modify("SYSTEM",.Properties)
write:('sc) $System.Status.GetErrorText(sc)
zn "USER"
do ##class(%SYSTEM.OBJ).Load(##class(%File).ManagerDirectory() _ "GitLab.xml","cdk")
do ##class(isc.git.Settings).setSetting("hooks", "MyApp/Hooks/")
do ##class(isc.git.Settings).setSetting("tests", "MyApp/Tests/")
do ##class(isc.git.GitLab).load()
halt
请注意，第一行有意留空。
由于某些设置可以是服务器特定的，脚本不会存储在仓库中，而是单独存储。 如果此初始挂钩始终相同，将其存储在仓库中即可。
现在，继续持续交付配置：
构建镜像：
stage: build
tags:
- test
script:
- cp -r /InterSystems/mount ci
- cd ci
- echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt
- mv temp.txt load_ci.script
- cd ..
- docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.domain.com/test/docker:$CI_COMMIT_REF_NAME .这里会执行哪些操作？
首先，由于 docker build 只能访问基础构建目录的子目录（本例中是仓库根目录），我们需要将“秘密”目录（包含 GitLab.xml、iris.key、pwd.txt 和 load_ci.script 的目录）复制到克隆的仓库中。
接下来，首次终端访问需要用户名/密码，因此我们会将这些信息添加到 load_ci.script 中（这也是 load_ci.script 开头一行留空的原因）。
最后，我们会构建 docker 镜像并适当地为其添加标签：docker.domain.com/test/docker:$CI_COMMIT_REF_NAME
其中，$CI_COMMIT_REF_NAME 是当前分支的名称。 请注意，镜像标签的第一部分应与 GitLab 中的项目名称相同，这样才能在 GitLab 的“注册表”标签页中看到它（“注册表”标签页中提供了关于添加标签的说明）。
构建 docker 镜像是通过 Dockerfile 完成的，具体如下：
FROM docker.intersystems.com/intersystems/iris:2018.1.1.611.0ENV SRC_DIR=/tmp/src ENV CI_DIR=$SRC_DIR/ci ENV CI_PROJECT_DIR=$SRC_DIR
COPY ./ $SRC_DIR
RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/
&& cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/
&& $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt
&& iris start $ISC_PACKAGE_INSTANCENAME
&& irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script
&& iris stop $ISC_PACKAGE_INSTANCENAME quietly
我们从基本的 iris 容器开始。
首先，我们将仓库（和“秘密”目录）复制到容器中。
接下来，我们将许可证密钥和 GitLab.xml 复制到 mgr 目录中。
然后，我们将密码更改为 pwd.txt 中的值。 请注意，此操作会删除 pwd.txt。
之后，实例启动并执行 load_ci.script。
最后，iris 实例停止。
以下是作业日志（部分日志，跳过了加载/编译日志）：
Running with gitlab-runner 10.6.0 (a3543a27) on docker 7b21e0c4 Using Shell executor... Running on docker... Fetching changes... Removing ci/ Removing temp.txt HEAD is now at 5ef9904 Build load_ci.script From http://gitlab.eduard.win/test/docker 5ef9904..9753a8d master -> origin/master Checking out 9753a8db as master... Skipping Git submodules setup $ cp -r /InterSystems/mount ci $ cd ci $ echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt $ mv temp.txt load_ci.script $ cd .. $ docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME . Sending build context to Docker daemon 401.4kBStep 1/6 : FROM docker.intersystems.com/intersystems/iris:2018.1.1.611.0 ---> cd2e53e7f850 Step 2/6 : ENV SRC_DIR=/tmp/src ---> Using cache ---> 68ba1cb00aff Step 3/6 : ENV CI_DIR=$SRC_DIR/ci ---> Using cache ---> 6784c34a9ee6 Step 4/6 : ENV CI_PROJECT_DIR=$SRC_DIR ---> Using cache ---> 3757fa88a28a Step 5/6 : COPY ./ $SRC_DIR ---> 5515e13741b0 Step 6/6 : RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt && iris start $ISC_PACKAGE_INSTANCENAME && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script && iris stop $ISC_PACKAGE_INSTANCENAME quietly ---> Running in 86526183cf7c . Waited 1 seconds for InterSystems IRIS to start This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement
%SYS> 1
%SYS> Using 'iris.cpf' configuration file
This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement
1 alert(s) during startup. See messages.log for details. Starting IRIS
Node: 39702b122ab6, Instance: IRIS
Username: Password:
Load started on 04/06/2018 17:38:21 Loading file /usr/irissys/mgr/GitLab.xml as xml Load finished successfully.
USER>
USER>
[2018-04-06 17:38:22.017] Running init hooks: before
[2018-04-06 17:38:22.017] Importing hooks dir /tmp/src/MyApp/Hooks/
[2018-04-06 17:38:22.374] Executing hook class: MyApp.Hooks.Global
[2018-04-06 17:38:22.375] Executing hook class: MyApp.Hooks.Local
[2018-04-06 17:38:22.375] Importing dir /tmp/src/
Loading file /tmp/src/MyApp/Tests/TestSuite.cls as udl
Compilation started on 04/06/2018 17:38:22 with qualifiers 'c' Compilation finished successfully in 0.194s.
Load finished successfully.
[2018-04-06 17:38:22.876] Running init hooks: after
[2018-04-06 17:38:22.878] Executing hook class: MyApp.Hooks.Local
[2018-04-06 17:38:22.921] Executing hook class: MyApp.Hooks.Global Removing intermediate container 39702b122ab6 ---> dea6b2123165 [Warning] One or more build-args [CI_PROJECT_DIR] were not consumed Successfully built dea6b2123165 Successfully tagged docker.domain.com/test/docker:master Job succeeded
请注意，我使用的是 GitLab Shell 执行器，而不是 Docker 执行器。 当您需要从镜像内部提取某些内容时，将使用 Docker 执行器，例如在 Java 容器中构建 Android 应用程序并且只需要一个 apk 时。 在我们的示例中，我们需要整个容器，因此需要使用 Shell 执行器。 因此，我们通过 GitLab Shell 执行器运行 Docker 命令。
我们构建了镜像，接下来要运行镜像。如果是功能分支，我们销毁旧容器并启动新容器即可。 如果是环境，我们可以运行临时容器，在测试成功的情况下，可以替换环境容器（此内容留给读者作为练习）。
脚本如下。
destroy old:
stage: destroy
tags:
- test
script:
- docker stop iris-$CI_COMMIT_REF_NAME || true
- docker rm -f iris-$CI_COMMIT_REF_NAME || true此脚本会销毁当前运行的容器，并且始终都会成功（默认情况下，如果 docker 尝试停止/移除不存在的容器，则会失败）。
接下来，我们启动新镜像并将其注册为环境。 Nginx 容器 使用 VIRTUAL_HOST 环境变量和 expose 指令（用于了解要代理的端口）自动代理请求。
run image:
stage: run
environment:
name: $CI_COMMIT_REF_NAME
url: http://$CI_COMMIT_REF_SLUG. docker.domain.com/index.html
tags:
- test
script:
- docker run -d
--expose 52773
--env VIRTUAL_HOST=$CI_COMMIT_REF_SLUG.docker.eduard.win
--name iris-$CI_COMMIT_REF_NAME
docker.domain.com/test/docker:$CI_COMMIT_REF_NAME
--log $ISC_PACKAGE_INSTALLDIR/mgr/messages.log我们来运行一些测试。
test image:
stage: test
tags:
- test
script:
- docker exec iris-$CI_COMMIT_REF_NAME irissession iris -U USER "##class(isc.git.GitLab).test()"最后，我们将镜像发布到注册表中
publish image:
stage: publish
tags:
- test
script:
- docker login docker.domain.com -u dev -p 123
- docker push docker.domain.com/test/docker:$CI_COMMIT_REF_NAME可以使用 GitLab 秘密变量传递用户名/密码。
现在，我们可以在 GitLab 中看到该镜像：
其他开发者可以从注册表中拉取该镜像。 “环境”标签页上提供了我们所有的环境，可以轻松进行浏览：
在这一系列文章中，我介绍了持续交付的常规方式。 这是一个涉及面非常广的话题，您应将这一系列文章视为方法集合，而不是确定性内容。 如果您想自动构建、测试和交付应用程序，可以选择持续交付（一般情况）和 GitLab（特殊情况）。 利用持续交付和容器，您可以根据需要自定义工作流。
就是这些！ 希望我已介绍了持续交付和容器的基础知识。
但还有一些主题我没有介绍（可能后面会介绍），特别是关于容器的内容：
在这一系列文章中，我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题：
在第一篇文章中，我们介绍了 Git 基础知识，以及为什么对 Git 概念的高层次理解对于现代软件开发如此重要，以及如何使用 Git 开发软件。
在第二篇文章中，我们介绍了 GitLab 工作流 – 一个完整的软件生命周期流程和持续交付。
在第三篇文章中，我们介绍了 GitLab 的安装和配置以及如何将环境连接到 GitLab。
在第四篇文章中，我们编写了 CD 配置。
在 第五篇文章中，我们讨论了容器与如何（以及为什么）使用它们。
在本文中，我们将探讨运行使用容器的持续交付管道所需的主要组件，以及它们如何协同工作。
我们的配置如下所示：
在这里，我们可以看到三个主要阶段的分离：
在之前的部分中，构建通常是增量式 – 我们计算当前环境与当前代码库之间的差异，并修改我们的环境以与代码库相对应。 使用容器时，每次构建都是完整构建。 构建的结果是一个可以通过依赖关系在任何地方运行的镜像。
在我们的镜像构建并通过测试后，它会被上传到注册表 – 用于托管 docker 镜像的专用服务器。 在那里，它可以替换具有相同标签的旧镜像。 例如，由于对 master 分支的新提交，我们构建了新镜像 (project/version:master)，如果测试通过，我们可以用相同标签的新镜像替换注册表中的旧镜像，这样，所有拉取 project/version:master 的人都会获得新版本。
最后，我们的镜像部署完成。 CI 解决方案（如 GitLab）可以控制此流程，也可以由专门的编排器控制，但目的都一样 – 执行一些镜像，定期检查健康状态，如果有新镜像版本可用就进行更新。
查看 docker 网络研讨会以了解这些不同阶段的解释。
或者，从提交的角度来看：<
在我们的交付配置中，我们会：
为此，我们需要：
首先，我们需要在某个地方运行 docker。 我建议从一台运行主流 Linux 发行版（如 Ubuntu、RHEL 或 Suse）的服务器开始。 不要使用面向云的发行版（如 CoreOS、RancherOS 等） - 它们并不适合初学者。 别忘了将存储驱动程序切换为 devicemapper。
如果我们在讨论大规模部署，那么使用像 Kubernetes、Rancher 或 Swarm 这样的容器编排工具可以自动执行大多数任务，但我们不会探讨它们（至少在这一部分中）。
这是我们需要运行的第一个容器，它是一个无状态、可扩缩的服务器端应用程序，作用是存储和分发 Docker 镜像。
您应当在想要实现以下目的时使用注册表：
此处提供了注册表的文档。
注：GitLab 包含内置注册表。 您可以运行它而不使用外部注册表。 请阅读本段中链接的 GitLab 文档。
要将您的注册表连接到 GitLab，您需要运行支持 HTTPS的注册表 – 我使用 Let's Encrypt 获取证书，并按照此 Gist 获取证书并将其传递到容器中。 在确认注册表可以通过 HTTPS 访问后（您可以从浏览器检查），请按照这些说明将注册表连接到 GitLab。根据您的需要和 GitLab 安装情况，这些说明会有所不同。就我而言，配置是将注册表证书和密钥（正确命名且具有正确的权限）添加到 /etc/gitlab/ssl 并将以下行添加到 /etc/gitlab/gitlab.rb 中：
registry_external_url 'https://docker.domain.com' gitlab_rails['registry_api_url'] = "https://docker.domain.com"
在重新配置 GitLab 后，我可以看到一个新的注册表标签页，其中提供了如何正确为新构建的镜像添加标签以便它们会出现在这里的信息。
在我们的持续交付配置中，我们将为每个分支自动构建一个镜像，如果镜像通过测试，那么我们会将其发布到注册表并自动运行，因此我们的应用程序将在所有“状态”下自动可用，例如，我们可以访问：
为此，我们需要一个域名并添加一条通配符 DNS 记录，将 *.docker.domain.com 指向 docker.domain.com 的 IP 地址。 另一种选项是使用不同的端口。
由于我们有几个功能分支，需要将子域自动重定向到正确的容器。 为此，我们可以使用 Nginx 作为反向代理。 此处提供了一份指南。
要开始使用容器，您可以使用命令行或 GUI 界面之一。 有许多可用工具，例如：
它们允许您从 GUI 而不是 CLI 创建和管理容器。 下面是 Rancher 的外观：
与之前相同，要在其他服务器上执行脚本，我们需要安装 GitLab 运行程序。 我在第三篇文章中探讨过这一点。
请注意，您需要使用 Shell 执行器而不是 Docker 执行器。 当您需要从镜像内部提取某些内容时，将使用 Docker 执行器，例如在 Java 容器中构建 Android 应用程序并且只需要一个 apk 时。 在我们的示例中，我们需要整个容器，因此需要使用 Shell 执行器。
开始运行容器十分容易，并且有许多工具可供选择。
使用容器的持续交付与常规的持续交付配置在以下几个方面有所不同：
在下一篇文章中，我们将创建一个利用 InterSystems IRIS Docker 容器的 CD 配置。
在这一系列文章中，我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题：
在第一篇文章中，我们介绍了 Git 基础知识、深度理解 Git 概念对现代软件开发至关重要的原因，以及如何使用 Git 开发软件。
在第二篇文章中，我们介绍了 GitLab 工作流 – 一个完整的软件生命周期流程，并介绍了持续交付。
在第三篇文章中，我们介绍了 GitLab 安装和配置以及将环境连接到 GitLab
在第四篇文章中，我们编写了 CD 配置。
在这篇文章中，我们将介绍容器以及使用容器的方法（和原因）。
这篇文章假设读者熟悉 docker 和容器的概念。 如果您想了解容器和镜像，请查阅 @Luca Ravazzolo 撰写的文章。
使用容器有诸多优势：
下面我们来具体介绍这些优势。
容器将应用程序与运行所需的一切（如配置文件和依赖项）打包在一起。 这样一来，您可以在您本地台式机、物理服务器、虚拟服务器、测试、暂存、生产环境以及公共云或私有云等不同环境中轻松、可靠地运行应用程序。
可移植性的另一个优势是，在您构建 Docker 镜像并确认它可以正常运行后，它便可以在任何运行 docker 的位置（目前是 Windows、Linux 和 MacOS 服务器）运行。
实际上，您只需要运行应用程序进程，而不需要运行所有系统软件等。 容器恰好可以满足这一需求 – 容器仅会运行您明确需要的进程，而不运行其他进程。 由于容器不需要单独的操作系统，占用的资源较少。 虚拟机的大小通常为几千兆字节，而容器的大小通常只有几百兆字节，因此在一台服务器上运行的容器数量要比虚拟机多得多。 由于容器对底层硬件的利用率更高，您需要的硬件更少，从而降低了裸机成本和数据中心成本。
容器会将应用程序与其他一切隔离开，同时多个容器可以在同一台服务器上运行，它们可以完全彼此独立。 容器之间的任何交互都应明确声明。 如果一个容器发生故障，它不会影响其他容器，并且可以快速重新启动。 得益于这种隔离机制，安全性也得到了保障。 例如，利用裸机上的 Web 服务器漏洞可能会让攻击者访问整个服务器，但如果使用的是容器，攻击者只能访问 Web 服务器容器。
由于容器不需要单独的操作系统，只需几秒钟即可启动、停止或重新启动，从而可以加快所有相关开发流程并缩短生产时间。 您可以更快地开始工作，并且无需花费任何时间进行配置。
不可变基础架构由不可变组件组成，每次部署时都会替换这些组件，而不是就地更新。 这些组件通过每次部署构建一次的通用镜像启动，可以进行测试和验证。不可变性减少了不一致情况，并且可以轻松地在应用程序的不同状态之间进行复制和移动。 详细了解不可变性。
利用上文提到的所有优势，我们可以通过全新的方式管理基础架构和工作流。
裸机或虚拟机环境存在一个问题 – 它们具有个体性，这一问题会在使用过程中带来许多意外，而这些意外通常不尽如人意。 解决这一问题的方法是基础架构即代码 – 利用 DevOps 团队为源代码使用的版本控制方法，采用描述性模型管理基础架构。
通过基础架构即代码，无论环境的起始状态如何，部署命令始终会将目标环境设为相同的配置。 要实现这一点，可自动配置现有目标，也可以丢弃现有目标并重新创建全新的环境。
因此，利用基础架构即代码，团队会更改环境描述并对配置模型进行版本控制，而配置模型通常采用 JSON 等归档完好的代码格式。 发布管道会执行该模型，以配置目标环境。 如果团队需要进行更改，则可以编辑源代码，而不是目标环境。
借助容器，这一切都可以实现，并且实施起来简单得多。 关闭容器并启动一个新容器只需几秒钟，而配置新虚拟机则需要几分钟。 我甚至都没有提到将服务器回滚到空白状态。
基于之前的描述，您可能认为基础架构即代码本身是静态的。 并不是这样，因为编排工具也可以根据当前工作负载提供横向扩缩（进行更多相同的配置）。 您仅应运行目前需要的容器，并相应地扩缩应用程序。 这样还可以降低成本。
容器可以简化开发流程。 消除了环境之间的不一致，可以更轻松地进行测试和调试。 可以通过编排构建可扩缩应用程序。可以轻松实现部署或回滚到不可变历史的任意点。
组织希望在更高层级上处理任务，其中所有上述问题均已得到解决，并且我们发现调度程序和编排程序以自动方式为我们处理更多的任务。
在下一篇文章中，我们将探讨使用容器进行配置，并创建利用 InterSystems IRIS Docker 容器的 CD 配置。
在这一系列文章中，我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题：
在第一篇文章中，我们介绍了 Git 基础知识、深度理解 Git 概念对现代软件开发至关重要的原因，以及如何使用 Git 开发软件。
在第二篇文章中，我们介绍了 GitLab 工作流 – 一个完整的软件生命周期流程，并介绍了持续交付。
在第三篇文章中，我们介绍了 GitLab 安装和配置以及将环境连接到 GitLab
在这篇文章中，我们将介绍编写 CD 配置。
首先，我们需要多个环境以及与之对应的分支：
| 环境 | 分支 | 交付 | 有权提交的角色 | 有权合并的角色 |
|---|---|---|---|---|
| 测试 | master | 自动 | 开发者、所有者 | 开发者、所有者 |
| 预生产 | preprod | 自动 | 无 | 所有者 |
| 生产 | prod | 半自动（按下按钮进行交付） | 无 | 所有者 |
作为示例，我们将使用 GitLab 流程开发一个新功能，并使用 GitLab CD 进行交付。
具体如下图所示（我用草图标出了我们需要为 CD 开发的部分）：
也可以用示意图形式表示此流程：
应用程序由两部分组成：
通过上面的计划，我们可以确定需要在持续交付配置中定义的阶段：
以下是它在 gitlab-ci.yml 配置文件中的样式：
stages: - load - test - package - deploy
下面我们来定义脚本。 脚本文档。 我们先来定义用于加载服务器端代码的脚本 load server：
load server:
environment:
name: test
url: http://test.hostname.com
only:
- master
tags:
- test
stage: load
script: csession IRIS "##class(isc.git.GitLab).load()"脚本会执行哪些操作？
重要说明
对于 InterSystems IRIS，请将 csession 替换为 iris session。
对于 Windows，请使用：irisdb -s ../mgr -U TEST "##class(isc.git.GitLab).load()
现在，我们来编写相应的 isc.git.GitLab 类。 此类中的所有入口点如下所示：
ClassMethod method()
{
try {
// code
halt
} catch ex {
write !,$System.Status.GetErrorText(ex.AsStatus()),!
do $system.Process.Terminate(, 1)
}
}请注意，可以通过两种方式结束此方法：
因此，加载代码如下：
/// Do a full load
/// do ##class(isc.git.GitLab).load()
ClassMethod load()
{
try {
set dir = ..getDir()
do ..log("Importing dir " _ dir)
do $system.OBJ.ImportDir(dir, ..getExtWildcard(), "c", .errors, 1)
throw:$get(errors,0)'=0 ##class(%Exception.General).%New("Load error")
halt
} catch ex {
write !,$System.Status.GetErrorText(ex.AsStatus()),!
do $system.Process.Terminate(, 1)
}
}
调用了两个实用方法：
如何获取目录？
执行脚本时，GitLab 会先指定很多环境变量。 其中一个环境变量是 CI_PROJECT_DIR – 克隆仓库以及运行作业位置的完整路径。 我们可以通过 getDir 方法轻松获取：
ClassMethod getDir() [ CodeMode = expression ]
{
##class(%File).NormalizeDirectory($system.Util.GetEnviron("CI_PROJECT_DIR"))
}以下是测试脚本：
load test:
environment:
name: test
url: http://test.hostname.com
only:
- master
tags:
- test
stage: test
script: csession IRIS "##class(isc.git.GitLab).test()"
artifacts:
paths:
- tests.html有哪些更改？ 当然是名称和脚本代码，但还添加了工件。 工件是作业成功完成后附加到作业的文件和目录列表。 本例中，测试完成后，我们可以生成重定向到测试结果的 HTML 页面，并使其可以通过 GitLab 访问。
请注意，加载阶段有很多复制粘贴的内容 – 环境是相同的，脚本部分（例如环境）可以单独标记并附加到脚本。 我们来定义测试环境：
.env_test: &env_test
environment:
name: test
url: http://test.hostname.com
only:
- master
tags:
- test现在，我们的脚本如下：
load test:
<<: *env_test
script: csession IRIS "##class(isc.git.GitLab).test()"
artifacts:
paths:
- tests.html接下来，我们使用 UnitTest 框架执行测试。
/// do ##class(isc.git.GitLab).test()
ClassMethod test()
{
try {
set tests = ##class(isc.git.Settings).getSetting("tests")
if (tests'="") {
set dir = ..getDir()
set ^UnitTestRoot = dir
$$$TOE(sc, ##class(%UnitTest.Manager).RunTest(tests, "/nodelete"))
$$$TOE(sc, ..writeTestHTML())
throw:'..isLastTestOk() ##class(%Exception.General).%New("Tests error")
}
halt
} catch ex {
do ..logException(ex)
do $system.Process.Terminate(, 1)
}
}
本例中，测试设置是相对于存储单元测试的仓库根目录的路径。 如果此处为空，则跳过测试。 writeTestHTML 方法用于输出重定向到测试结果的 html：
ClassMethod writeTestHTML()
{
set text = ##class(%Dictionary.XDataDefinition).IDKEYOpen($classname(), "html").Data.Read()
set text = $replace(text, "!!!", ..getURL())
set file = ##class(%Stream.FileCharacter).%New()
set name = ..getDir() _ "tests.html"
do file.LinkToFile(name)
do file.Write(text)
quit file.%Save()
}
ClassMethod getURL()
{
set url = ##class(isc.git.Settings).getSetting("url")
set url = url _ $system.CSP.GetDefaultApp("%SYS")
set url = url_"/%25UnitTest.Portal.Indices.cls?Index="_ $g(^UnitTest.Result, 1) _ "&$NAMESPACE=" _ $zconvert($namespace,"O","URL")
quit url
}
ClassMethod isLastTestOk() As %Boolean
{
set in = ##class(%UnitTest.Result.TestInstance).%OpenId(^UnitTest.Result)
for i=1:1:in.TestSuites.Count() {
#dim suite As %UnitTest.Result.TestSuite
set suite = in.TestSuites.GetAt(i)
return:suite.Status=0 $$$NO
}
quit $$$YES
}
XData html
{
<html lang="en-US">
<head>
<meta charset="UTF-8"/>
<meta http-equiv="refresh" content="0; url=!!!"/>
<script type="text/javascript">
window.location.href = "!!!"
</script>
</head>
<body>
If you are not redirected automatically, follow this <a href='!!!'>link to tests</a>.
</body>
</html>
}
我们的客户端是一个简单的 HTML 页面：
<html>
<head>
<script type="text/javascript">
function initializePage() {
var xhr = new XMLHttpRequest();
var url = "${CI_ENVIRONMENT_URL}:57772/MyApp/version";
xhr.open("GET", url, true);
xhr.send();
xhr.onloadend = function (data) {
document.getElementById("version").innerHTML = "Version: " + this.response;
};
var xhr = new XMLHttpRequest();
var url = "${CI_ENVIRONMENT_URL}:57772/MyApp/author";
xhr.open("GET", url, true);
xhr.send();
xhr.onloadend = function (data) {
document.getElementById("author").innerHTML = "Author: " + this.response;
};
}
</script>
</head>
<body onload="initializePage()">
<div id = "version"></div>
<div id = "author"></div>
</body>
</html>
要进行构建，需要将 ${CI_ENVIRONMENT_URL} 替换为其值。 当然，实际应用程序可能需要 npm，但此处仅为了举例说明。 脚本如下：
package client:
<<: *env_test
stage: package
script: envsubst < client/index.html > index.html
artifacts:
paths:
- index.html最后，我们将 index.html 部署到 Web 服务器根目录，以部署客户端。
deploy client: <<: *env_test stage: deploy script: cp -f index.html /var/www/html/index.html
就是这些！
如果您需要在多个环境中执行相同（相似）的脚本，应该如何操作？ 脚本部分也可以是标签，因此下面给出了在测试和预生产环境中加载代码的示例配置：
stages: - load - test.env_test: &env_test environment: name: test url: http://test.hostname.com only: - master tags: - test
.env_preprod: &env_preprod environment: name: preprod url: http://preprod.hostname.com only: - preprod tags: - preprod
.script_load: &script_load stage: load script: csession IRIS "##class(isc.git.GitLab).loadDiff()"
load test: <<: *env_test <<: *script_load
load preprod: <<: *env_preprod <<: *script_load
通过这种方式，我们便无需复制粘贴代码。
有关完整的 CD 配置，请参阅此处。 该配置遵循在测试、预生产和生产环境之间移动代码的原始计划。
可以将持续交付配置为自动执行任何所需的开发工作流。
在下一篇文章中，我们将创建利用 InterSystems IRIS Docker 容器的 CD 配置。
在这一系列文章中，我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题：
在第一篇文章中，我们介绍了 Git 基础知识、深度理解 Git 概念对现代软件开发至关重要的原因，以及如何使用 Git 开发软件。
在第二篇文章中，我们介绍了 GitLab 工作流 – 一个完整的软件生命周期流程，并介绍了持续交付。
在这篇文章中，我们将探讨：
我们将在本地安装 GitLab。 可以通过多种方式安装 GitLab – 通过源代码、软件包安装，以及在容器中安装。 我不会在这里详细介绍所有步骤，请参阅相关指南。 但仍需要注意几点：
前提条件：
首先，您可能需要发送包含通知的电子邮件。
接下来，建议安装 Pages。 正如我们在上一篇文章中所讨论的 – 可以将脚本中的工件上传到 GitLab。 用户可以下载这些工件，但能够直接在浏览器中打开工件将非常有用，为此我们需要使用页面。
需要使用页面的原因：
由于 html 页面会在加载时重定向，可以使用 html 页面将用户重定向到我们需要的位置。 例如，下列代码生成的 html 页面会将用户重定向到上次执行的单元测试（生成 html 时）：
ClassMethod writeTestHTML()
{
set text = ##class(%Dictionary.XDataDefinition).IDKEYOpen($classname(), "html").Data.Read()
set text = $replace(text, "!!!", ..getURL())
set file = ##class(%Stream.FileCharacter).%New()
set name = "tests.html"
do file.LinkToFile(name)
do file.Write(text)
quit file.%Save()
}
ClassMethod getURL()
{
set url = "http://host:57772"
set url = url _ $system.CSP.GetDefaultApp("%SYS")
set url = url_"/%25UnitTest.Portal.Indices.cls?Index="_ $g(^UnitTest.Result, 1) _ "&$NAMESPACE=" _ $zconvert($namespace,"O","URL")
quit url
}
XData html
{
<html lang="en-US">
<head>
<meta charset="UTF-8"/>
<meta http-equiv="refresh" content="0; url=!!!"/>
<script type="text/javascript">window.location.href = "!!!"</script>
</head>
<body>
If you are not redirected automatically, follow this <a href='!!!'>link to tests</a>.
</body>
</html>
}
我使用页面时遇到了错误（浏览工件时出现 502 错误） - 解决方法。
要运行 CD 脚本，需要使用环境，即配置好的用于运行应用程序的服务器。 假设有一个安装了 InterSystems 产品（例如 InterSystems IRIS，但也可以使用 Caché 和 Ensemble）的 Linux 服务器，可以通过以下步骤将环境连接到 GitLab：
重要说明 - 安装 GitLab 运行程序后请勿克隆服务器。否则，结果将不可预测，并且大多数情况下的结果都不尽如人意。
运行初始程序后：
sudo gitlab-runner register
您会看到多个提示，大部分步骤都非常简单，但有几步比较复杂：
请输入用于此运行程序的 gitlab-ci 令牌
有多个令牌可用：
由于您连接运行程序是为特定项目运行 CD，需要指定此项目的令牌。
请输入此运行程序的 gitlab-ci 标签（以逗号分隔）：
在 CD 配置中，您可以筛选针对具体标签运行的脚本。 因此，在最简单的情况下，请指定一个将作为环境名称的标签。
请输入执行器：ssh、docker+machine、docker-ssh+machine、kubernetes、docker、parallels、virtualbox、docker-ssh、shell:
docker
如果您使用的是没有 docker 的普通服务器，请选择 shell。我们将在后续部分讨论 docker。
将运行程序连接到 GitLab 后，我们需要允许运行程序与 InterSystems IRIS 交互，为此：
对于 2 和 3，可以采用其他方式，例如传递用户名/密码，但我认为操作系统身份验证是更好的选择。
在本部分中：
在下一部分中，我们将编写持续交付配置。
在这一系列文章中，我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题：
在上一篇文章中，我们介绍了 Git 基础知识、深度理解 Git 概念对现代软件开发至关重要的原因，以及如何使用 Git 开发软件。 我们的侧重点仍是软件开发的实现部分，但本部分会介绍：
GitLab 工作流是软件开发流程整个生命周期中可能采取的操作的逻辑序列。
GitLab 工作流会考虑我们在上一篇文章中探讨的 GitLab 流程。 具体如下：
再次说明，流程本身不是新的（或者 GitLab 独有的），并且可以通过其他工具来实现。
我们来讨论一下其中的几个阶段以及这些阶段涉及的内容。 还提供文档。
GitLab 工作流的开始阶段以问题为中心，问题是指一个功能、一个错误或其他在语义上独立的工作。
问题有多个目的，例如：
在计划阶段，我们可以按问题的优先级、里程碑、看板将问题分组，并获得问题的概览。
开发在前一部分进行了讨论，只需按照您希望使用的任何 git 流程执行操作即可。 我们开发了新功能并将其合并到 master 分支后，接下来应怎样操作？
持续交付是一种软件工程方式，团队通过这种方式在短周期内制作软件，从而确保软件可以随时实现可靠发布。 它的目的是更快速、更频繁地构建、测试和发布软件。 这种方式允许对生产中的应用程序进行更多增量更新，从而帮助缩减交付更改的成本、缩短时间，以及降低风险。 简单且可重复的部署过程对于持续交付非常重要。
在 GitLab 中，持续交付配置按仓库以 YAML 配置文件形式定义。
脚本定义了一个操作以及执行该操作需要满足的条件：
环境是配置好的服务器或容器，可用于运行脚本。
运行程序用于在特定环境中执行脚本。 运行程序连接到 GitLab，并根据需要执行脚本。
运行程序可以部署在服务器上、容器上，甚至部署在本地机器上。
持续交付是如何实现的？
例如，下面是提交到 master 分支后执行的一个管道：
管道包含四个阶段，各阶段连续执行
我们可以看到，每个脚本都成功运行，如果其中一个脚本运行失败，则默认不会运行后面的脚本（但我们可以更改此行为）：
如果我们打开脚本，可以查看日志并确定脚本运行失败的原因：
Running with gitlab-runner 10.4.0 (857480b6)
on test runner (ab34a8c5)
Using Shell executor...
Running on gitlab-test...
Fetching changes...
Removing diff.xml
Removing full.xml
Removing index.html
Removing tests.html
HEAD is now at a5bf3e8 Merge branch '4-versiya-1-0' into 'master'
From http://gitlab.eduard.win/test/testProject
* [new branch] 5-versiya-1-1 -> origin/5-versiya-1-1
a5bf3e8..442a4db master -> origin/master
d28295a..42a10aa preprod -> origin/preprod
3ac4b21..7edf7f4 prod -> origin/prod
Checking out 442a4db1 as master...Skipping Git submodules setup$ csession ensemble "##class(isc.git.GitLab).loadDiff()"[2018-03-06 13:58:19.188] Importing dir /home/gitlab-runner/builds/ab34a8c5/0/test/testProject/
[2018-03-06 13:58:19.188] Loading diff between a5bf3e8596d842c5cc3da7819409ed81e62c31e3 and 442a4db170aa58f2129e5889a4bb79261aa0cad0
[2018-03-06 13:58:19.192] Variable modified
var=$lb("MyApp/Info.cls")
Load started on 03/06/2018 13:58:19
Loading file /home/gitlab-runner/builds/ab34a8c5/0/test/testProject/MyApp/Info.cls as udl
Load finished successfully.
[2018-03-06 13:58:19.241] Variable items
var="MyApp.Info.cls"
var("MyApp.Info.cls")=""
Compilation started on 03/06/2018 13:58:19 with qualifiers 'cuk /checkuptodate=expandedonly'
Compiling class MyApp.Info
Compiling routine MyApp.Info.1
ERROR: MyApp.Info.cls(version+2) #1003: Expected space : '}' : Offset:14 [zversion+1^MyApp.Info.1]
TEXT: quit, "1.0" }
Detected 1 errors during compilation in 0.010s.
[2018-03-06 13:58:19.252] ERROR #5475: Error compiling routine: MyApp.Info.1. Errors: ERROR: MyApp.Info.cls(version+2) #1003: Expected space : '}' : Offset:14 [zversion+1^MyApp.Info.1]
> ERROR #5030: An error occurred while compiling class 'MyApp.Info'
ERROR: Job failed: exit status 1
编译错误导致脚本失败。
在下一篇文章中，我们将：
我们来探讨一下持续交付的运作方式。
首先，我们需要多个环境以及与之对应的分支。 代码进入此分支，并交付到目标环境：
| 环境 | 分支 | 交付 | 有权提交的角色 | 有权合并的角色 |
|---|---|---|---|---|
| 测试 | master | 自动 | 开发者、所有者 | 开发者、所有者 |
| preprod | 预生产 | 自动 | 无 | 所有者 |
| prod | 生产 | 半自动（按下按钮进行交付） | 无 | 所有者 |
作为示例，我们将使用 GitLab 流程开发一个新功能，并使用 GitLab CD 进行交付。
具体如下图所示：
也可以用示意图形式表示此流程：
大家都搭建了测试环境。
有些人很幸运，可以在完全独立的环境中运行生产。
-- 佚名
.
在这一系列文章中，我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题：
第一部分将介绍现代软件开发的基础 – Git 版本控制系统和各种 Git 流程。
虽然我们将主要探讨软件开发的概况以及 GitLab 如何帮助我们实现这一目标，但 Git，或者说 Git 设计中的几个基础的高级概念对于更好地理解后面的概念非常重要。
也就是说，Git 是基于这些概念的版本控制系统（还有更多概念，但这几个概念最为重要）：
我的意思不是说 Git 发明了这些概念。 Git 并没有发明这些概念， 而是使这些概念变得简单、流行，并加入了多个相关创新概念，也就是说，架构即代码/容器化改变了软件开发。
仓库是存储数据以及关于数据的元信息的项目。
仓库可以：
但从 git 的角度来看，本地仓库与远程仓库之间没有特殊的区别。
提交是仓库的固定状态。 很显然，如果每次提交都存储仓库的完整状态，我们的仓库很快就会变得非常大。 因此，提交会存储差异，也就是当前提交与其父提交之间的差异。
不同的提交可以具有不同数量的父提交：
现在，对于父提交，每个与之不同的提交都被称为子提交。 每个父提交可以有任意数量的子提交。
分支是对提交的引用（或指针），如下图所示：
该图像显示的仓库具有两个提交（灰色圆圈），第二个圆圈是 master 分支的头部。 在我们添加更多提交后，仓库开始变成下图所示的状态：
这是最简单的情况。 我们的开发者一次负责处理一个更改。 但通常会有很多开发者同时负责处理不同的功能，我们需要使用提交树显示仓库中的变化。
我们从相同的起始状态开始。 仓库具有两个提交：
但现在，两名开发者在同时工作，为了避免相互干扰，他们在单独的分支中工作：
一段时间后，他们需要合并所做的更改，为此，他们创建了合并请求（也叫拉取请求）， 顾名思义，该请求可将两个不同的仓库状态（本例中，我们要将 develop 分支合并到 master 分支中）合并为一个新状态。 接受相应审查并获得批准后，仓库状态如下图所示：
开发继续进行：
主要概念：
如果您想了解更多关于 Git 的信息，可以阅读相关书籍。
现在，读者已熟悉基本的 Git 术语和概念，我们来探讨一下如何使用 Git 管理软件生命周期的开发部分。很多实践（称为流程）介绍了使用 Git 的开发流程，但我们只会探讨其中两个：
GitHub 流程非常简单。 具体如下：
我们需要遵守几条规则：
* 不要与“Ensemble 生产”混淆，这里的“生产”是指正式。
** 环境是配置好的代码运行位置，可以是服务器、虚拟机，甚至可以是容器。
如下图所示：
有关 GitHub 流程的更多信息，请参阅此处。 我们还提供了图解指南。
GitHub 流程非常适合小型项目，如果您刚开始使用 Git 流程，可以尝试一下。 不过，GitHub 也会使用 GitHub 流程，因此也可以在大型项目中使用 GitHub 流程。
如果您还没有准备好立即部署到生产环境，GitLab 流程提供 GitHub 流程 + 环境。 具体做法是：在功能分支中进行开发（与上例相同），合并到 master 分支中（与上例相同），但这里有一个不同之处： master 分支仅等同于测试环境。 除此之外，还有链接到可能存在的各种其他环境的“环境分支”。
通常存在三个环境（可以根据需要创建更多环境）：
进入其中一个环境分支的代码应立即移至相应的环境中，此流程可通过以下方式完成：
完整的流程是：
具体如下图所示：
有关 GitLab 流程的更多信息，请参阅此处。
在接下来的部分中，我们将：
敬请关注。
✓ 八月有 51 位新成员加入
✓ 所有时间发布了 2,163 篇帖子
✓ 所有时间有 1,975 位成员加入
各位社区成员，大家好，
利用面向您的组织中的各个角色提供的全套 InterSystems 学习资源（在线或面授形式），您可以全面挖掘 InterSystems IRIS 的潜力，并帮助您的团队完成入门流程。 开发者、系统管理员、数据分析师和集成商可以快速上手。
在深入学习角色特定的资源之前，我们先来总体了解一下现有的学习资源：
通过这些学习资源，您的团队将掌握相应知识，从而最大限度地利用 InterSystems IRIS 的功能，推动组织的发展并取得成功。 如需获取其他帮助，请随时在此发布问题或咨询您的专属销售工程师。
在您和您的团队成员接受足够时长的培训并获得相应经验后，你们可以申请认证来证明在 InterSystems 技术方面具备相应的技能和专业知识：
可定制以收集全方位的身心健康数据。
Caren从可穿戴设备和护理设备点（如iHealth®、Fitbit®、Omron®、Tenovi®和Withings®）收集数据。数据显示在网络仪表板上，可以在电子病历系统内也可以独立查看。Caren可以定制，使用API从专门的医疗设备收集健康数据。
语音交互式移动应用程序提高了患者的参与度。
用户友好的语音交互式移动应用程序提供了简单、直观的设计，用户只需轻点一下即可进入或查看测量和观察结果。
公司介绍：https://www.carenmhealth.com
目标使用者--临床医生和患者
类别--临床研究、疾病管理、远程医疗
应用程序类型--SMART ON FHIR应用程序
FHIR 版本--R4
支持的电子病历系统--Cerner、Epic等支持FHIR API的软件系统