您打算实施 Atlassian 软件（Jira、Confluence）吗？ 不想犯残酷的设计错误，然后必须在最后一刻解决？
那么你在这里 - 我们正在考虑在公司中实施 Atlassian Jira + Confluence，同时考虑到各种技术方面。
您好，我是 RSHB 的产品负责人，负责开发基于 Atlassian Jira 和 Confluence 软件产品的生命周期管理系统 (LCMS)。
在本文中，我将介绍构建 LCMS 的技术方面。 本文对计划在企业环境中实施或开发 Atlassian Jira 和 Confluence 的任何人都有用。 本文不需要特殊知识，专为初步熟悉 Atlassian 产品而设计。 本文将对管理员、产品所有者、项目经理、架构师以及计划实施基于 Atlassian 软件的系统的每个人都有用。
介绍
本文将讨论在企业环境中实施生命周期管理系统 (LCMS) 的技术问题。 让我们首先定义这意味着什么。
什么是企业解决方案？
这意味着解决方案：
- 可扩展。 在负载增加的情况下，存在增加系统容量的技术可能性。 水平和垂直扩展分离——垂直扩展增加了服务器的容量，水平扩展增加了系统运行的服务器数量。
- 故障保险。 如果一个元素出现故障，系统将保持可用。 一般来说，企业系统不需要容错，但我们会考虑这样的解决方案。 我们计划在系统中有数百个竞争用户，停机时间将非常关键。
- 支持的。 该解决方案必须得到供应商的支持。 不受支持的软件应替换为内部开发或其他受支持的软件。
- 安装 自我管理 （内部部署）。 自我管理是指不在云中而是在您自己的服务器上安装软件的能力。 更准确地说，这些都是非 SaaS 安装选项。 在本文中，我们将仅考虑自我管理的安装选项。
- 独立开发和测试的可能性。 为了组织系统中可预测的变化，需要一个单独的系统用于开发（系统本身的变化），一个测试系统（Staging）和一个供用户工作的生产系统。
- 更多。 支持各种身份验证场景，支持审计日志，具有自定义角色模型等。
这些是企业解决方案的主要元素，不幸的是，在设计系统时，它们经常被遗忘。
什么是生命周期管理系统 (LCMS)？
简而言之，在我们的例子中，这些是 Atlassian Jira 和 Atlassian Confluence——一个提供用于组织团队合作的工具的系统。 该系统不会“强加”组织工作的规则，而是提供各种工作工具，例如 Scrum、看板、瀑布模型和可扩展的 Scrum 等。
LCMS这个名称不是行业术语或通用术语，它只是我们银行系统的名称。 LCMS 对我们来说不是错误跟踪系统，也不是事件管理系统和变更管理系统。
实施包括哪些内容？
该解决方案的实施包括许多技术和组织问题：
- 技术能力的分配。
- 购买软件。
- 创建一个团队来实施解决方案。
- 解决方案的安装和配置。
- 解决方案架构开发。 好榜样。
- 操作文档的开发，包括说明、法规、技术设计、法规等。
- 改变公司流程。
- 创建一个支持团队。 SLA 开发。
- 用户培训。
- 更多。
在本文中，我们将考虑实施的技术方面，而不是组织组件的详细信息。
特性 Atlassian
Atlassian 是许多领域的领导者：
（由于成功收购 AgileCraft 及其云解决方案而成为领导层）
Atlassian 的产品具有您需要的所有企业功能。 我会注意到以下特点：
- Atlassian 解决方案基于 Java Tomcat Web 服务器。 Apache Tomcat 软件包含在 Atlassian 软件中，作为安装的一部分，您无法更改与 Atlassian 软件一起安装的 Apache Tomcat 版本，即使该版本已过时且包含漏洞。 唯一的选择是等待 Atlassian 使用较新版本的 Apache Tomcat 进行更新。 现在，例如，当前版本的 Jira 有 Apache Tomcat 8.5.42，而 Confluence 有 Apache Tomcat 9.0.33。
- 方便的界面，实现了市场上此类软件的最佳实践。
- 完全可定制的解决方案。 通过改进，您可以为用户实现基本功能的任何更改。
- 发达的生态系统。 有数百个合作伙伴： ，包括俄罗斯的 16 个合作伙伴。 您可以通过俄罗斯的合作伙伴购买 Atlassian 软件、插件并获得培训。 开发和维护大部分插件的是合作伙伴。
- 应用商店（插件）： . 插件大大增强了 Atlassian 软件的功能。 Atlassian 软件的基本功能非常有限，几乎任何任务都需要免费或额外付费安装额外的插件。 因此，软件成本可能会大大高于最初的估计。
迄今为止，商店中已经发布了数千个插件，其中近千个已经在数据中心批准的应用程序程序下进行了测试和验证。 这样的插件可以认为是稳定的，适合在繁忙的系统中使用。
插件规划的问题我劝大家慎重考虑，这极大的影响了解决方案的成本，很多插件会导致系统不稳定，插件厂商也不提供解决问题的支持。 - 培训和认证：
- 支持 SSO、SAML 2.0 机制。
- 对可伸缩性和容错的支持仅在数据中心版本中可用。 此版本首次出现于 2014 年 (Jira 6.3)。 Data Center 版本的功能不断扩展和改进（例如，单节点安装的可能性仅在 2020 年出现）。 随着数据中心批准的应用程序的引入，数据中心版本的插件方法在 2018 年发生了很大变化。
- 支持成本。 供应商的支持成本几乎等于软件许可的全部成本。 下面给出了计算许可证成本的示例。
- 缺乏长期发布。 有所谓的 ，但与所有其他版本一样，它们的支持期为 2 年。 不同之处在于，仅针对企业版本发布了修复程序，而没有添加新功能。
- 扩展支持选项（需要额外资金）。
- 支持多种 DBMS 变体。 Atlassian 附带一个免费的 H2 数据库，不建议将其用于生产用途。 以下 DBMS 支持用于生产用途：Amazon Aurora（仅限数据中心）PostgreSQL、Azure SQL、MySQL、Oracle DB、PostgreSQL、MS SQL Server。 支持的版本有限制，通常只支持旧版本，但对于每个 DBMS 都有一个提供供应商支持的版本：
,
.
技术架构
方案说明：
- 图为我行的实现，此配置仅作为示例，不推荐使用。
- nginx 为 Jira 和 Confluence 提供反向代理功能。
- DBMS的容错是通过DBMS实现的。
- 使用 Configuration Manager for Jira 插件在环境之间传输更改。
- 图中的AppSrv是一个原生的报表应用服务器，没有使用Atlassian软件。
- EasyBI 数据库是为使用 eazyBI Reports and Charts for Jira 插件构建立方体和报告而创建的。
- Confluence Synchrony 服务（允许同时编辑文档的组件）没有分离到单独的安装中，而是与 Confluence 一起在同一台服务器上运行。
许可
Atlassian 许可问题值得单独写一篇文章，这里我只提一般原则。
我们遇到的主要问题是数据中心版本的许可问题。 服务器和数据中心版本的许可功能：
- 服务器版的许可证是永久性的，即使在许可证过期后客户也可以使用该软件。 但许可证过期后，买方将失去获得产品支持和将软件更新到最新版本的权利。
- 许可基于“JIRA 用户”全局权限系统中的用户数量。 他们是否使用该系统并不重要——即使用户从未登录过系统，所有用户都将被考虑到许可证。 如果超过许可用户数，解决方案是删除部分用户的“JIRA 用户”权限。
- 数据中心许可证实际上是一种订阅。 需要每年支付许可费。 在任期届满时，系统的工作将被阻止。
- 许可证的费用可能会随着时间的推移而变化。 正如实践所示，在很大程度上，也许是显着的。 因此，如果您今年的许可证费用为一笔费用，那么明年的许可证费用可能会增加。
- 许可由用户按级别（例如，级别 1001-2000 用户）完成。 可以升级到更高级别，但需支付附加费。
- 如果超过许可用户数，将创建新用户，但无权登录（'JIRA Users' 全局权限）。
- 插件只能获得与主软件相同数量的用户许可。
- 只有生产性安装需要获得许可，其余的您可以获得开发者许可： .
- 购买维护需要购买Renew Software维护——费用约为原软件成本的50%。 此功能不适用于数据中心并且不适用于插件 - 您必须每年支付全部费用以支持它们。
因此，对于服务器版，年度软件支持成本占软件总成本的 50% 以上，对于数据中心版，则为 100% - 这明显高于大多数其他供应商。 在我看来，这是 Atlassian 商业模式的一个显着缺点。
从服务器版过渡到数据中心版的特点：
- 从服务器版到数据中心版的转换是付费的。 价格可以在这里找到 .
- 从服务器版切换到数据中心时，您无需为更改插件的版本付费 - 服务器版的插件将正常运行。 但有必要为 Data Center 版本更新插件许可证。
- 您可以使用没有适用于 Data Center 版本的版本的插件。 同时，当然，此类插件可能无法正常工作，最好提前提供此类插件的替代方案。
- 升级到 Data Center 版本是通过安装新许可证完成的。 同时，服务器版的许可证仍然可用。
- 对于用户来说，数据中心版和服务器版之间没有功能差异，所有差异仅在于管理功能和安装的技术能力。
- Server 和 Data Center 版本的软件和插件成本不同。 成本差异通常小于 5%（不是必需的）。 成本计算示例如下所示。
功能实现范围
基本的 Atlassian 软件包包含大量功能，但通常严重缺乏系统提供的功能。 有时即使是最简单的功能在基本包中也没有，因此几乎任何实现都离不开插件。 对于Jira系统，我们使用了以下插件（图片可点击）：
对于Confluence系统，我们使用了以下插件（图片可点击）：
对带有插件的表的评论：
- 所有价格均按2000个用户计算；
- 价格以所示价格为准 ，实际成本（有折扣）更低；
- 如您所见，数据中心版和服务器版的总量几乎相同；
- 仅选择使用支持 Data Center 版本的插件。 为了系统的稳定性，我们从计划中排除了其余的插件。
注释列中简要描述了该功能。 附加插件扩展了系统的功能：
- 添加了几个可视化工具；
- 改进整合机制；
- 增加了瀑布模型项目的工具；
- 添加了可扩展的 Scrum 工具来组织大型项目团队的工作；
- 添加了时间跟踪功能；
- 添加了用于自动化操作和配置解决方案的工具；
- 增加了简化和自动化解决方案管理的功能。
此外，我们使用 . 此应用程序允许您在外部应用程序 (MS Office) 中编辑文件并将它们返回到 Confluence（签入）。
用户工作站应用程序（胖客户端） ALM Works Jira 客户端 由于供应商支持不力和负面评论，决定不使用。
为 与 MS 项目集成 我们使用一个自行编写的应用程序，允许您从 Jira 更新 MS Project 中的问题状态，反之亦然。 将来，出于同样的目的，我们计划使用付费插件 ，它作为 MS Project 的附加组件安装。
与外部应用程序集成 通过应用程序链接实现。 同时，Atlassian 应用程序的集成已预先配置并在设置后立即运行，例如，您可以在 Confluence 的页面上显示有关 Jira 中的问题的信息。
REST API 用于访问 Jira 和 Confluence 服务器： .
SOAP 和 XML-RPC API 已弃用，无法在新版本中使用。
结论
因此，我们考虑了基于 Atlassian 产品实现系统的技术特征。 提议的解决方案是可能的解决方案之一，非常适合企业环境。
所提出的解决方案是可扩展的、容错的，包含用于组织开发和测试的三个环境，包含系统中协作的所有必要元素，并提供范围广泛的项目管理工具。
我很乐意回答评论中的问题。
来源： habr.com