SUSE 如何构建其 Enterprise Linux 发行版–第 3 部分

二月 28, 2020 | By: Ying Ma

在本系列文章中，我们将深入探讨 SUSE Linux Enterprise 产品开发，这里是其中的第三篇博客。您将通过这些文章获得 SUSE 和 SLE 产品的第一手概况，了解工程团队如何应对日新月异的开源项目、来自客户和合作伙伴的新需求，以及与业务相关的限制等

SUSE 如何构建其 Enterprise Linux 发行版：

无论您是 SUSE 的长期客户、新客户、SUSE 的合作伙伴，还是 OpenSUSE 的粉丝或开源的狂热爱好者，我们都希望这些博客在让您觉得有趣有用的同时也能够让您获得丰富的内容。

Service Pack

支持的升级路径概述

如果开源项目能够立即支持所有必需的和理想的功能，那就太好了。如果没有 bug，也没有已知的安全问题，那么我们就可以部署系统，而不必担心更新或潜在的回归风险。事实上，软件总是有必须解决的 bug 和安全问题。此外，新的特性和功能正在不断开发、增强和优化。

截至目前，我们支持 SUSE Linux Enterprise 的两个主要版本：SLE 12（2014 年 10 月发行）和 SLE 15（2018 年 7 月 16 日发行）。

SUSE 研发通常将这些“主要版本”称为“代码流”。在“通用代码基”的基础上，我们不仅可以谈论 SUSE Linux Enterprise Server，还可以谈论整个 SUSE Linux Enterprise 系列，其中包括 SUSE Linux Enterprise Server (SLES)、SUSE Linux Enterprise Server for SAP Applications (SLES4SAP)[1]、SUSE Linux Enterprise Desktop (SLED) [2]和它的“兄弟”SUSE Linux Enterprise Workstation Extension (SLEWE)[3]、SUSE Linux Enterprise High Availability(SLEHA)[4]、SUSE Linux Enterprise High Performance Computing (SLEHPC)[5]、SUSE Linux Enterprise Real Time (SLERT)[6]、SUSE Linux Enterprise Point of Server (SLEPOS)，后者现在被称为 SUSE Manager for Retail[7]。

目前，我们有两个完整的“代码流”要并行开发、发行和支持（最长 13 年），您可以想象，只有特定的流程和工程才能确保其按时发行。

至于 SLE 的“次要版本”，我们（14 多年前）决定在 SLE 版本中使用“Service Pack”模式。我们的目标是提供一个让用户能够为其更新做出相应规划的可预测的发行周期，同时安排发行针对给定主要版本的维护更新和新功能。过去，我们曾承诺每 12 到 18 个月发行一个 Service Pack，但是自 SLE 12 GA（5 年多前）以来，我们决定简化并增加发行频率，将发行周期定为 12 个月，并在新的 Service Pack 发行后的 6 个月内支持以前的 Service Pack。

为什么要这样做呢？其实，这个决定是根据我们的客户和合作伙伴的反馈做出的，也是因为开源开发的节奏越来越快。例如，举几个其他开源项目的例子，您是否知道每两个月就有一个上游的 Linux Kernel 次要版本，Mozilla 每 6 周发布一个新的 Firefox 版本，而 GNOME 每 6 个月创建一个完整的稳定版本。

为了跟上开源项目的步伐，同时为所有企业用户提供选择和清晰的思路，我们每年发行一次“次要版本”（通常被称为“Service Pack”），并提供两个主要的 SLE 版本，但这只是解决办法的一部分。

我们将在另一篇博客中专门讨论 SLE 的发行计划，但是在这些技术性的讨论之前，我们想让您更深入地了解我们的发行管理团队，也就是那些发行背后的人员和团队。

发行管理

在 SUSE Linux Enterprise Team（SUSE Linux Enterprise 团队）中输入 Release Manager（发行管理人员）角色。当然，要应对两个主要的 SLE 版本及其各自的 Service Pack，背后不只有一个 SLE 发行管理人员，而是一个发行管理人员团队。这个团队负责成功交付 SLE 产品系列和 openSUSE Leap（更多关于 openSUSE 的内容将在以后的博客中专门介绍）、完善流程和工具、推动SLE研发部门提高效率

当然，他们应该创建一个开发计划表，它能够满足不同的利益相关者，第一个客户发货日期的产品管理，为内部测试提供足够时间的质量保证，当然，还能够为工程设计的开发带来更合理的时间规划

SUSE 拥有的是一个真正的国际化员工队伍，产品管理、质量保证、合作伙伴管理和工程设计团队分布在全球各地。SUSE 最大的办事处设立在纽伦堡（德国）、布拉格（捷克）、北京（中国）和普罗沃（美国），有三分之一以上的员工在偏远地区工作。在规划阶段，发行管理人员务必要考虑到公休日和人们最可能休假的时间，以确保为开发交付和构建测试提供最佳的发行计划。

发行管理人员会根据多种因素，例如，对即将发行版本的功能需求进行审查、特定的产品需求以及从多年的 SLE 发行中获得的经验等人为因素，制定开发计划。

该计划将始终包含一些缓冲，特别是在情况需要时包含其他预发行版本。就像两年前 Meltdown 漏洞被公布时我们需要进行调整一样。

我们将不再深入讨论发行管理人员的职责和任务，但现在您知道他/她有责任根据多个约束条件来制定计划，他/她还将审查产品中的每个代码提交，就每个预发行版本与质量保证团队进行广泛的讨论，与负责特定技术或体系结构的多个技术项目经理进行交谈等等。

接下来，我们将对过去和现在的 SLE 计划展开讨论。

[1] https://www.suse.com/products/sles-for-sap /

[2] https://www.suse.com/products/desktop /

[3] https://www.suse.com/products/workstation-extension /

[4] https://www.suse.com/products/highavailability /

[5] https://www.suse.com/products/server/hpc /

[6] https://www.suse.com/products/realtime /

[7] https://www.suse.com/products/suse-manager-retail/