为什么迟到飞行而不飞行并不总是一件坏事？ 谁应该为码头迟到负责？ 为什么要提前到机场？ A380可以飞往阿斯特拉罕吗？ 为什么直觉并不总是有效？ 惊喜在发生-从未发生过，再次出现？ 乘客着陆后为什么要猛烈抨击飞行员？假设您正在开发一个全国范围的州级信息系统（GIS）。 项目团队（分析师，开发人员，测试人员，支持服务，基础结构服务等）有一百多人。 该系统已在试验或工业操作中实施。 成千上万的组织已经与您的系统集成并开始使用它，甚至更多的组织正在计划集成。 数以万计的组织通过Web界面进行工作。 该系统包含对公民有用的信息，并提供有趣的功能。 客户和/或用户需要新的改进。 全国有数百万人在注册并使用该系统。 来自外界的礼物以油价变化，制裁，限制等形式出现。
赠送？ 因此，目前正是这样的一个项目是GIS住房和公共服务项目，我们早些时候就开始
谈论它，现在我们希望继续。
来源赖特兄弟的初体验
最有可能的是，如果您在一家小型公司工作并开发“小型项目”，那么您的发布流程就不会那么多。 工作计划看起来像这样。 您只是假装在4-5个月内发布一些功能会很不错。 然后，您再编写一个月的产品，进行开发，开发，然后尝试稳定所有这些经济情况，以便发布该软件的新版本。 当然，到发布之时，事实证明，某些改进无法以任何方式稳定下来，在某些地方发现了产品中的缺陷，因为这些产品已经做了很长时间了，现在有些变化了，有些地方证明它们是在不现实的功能下签名的，等等。但是，这种方法本身就很好用，但是通常，只要项目团队很小并且变更的强度很小（系统未投入运行或由某些用户试用，等等）。 原则上，没有流程，您可以扩展到相当大的项目-最多20个人，最多40个人-这全都取决于个人的冷静和奉献精神。 当项目团队由冷酷绝望的专家组成时，如果截止日期临近，几乎所有事物都友好地消失了，……“在他们的肩膀上”，“道德和坚强”披萨盒在山上，肯定会有很多人熟悉这种情况。最终将该版本投入运行。
威伯（Wilber）和奥维尔·怀特（Orville Wright），与赖特（Wright）兄弟一样深深地陷入了历史，是世界上第一个制造飞机并在上面飞行的人。 来源相信我，我们也经历了这一点（这就是为什么我们现在喜欢各种疯狂的事物，例如
赛车英雄 ，
马拉松等等）。 但是到了某个时候，我们意识到一切都有局限性，并且在没有明确发布流程的情况下实施GIS规模的住房和公共服务系统时，我们肯定会遇到三个主要的不愉快时刻：
- 客户对您不满意，因为 您无法预测该功能的发布日期并不断突破截止日期，并且如果发生无法预料的任务，则会导致严重问题；
- 由于持续的混乱，摊牌，加班等，员工的生活质量正在恶化；
- 您公司的领导对您不满意，因为 成本将完全无法控制。
LANIT在GIS住房和公共服务开发方面的经验告诉我们，在大型项目的实施过程中，转换为“工业轨道”的最重要时刻之一就是发布过程的质量建设。 当然，这还不足以使人获得完全的幸福，但是释放过程是一切的基础，如果没有释放，您肯定会变得比现在更糟。
在本文中，我们将描述两种主要的实践，它们是GIS住房和公共服务规模的IT系统中有效发布过程的基础：
一方面，这些实践是众所周知的，并已用于许多方法中，并记录在《
敏捷宣言》中 。 但是，它们与直觉大相径庭，需要一定的资格和技能，因此很难在客户和项目团队中找到理由并缺乏理解。 它们在公司标准中的实施将需要对“我们要实现的目标”和“为什么这些实践的实施究竟能带来预期的结果”有很好的理解。 下面我们将以示例的方式考虑这些做法以及实施中的主要问题。
当我们分析与发布管理相关的内部流程时，与现代航空公司的工作相关联出现在我的脑海中。
定期空中交通
该航空公司进行了市场分析，预测哪些航线将带来大量客流，并在下个季度变得有利可图，与需要的人进行谈判，获得必要航线的权利，开通常规航班。 通常，航班时间表的时间很长，通常为六个月到一年。 当然，究竟是谁飞行，航空公司也不为人知-它专注于平均预计入住率。 此外，航空公司可以与机场签订长期协议，考虑哪些飞机最适合搭乘飞机，建立自己的内部程序等。 所有这些都有助于成本优化。来源如果公司员工需要在某个特定时间参加重要会议，然后乘飞机飞往另一个城市，那么他只需考虑到会议被推迟的风险和交通状况，自己为自己选择航班。
定期航班有其缺点。 如果员工购买了机票但没有时间，那么飞机将不会等待。 不愉快吗 是的 可能是员工今天需要飞走，而只有明天或从现在起一周才有航班。 不太好吗 是的 但最大的好处是您可以计划六个月或一年的行程，并确保可以进行飞行。 您确切地知道什么时候到达，您可以将此时间告诉可以见到您的亲人，或者您可以乘飞机转机而不必担心没有时间停靠。 好吧，总的来说，想一想，一架巨大而沉重的铁架飞机（对于90％的人类根本不了解它是如何飞行的）会很快将您载着，魔鬼知道在哪里，这将花费您差不多一两天的火车时间。让我们回到项目。 GIS实用程序使用常规功能。
LANIT团队制定了1年的发布时间表，其中确定了发布日期，因此每月发布大约1次。 由于在这一年中，一切仍然可以改变一百次（下面有更多内容），因此在编制时间表时，我们仍然不确定确切地实施和实施哪些改进措施。
在计划时，会考虑基础设施/运营服务所需的例行维护计划。 全局变化和异构变化必须彼此不重叠-这样可以降低风险，并且更容易控制一切。 例如，安装软件的新版本并同时升级DBMS版本或更新存储控制器的固件是一个非常糟糕的主意。
关键点是发布日期不会随后更改。 如果该版本计划在某个日期发布，那么我们必须轻而易举，但要承受计划的时间。接下来，我们将解释原因和原因。
每个版本的条件大致相同（持续时间，团队，特定任务等）的事实使您可以计划和调试所有准备和发布过程。
不参与生产过程的人可能不了解在GIS住房和公共服务等大型项目上发布版本的复杂性。 为了发布该版本，您需要执行大量操作，例如回归测试（可能需要多次），负载测试，测试部署和迁移脚本，分析性能统计信息（SQL查询，服务等）。 。 这些操作可能会很长，例如，在测试平台上部署版本可能需要一天的时间，这使情况更加恶化。 如果出现问题，您可以轻松退出计划。 因此，如果您没有一个定期且大致相同的工期时间表，那么我保证每个问题对您来说将是146％的更为严峻的考验。
为了确定缺陷纠正的期限并将其传达给用户，还需要制定时间表。 通常，我们会纠正当前版本中的大多数现有缺陷。 但是，某些缺陷可能需要更多时间，或者可能在发布周期结束时发生，因此将它们转移到下一个版本。 如果由于某种原因（请参阅下文）我们开始转换版本，则用户以后会自动收到更正，这不好。
还需要计划版本的发布时间表，以计划具有明确期限的改进版本的发布。 生产团队确切地了解何时应实施修订版，并选择所需的版本，并在其中发布。 如果发布日期被推迟，则可能导致修订版本发布晚（关于由于重要任务而导致的版本更改的后果，请参见下文）。
就像常规的运输链接一样，这是全球运输系统的基础，基于常规功能交付的发布过程是有效开发GIS规模的住房和公共服务系统的基础。 如果建立了此过程，则已经有可能“串起”计划以实现和交付功能。
不幸的是，从各个方面介绍这种看似有用的做法的方法既困难又棘手。 以下是团队可能陷入的主要陷阱，应该对其进行监视和抑制。
注册后登机
航空公司简化了航班登机手续，其中特别包括一项规则：旅客必须在出发前40分钟内办理登机手续。 为什么需要这40分钟？ 需要它们，以便有足够的时间检查行李并将其装载到飞机上，以便根据行李的重量和登记的乘客数量可以计算所需的燃料，为飞机加油等。 另外，这个时间是必要的，以便乘客有足够的时间找到所需的出口/终点站。 显然，货物或乘客可能出了点问题（乘客在机场迷路或行李发生了故障），即使这40分钟也不够。 但是，尽管如此，在浪费乘客时间和发生紧急情况的风险之间进行折衷是多年以来折衷的结果。
如果乘客喜欢在登机手续即将结束时到达机场，那么这仅表示他同意发生某些事情的风险增加，并且他不会及时赶上飞机。 如果航空公司遇到这些人，将导致事实增加风险。 也许她将只需要为此乘客付费乘坐特殊的飞机航班。 也许是在最后一刻急于办理登机手续时，机场工作人员会犯错，行李会飞到错误的城市。来源发布发行版时，最重要的一点是修订必须满足的标准以及完成修订的截止日期（类似于检入结束）。 每月发布该版本意味着如果在当前版本的软件中尚未完成某些任务，而该任务将在一个月内转移到下一个版本。 通常您可以忍受这一点，但是当任务非常重要时却很难做到这一点，但同时又只有几天或一周的延迟。 有一个很大的诱惑要打破截止日期，并在发行版中包含尚未完成的任务，然后尝试将其挤出来。
为什么这样不好？
首先，
我们必须勇敢地接受并接受这样一个事实，即所有“压力”，“如果我们能抓住它的话”很可能是生产管理中的一个小问题。 这意味着没有提前采取各种措施，情况变得很危急。 现在，由于个人或团队的“英雄”-加班，拐杖，运气等，这种情况将得到纠正。 从经验来看，这可以在短期内解决问题，但如果您始终这样做，将导致人们“精疲力尽”和其他非常不愉快的后果。
其次，就像航空公司的例子一样，任务准备的最后期限是时间表和风险之间的折衷。 如果我们开始超过最后期限，则会增加版本出现问题的风险-要么无法按时发布整个版本，要么降低质量，并且由于无法正常工作或在负载下无法正常工作会收到大量电话。
不幸的是，出现了一项非常非常重要的任务，有必要在当前版本中将其发布的情况。 但是主要思想是，这种情况不应被普遍接受和鼓励，而应被视为问题并在“回顾”中予以考虑。VIP乘客造成的航班延误
假设您购买了转机航班。 假设您确定了两次连接之间有足够的时间。 您提前到达机场，办理了登机手续，登上飞机，给我父亲和妈妈打电话，然后他们宣布航班延误，因为 一个重要的政府代表团为时已晚（当然，相反，他们会告诉您有关恶劣的天气或其他检查：）。 您和整个飞机都在等待这个委派，结果，飞机飞离了很大的延迟。 到达中间点时，您发现只有30分钟的时间才能在一个巨大的机场中导航，然后实际到达另一个航站楼。 当然，也许您会及时到位，或者您可能会急于弄乱某些内容并逃到错误的终端，甚至只是没有时间去执行所有必要的步骤。 如果您也是某个其他政府组织的成员（但只是谦虚的成员），并且还急着去某个地方？来源因此，如果航空公司定期允许航班转换，那么这将导致各方面的问题。 对于乘客来说，这意味着他将需要花更多的时间进行连接，乘客将更有可能冒险并一直到注册结束。 这将导致更多的冲突并浪费时间。 对于航空公司而言，这还意味着需要更多时间在机场停机，从而增加了成本。在发布过程中，如果突然某个任务没有计划的时间，那么也很可能将整个发布（例如，一周）转移。 看来这是一个简单而又好的解决方案，尤其是如果此任务在主要客户的控制之下。让我们看看所有这些最终会导致什么。
在GIS住房和公共服务项目中，在下一发行版的框架内，发布了多达100个任务和更多错误修复程序。 发行变更意味着用户将在以后获得所需的功能或错误修复。 当然，正在讨论的问题确实很重要，但是与此同时，其余的99个任务中的许多任务也非常重要，但是由于它们的一切正常，我们已经忘记了它们。
下一个 如果我们开始定期更改版本，那么客户将开始对发布计划失去信心。 他总是坐在脑海中，想当然，下一个版本计划在10日发布，但是很可能会发生某些事情，并且每星期或什至两周会有一次轮班。 转变的原因可能有所不同，但最终它们都被遗忘了，并且仍然感觉到过程不稳定且不透明。
这会导致什么？ 而且，如果出现紧急缺陷或任务，则客户不同意将其作为特定版本的一部分发布，而是需要特殊版本或修补程序。 结果，我们有大量的额外费用。如果我们允许版本转换，那么这会降低优化流程的能力。 相反，如果发布程序是统一且定期的，那么我们就有机会对其进行改进。 版本发布后，我们进行“回顾”，讨论迭代过程中发生的主要正面和负面观点。 每次重复，我们都会进行某种改进，结果是减少了开销成本，减少了错误数量，从而改善了结果。
为什么大飞机并不总是更好
航空公司可以在航线上使用不同类型的飞机：容纳75-110名乘客的支线飞机（ SSJ-100型 ），或容纳140-180名乘客的窄体飞机（ A320型， 波音737型 ），或容纳200-300名乘客的宽体飞机（ A330型） ， A340或A380之类的怪物，能够运送525至853名乘客。 简而言之，我们可以假设航空公司选择了所需的飞机类型和所需的飞行强度，以折衷于乘客每天有尽可能多的航班的愿望和航空公司为减少一名乘客的运输成本以最大程度地提高他们的利润而做出的选择。现在，至少有三家航空公司飞往我的家乡阿斯特拉罕，每天使用支线或窄体飞机进行一次飞行。 即使在阿斯特拉罕的机场基础设施允许接收A380（空中客车公司最大，最宽敞的飞机）以进行装载，也必须大幅度降低飞行强度，这对于乘客来说是完全不便的。 如果成本差异不大，则旅客每天会选择较多的航班。释放过程中大约有相同的逻辑。 发行版本之间的时间越短，对客户越有利。
如果发布过程完全是完全不可见和透明的，则对客户而言将是理想之选。我们执行了该任务，单击了按钮，它可以立即在舞会中正常工作，而无需停机。为了确保高版本发布频率，有必要提高自动化和调试过程的水平。在全面增长的情况下，产生了有关间接费用的问题。实际上，发布版本会涉及开销或发布成本。例如，我们进行诸如回归测试，压力测试，性能统计分析，部署脚本分析和数据迁移之类的工作。合理地假设发布周期越大，每单位“有用”发布功能所具有的开销就越少。事实证明，生产团队需要尝试增加发布周期的长度以降低成本。但是，这个结论是不正确的。下图显示了单位功能成本与发布周期长度之间的关系（对于我们的项目，我们的团队，当前的自动化水平，能力，运动服，内心的平静，俄罗斯足球队的表现结果）。图1.每单位产出的间接成本对发布周期长度的依赖关系（针对我们的条件）的确，如果我们想以“执行任务，单击按钮，一切都在生产中工作”的方式实施连续发布过程，或者每周发布一个版本，肯定需要我们作出重大的初步努力来重组工作。这很可能与自动化程度的进一步提高以及所有过程的规范和调试有关。也许这将需要进行一些体系结构更改。到目前为止，我们还没有进行任何工作，以至于发布周期相当长，只有两周或更短的时间，因此，我的假设是曲线的行为在指定范围内，这是基于产生小型中间版本和修补程序的经验。在三到四周的周期范围内，我们很可能在单位生产成本方面具有局部最小值，然后随着发布周期的延长，成本开始急剧上升。关于它下面。额外的货物-额外的燃料
假设航空公司承运了更多货物。这对她来说不是免费的，因为它将至少需要额外的燃料。不幸的是，在航空业中，不幸的情况是，由于贪婪或愚蠢而允许获得优势，这导致了空难。如果我们每三到四周发布一个发行版，那么每个版本的发行都需要某些程序 -这是回归测试，负载测试，部署脚本测试和数据迁移的两个周期（我们将在另一篇文章中对此进行详细介绍）。假设例如，如果将周期延长到两个月，则我们将需要为发布进行相同的工作，这是错误的。事实是，如果周期很大，那么会有更多变化落入其中。反过来，这会导致潜在问题区域的增加-在复杂的系统中，这种增长（如果不是指数级的）则肯定是（由于变化的相互影响）是非线性的。实际上，我们已经看到，对于四个星期的周期，一次回归测试迭代是不够的。实际上，在第一次回归的框架内，我们确定了一定数量的缺陷，对其进行了纠正，而变化的数量证明是需要进行更多“最终”回归的。最终回归对我们来说已经更加紧凑，通过速度更快且没有问题，但是仍然需要。如果我们切换到两周的发布周期，那么很可能我们只能进行一次回归。另一方面，如果我们将周期延长到1.5-2个月，那么为了稳定，我们不再需要1.5回归，而是需要2或3。新飞机客舱中的空姐宣布飞机上的情况：
-在第一层甲板上-行李在第二层甲板上-在第三层酒吧-在第四座游泳池上高尔夫球场。
并补充：
-现在，先生们，请系好安全带。现在，所有这些垃圾我们将尝试起飞。
如果我们进一步扩展发行版，那么变更的数量和风险将大大增加，以至于稳定过程将不再收敛。我们的飞机很可能不会在所有这些泳池和高尔夫球场上起飞。没去过这里
发布版本涉及相当复杂的基础架构。对于发行版，使用了多个测试台，配置了版本控制系统，组装线等。因此，我们尝试组织工作，以便在任何给定时间仅准备一个发行版。如果突然发现您需要支持多个版本，那么这将大大增加成本。因此，我们正在尽最大努力避免这种情况。来源对于初学者，我们必须承认计划外和紧急任务会发生。因此，当发生这种情况时，期望一旦任务准备就绪就将其投入商业运行。如果发布周期很长，那么惊喜正等着您！假设您的发布周期为四个月。事实证明，计划在未来几天内发布该版本的可能性很小。在这种情况下，您需要为此任务制作一个特殊版本，准备一个发行版并将其发布在舞会中。这是额外的费用。即使就在前一天发布了某个版本，也是如此。在这种情况下，很可能是由于您挤压了其他任务，因此您将违反发行版的准备计划。这可能会导致您想要转移版本。我认为，这样做的后果甚至比制作特殊版本还要糟糕。相反，如果您每两周发布一次，则可以尝试将该任务包含在当前版本中，或者最糟糕的是将其包含在下一个版本中。在这种情况下，从准备好任务开始到释放任务，在最坏的情况下，将经过4周，最可能是2-3周。这通常是完全可以接受的。这意味着您很可能无需额外的基础架构成本。根据更改发生的频率，您可以从较短的发布周期中获得更多收益。在GIS住房和公共服务规模的项目中，计划外的紧急变化相当经常地发生。认识到这一事实需要付出一些努力（更不用说躲藏了-很有勇气），因为在这里，我们在某种程度上也与直觉和不愿冒险共事发生冲突。事实是，如果考虑到特定风险，可能会导致需要制作特殊版本，则其可能性很可能是微观的。如果上个月由于立法变化或一些新发现的地区特征而没有任何改善，那么我们预计下个月不会有任何类似的事情。因此，可以得出结论，由于每个事件的概率很小，因此什么也不会发生。但是，这是错误的结论。事实是，概率至少有一个风险被实现等于每个个体风险的概率之和。因此，如果我们考虑甚至在发布周期的一个月内发生的所有事情的规模（准备版本所需的关键员工数量，做出的决定，集成GIS的外部系统数量，基础架构的复杂性，主题领域的复杂性等）。 d。），那么这种可能性本身就已经相当可观了。例如，即使从2018年1月到2018年5月的发布周期为一个月，我们也已经毫不夸张地说已经完成了非常重要且非常紧急的任务，这些任务必须由ASAP进行并且需要特殊版本。关于4-5个月的发布周期，我们能说些什么！如果我们每5个月毕业一次，那么很可能会将2-3个附加的中间版本添加到这两个特殊版本中，这使得发布周期超过1-1.5个月在我们的条件下完全不经济。因此，允许您灵活地响应更改的发布过程对于GIS实用程序规模的项目来说是一个很大的好处。我们只有在降落后才鼓掌飞行员！
每次未完成的改进都会带来版本发布的风险。无论他们的眼睛有多诚实，您都无法发言。最好相信事实。根据我们的经验，只有在对修订版进行了全面测试并且所有关键缺陷都得到修复后，您才能或多或少地保持安静的呼吸。此后，通常已经消除了主要生产风险。但是在这种情况发生之前，不可能排除发生错误的事件的发展，而完善会开始威胁该版本的发布。我们已经说过多少次，明天将对修订进行测试，不会有任何问题，然后再出现问题。如果修订部分或全部完成，但被推迟了，那么很可能在半年后返回时，您会发现它不再起作用，系统中的所有内容都已更改，您需要再次理解它。保持延迟改进的相关性是额外的无用费用，最好也避免使用。资料来源不仅如此，由于GIS住房和公共服务主题领域的复杂性，始终存在在设计过程中提出非最佳解决方案或未考虑某些区域特性的风险。许多点只能在飞行员操作期间识别。这是缩短发布周期并更快地将改进发布到运营中的另一个论点。您将更快地获得反馈，更快地测试您的决策，并能够快速完成客户和市场的实际需求。如果发布周期较长，则相反会引发冗余功能，从而增加了花大量精力处理后来发现错误或不必要的风险。机组人员向乘客说再见
我们回顾了对我们至关重要的关键发布管理实践。这是常规功能，并且减少了发布周期。不幸的是，尽管这些做法声名widespread起，但实际上并不十分明显，并且与直觉有些矛盾，因此，它们的实施常常遇到障碍。作为GIS住房和公共服务的一部分，这些做法已得到实施，已经成功运行了很长时间，并显示出良好的效果。我们确保严格遵守发布时间表，版本发布的准备过程已得到更严格的控制，并且更加有序和有规律，我们可以灵活地响应更改。当然，生活不仅限于文章中指出的建议。船上有许多有趣的细微差别和情况，例如：- 旅客办理登机手续，托运行李然后免税狂饮而错过登机时该怎么办，
- 如果货物不适合常规航班上的飞机怎么办，
- 如何准确地安排注册，验证等
下次将讨论。听到您的意见会很有趣。您是否同意本文中的陈述和建议？您如何管理大型项目的发布管理？实施容易吗？