Questions tagged «release-management»

这并不是一个真正的技术问题，但是这里还有一些其他有关源代码控制和最佳实践的问题。 我工作的公司（将保持匿名）使用网络共享来托管其源代码和发布的代码。开发人员或管理人员的责任是根据源代码是否已发布以及版本和内容将其手动移动到正确的文件夹中。我们围绕着记录文件名和版本以及更改内容的地方散布着各种电子表格，并且一些团队还在每个文件的顶部放置了不同版本的详细信息。每个团队（2-3个团队）在公司内部的做法似乎有所不同。可以想象，这是一个有组织的混乱-有组织，因为“正确的人”知道他们的东西在哪里，但是却一团糟，因为它们完全不同，并且依赖于人们随时记住要做的事情。 一段时间以来，我一直在努力寻求某种托管源代码控制，但在公司内部似乎无法获得足够的支持。我的主要论据是： 我们目前很脆弱；在任何时候，任何人都可能忘记执行我们必须执行的许多发布操作之一，这可能意味着未正确存储整个版本。如有必要，可能需要数小时甚至数天的时间才能将版本拼凑在一起 我们正在开发新功能以及错误修复，并且由于某些工作尚未完成，因此常常不得不延迟发布其中一个。我们还必须强迫客户采用包含新功能的版本，即使他们只想修复错误也是如此，因为我们实际上只在开发一个版本。 我们遇到了Visual Studio问题，因为多个开发人员正在同时使用相同的项目（不是相同的文件，但是仍然会引起问题） 只有15个开发人员，但我们的工作方式有所不同。我们都必须遵循一种标准的全公司范围的方法，这会更好吗？ 我的问题是： 如此规模的小组没有源代码管理是正常的吗？ 到目前为止，我仅获得了没有源代码控制的模糊原因- 考虑到上述信息，您认为哪些原因对于不实施源代码控制可能是有效的？ 我可以将更多的源代码控制理由添加到我的武器库中吗？ 我主要是想了解为什么我受到如此多的抵制，所以请诚实地回答。 我将给我相信采用最平衡方法并回答了所有三个问题的人的答案。 提前致谢

152 version-control  project-management  management  release-management 

我似乎反复陷入这样的情况，即发布日期的确定不是基于任何技术因素，而是因为Sales某个人当时已经承诺要与客户联系。根据与其他公司开发中的朋友的讨论，似乎发生了同样的事情。 “这里是承诺的功能集，这里是承诺的发布日期”，很难争辩，因为在这一点上有钱可赚，而这一切都胜过一切。 总的来说，有没有办法解决这个问题？ 如果不是此版本，将来如何？我的问题是，我看到这样做的唯一方法是尽我所能，但是可以说按原样发布软件。 我不想发布臭虫缠身的软件，因为它是我的名字，但是一次连续80小时工作几个月，一次就证明了任意设置的发布日期。 编辑：记录下来，我现在不每周工作80个小时，这是我想到的，因为要满足发行日期之前预期的功能集需要什么。

120 communication  estimation  release-management 

我最近开始将代码置于版本控制下（在实验室中，我正在SVN下工作，而我自己的代码在github中（显然是git））。在使用版本控制之前，我曾经做过类似的事情。我有一个带库名称的文件夹，其中有许多带版本号的文件夹。每当我想开始使用新版本时，我都会复制上一个版本，将名称更改为新版本并开始实施。 但是，当将文件夹置于版本控制下时，这似乎是多余的。除了冗余之外，如果有人想获得最新版本，那么只要他import/ 她就可以下载所有版本clone。 现在，我看到了使用版本控制执行此操作的许多方法，但是由于我是新手，所以我不知道哪种方法更可维护。 方法1：使用标签 如果我正确地理解了标签，那么您将拥有主分支，您可以进行所做的任何更改并使用版本进行标签。然后，当您想要获得它的工作副本时，您将获得带有特定标签的副本。（如果我错了纠正我） 方法2：分支版本 在这种方法中，主要分支将是开发分支。时不时地制作一个稳定的版本（例如v1.2.0），您为该版本创建一个分支，并且永远不要提交它。这样，如果您要下载某个版本，则可以从该分支获取代码。尽管我说过您从未承诺过这样做，但有可能进行错误修复并承诺到旧版本的分支以保持旧版本运行。例如，如果当前版本为v2.0，但是有些人想要使用v1.2，则可以从中获取另一个分支v1.2，即v1.2.1提交错误修复程序，或者仅将版本保持不变，v1.2然后提交错误修复程序。 所以分支看起来像这样： v1.2.1 v1.2.2 / / v1.0.0 v1.2.0--------- v2.0.0 / / / -------------------------------------- dev 这样，您可以为每个次要版本更新创建分支。（请注意，在上图中，v1.2.1和v1.2.2或在v2.0.0发布之后创建的，因此它们不是v1.2.0和v2.0.0之间的开发的一部分。可以将其视为对较早版本的支持） 方法3：分支发展 此方法与以前的方法相反。主分支将是最新的稳定版本。每当使用新版本时，都将创建一个分支（用于开发），使用您的代码，并在代码稳定后将其与主分支合并。 在这种情况下，分支看起来像这样： ________ ____ ________________ _____ dev / \/ \/ \/ ---------------------------------- latest_version 可能需要结合标签一起执行此操作吧？ 问题！ 无论如何，我的问题是，根据您的经验，这些方法中的哪一种被证明更实用？有没有已知的最佳方法（可能我没有弄清楚自己）？这些事情通常是怎么做的？

24 version-control  git  svn  branching  release-management 

产品版本（例如）v1.0.0.100不仅代表软件的唯一生产版本，而且还有助于识别该产品的功能集和修补程序阶段。现在，我看到两种方法来维护产品的最终程序包/内部版本/二进制版本： 版本控制。一个文件存储着版本号。持续集成（CI）构建服务器将具有脚本来构建软件，该脚本使用此签入的版本号将其应用于所需的软件的所有区域（二进制文件，安装程序包，帮助页面，文档等）。 环境和/或构建参数。这些在版本控制之外进行维护（即，它们不依赖于快照/标签/分支）。构建脚本以相同的方式分配和使用数字，但是它们只是以不同的方式获取值（将其提供给构建脚本，而不是让脚本知道相对于源树在何处获取该值）。 第一种方法的问题在于，它会使跨主线分支的合并变得复杂。如果您仍然维护同一软件的2个并行发行版，并且自上次合并以来两个主版本的版本均已更改，则将在合并两个主干之间时解决冲突。 第二种方法的问题是和解。回到1年前的发行版时，您将仅依靠标签信息来标识其发行版号。 在这两种情况下，版本号的某些方面可能在CI生成之前是未知的。例如，CI构建可能会以编程方式放入第4个组件，该组件实际上是自动构建编号（例如，分支上的第140个构建）。它也可能是VCS中的修订号。 跟上软件版本号的最佳方法是什么？是否应始终在VCS中维护“已知”部分？如果是这样，主线分支之间的冲突是否成为问题？ 现在，我们通过CI构建计划（Atlassian Bamboo）中指定和维护的参数来维护版本号。在合并到我们的master分支机构之前，我们必须小心一点，即在开始构建CI之前已正确设置了版本号。关于Gitflow工作流程，我认为，如果在源代码管理中跟踪了版本号，我们可以保证在创建release分支以准备发布时正确设置了版本号。质量检查人员将在该分支机构上执行最终的集成/烟熏/回归测试，并在签收后进行合并，master这表示发布承诺。

22 version-control  continuous-integration  versioning  release-management  continuous-delivery 

我知道这是一个非常基本的问题。如果有人能使我幽默并告诉我他们将如何处理，我将不胜感激。 我决定发布此内容，因为我将要安装SynchToy来解决以下问题，并且使用“ Toy”感到有点不专业，但是我想不出更好的方法。 当我处于这种情况下，我发现很多时候，我都缺少一些痛苦而明显的做事方法-这是因为它是公司中唯一的开发人员。 在计算机上工作时开发的ASP.NET Web应用程序 解决方案有2个项目： 网站（文件） WebsiteLib（C＃/ dll） 使用Git存储库 部署在GoGrid 2008R2 Web服务器上 部署： 进行代码更改。 推送到Git。 远程桌面到服务器。 从Git中拉出。 通过使用Windows资源管理器拖放来覆盖实时文件。 在第5步中，我从网站根目录中删除所有文件。这不是一件好事。这就是为什么我要安装SynchToy ... 更新：感谢所有有用的回复。我无法选择哪个人来标记答案-在使用Web部署之间-看来我有几个有用的建议： Web Project =将整个站点打包到一个DLL中-对我来说，我无法进行简单的更新-作为50个公司的开发人员，这有时会更简单。 从SCM直接拉到站点的Web根-我最初并不是这样做，因为我担心我的SCM隐藏目录可能最终被暴露出来，但是这里的答案帮助我克服了这一点（尽管我仍然不喜欢拥有一个还有更多的事情需要担心忘记以确保随着时间的推移仍然是正确的） 使用Web场并系统地部署到节点-这是零停机的理想解决方案，这实际上是我关心的问题，因为该站点实质上是我公司的实时收入来源-我可能很难说服他们服务器成本却翻了一番。 ->最后，重申基本原则，即需要对站点进行一次单击部署，否则可能会出错，这是我从答案中得到的最有用的东西。 更新2：我以为我会回到此位置，并使用已经存在了几个月并且可以正常使用的实际解决方案进行更新（对于我的单个Web服务器解决方案）。 我使用的过程是： 进行代码更改 推到Git 远程桌面到服务器 从Git拉 运行以下批处理脚本： cd C：\ Users \ Administrator ％systemroot％\ system32 \ inetsrv \ appcmd.exe停止站点“ /site.name：默认网站” robocopy文档\代码\ da …

21 web-development  deployment  websites  release-management  configuration-management 

将签名授权给测试人员是否有意义？应该有一个测试团队 只需测试功能，问题等，并仅在通过/失败的基础上进行报告，然后由其他人根据这些结果采取行动，或者 是否有权根据这些结果自行阻止发布？ 换句话说，应该要求测试人员实际批准发布吗？与我一起工作的测试团队认为他们确实这样做了，因为“测试范围蠕变”，我们对此有疑问-拒绝批准发行版有时是基于有问题的发行版未明确解决的问题。

20 testing  release-management  process 

我目前管理的图书馆有很多公共用途，并且我对语义版本化有疑问。我想重构该库的一个相当重要的部分，该部分执行不正确-始终执行不正确。但是，这样做将意味着更改公共API，这是一个重大决定。 我要进行的更改围绕如何使用迭代器展开。当前，用户必须执行以下操作： while ($element = $iterator->next()) { // ... } 至少在PHP的本机Iterator接口中，这是不正确的。我要替换为： while ($iterator->valid()) { $element = $iterator->current(); // ... $iterator->next(); } 类似于： foreach ($iterator as $element) { // ... } 如果您查看Tom的语义版本控制指南，他清楚地指出，对公共API的任何更改（即那些不向后兼容的更改）都应证明是主要版本的合理性。因此，该库将从1.7.3跳到2.0.0，对我来说，这是一个太远的步骤。我们只是在谈论一个已修复的功能。 我确实有计划最终发布2.0.0，但是我认为这是您完全重写该库并实现了许多公共API更改的时候。引入此重构是否需要发行主要版本？我真的不知道它是如何工作的-我更愿意将其发布为1.8.0或1.7.4。有人建议吗？

18 versioning  release-management  semantic-versioning 

发布的最后期限是明天，您的同事最终完成了对于此发布至关重要的任务，项目经理站在您的肩膀上，并敦促您最终进行构建，并且您在审核过程中注意到同事的代码中存在缺陷。不是关键的东西，但是如果不是明天发布的东西，您将不会放手。更糟的是，您需要自己完成工作，并需要尽快完成。所以你会怎么做？尽管面临压力，您还是提出反对意见？ 我发现的一种方法是将该提交临时合并到另一个分支上，并留待以后检查。如果问题只是表面上的问题，并且是唯一仍在等待代码审查的问题，则它可以工作。但是，有没有更有效的方法来处理此问题？例如，您是否建议让一个人只进行代码审查和测试？

17 version-control  code-reviews  release-management 

我正在尝试收集其他人解决以下问题的有效方法。在工作中，我们被迫发布仅希望特定客户看到的软件补丁（安装在最终用户系统上）。定制代码位于其自己的源代码控制分支中。问题是我们有两条并行的代码行（和构建脚本）保持同步，并且每次我们修补原始代码时，我们都必须修补和测试客户特定的代码。 我很好奇，其他组织如何处理这种情况？我们向业务解决方案开放，而不仅仅是技术（与源代码控制相关）解决方案。例如，我们已经讨论过告诉客户他们无法在该分支上接收更新。 我们的分支策略是这样的（基于Visual Studio TFS分支指南，尽管我们正在使用Subversion）

16 version-control  business  release-management 

这里有点背景-我们是RAD开发人员的一个小团队（一个5人），负责一家大型非软件公司的内部软件开发。“内部软件”从使用MSSQL服务器作为后端的桌面.NET应用程序到在后台运行的Python脚本到MS Word文档和模板（技术之源）不等。 整个团队由全方位的人员组成，能够从用户那里获得需求，对其进行编码，对其进行测试并部署到生产中。一旦软件投入生产后，将由另一个团队负责，但是如果出现问题，通常我们很容易进行干预。 到目前为止，一切听起来不错，但是有一个问题-作为RAD团队，我们必须经常发布，而且如果没有我们发布一个或两个应用程序的新版本（也可能是脚本，更新的Word文档），就没有一天可做，C ++控制台应用等）导入生产环境。我们进行开发测试，并通过允许最终用户在UAT环境中运行软件来使其参与。 ...但是这些错误反正逐渐渗透到生产中。用户确实知道这些错误和偶尔的不稳定是他们为真正迅速获得所需付出的代价，但与此同时，它也让我们思考-也许我们可以改进开发或发布实践以提高稳定性。软件，并减少添加新功能时引入的错误数量。 优点-首先我们真的没有太多的流程，所以应该很容易就可以开始进行改进，不好的事情-作为RAD小组的一员，我们实际上没有太多的时间和资源来实施事情有些大，但我们一直在考虑以下举措，欢迎您提出任何反馈，提示，提示和建议。 当前，一些应用程序是在开发人员测试后直接发布到产品中的，而绕过了用户验收测试。应该停止这种做法，即使是很小的更改也必须由最终用户进行测试。每个应用程序都会有一个从最终用户中选择的专用beta测试器。仅在Beta测试人员确定新版本之后，它才能从测试环境升级到生产环境。 我们不进行代码审查-但是我们将在其中一位签入变更集之前开始进行代码审查。我也在考虑“发布审核”-基本上，一个开发人员必须坐在旁边，而另一位开发人员则看着他/她进行软件发布（复制二进制文件，更新配置，向数据库添加新表等）-通常它只是需要5到10分钟，因此不会花费太多的“发布审核”时间。 当一个新版本被证明具有足够的bug可以从生产中撤出并由一个好的旧版本替代时，如何减少回滚时间。我们确实存储了所有发行版本的历史记录（以二进制文件的形式），以使返回一个版本变得容易-尽管快速“用先前版本的二进制文件覆盖新发行的二进制文件”还是很容易的，但它仍然是一个手动过程，容易出错有时要求“如果回滚将失败并且将使系统无法使用而不是出现故障，该怎么办”。 这是我们用完我们的想法的地方，我们希望得到您的反馈，如果您可以分享一些简单的发行/开发过程改进建议，那就太好了。

15 development-process  release-management  rad 

如何将发布的二进制文件保持在版本控制之下？这样可以跟踪在每个发行版之间更改了哪些内容。我的意思是将发布的二进制文件与源存储库分开。发行的二进制文件可以从Continuous Integration软件构建，也可以手动编译。

14 version-control  release-management 

我知道这是一个广泛的问题，所以我将尽量具体。这个问题比技术性问题更像是一个“组织性”问题。 我们有一个包含以下主要组成部分的多面项目： 服务器，托管核心业务逻辑（数据模型） 使用核心业务逻辑的客户后台 也使用核心业务逻辑的应用程序API（REST） 有使用应用程序API的智能手机应用程序（iOS和android） 还有另一个平板电脑应用程序（android）与使用相同应用程序API的智能手机不同。 很快，我将在活跃的客户中投入生产。作为任何项目，我都需要随着时间的推移维护所有不同的组件。这意味着可以升级以下所有内容： 服务器中核心业务逻辑的代码（由后台，API使用，并且副作用是由移动应用程序使用） API本身（由智能手机和平板电脑应用程序使用） 所有移动应用（通过appstore / googleplay） 当然，服务器端部分（核心业务逻辑代码和API代码）可以由我自己立即更改。但是，客户端必须在appstore / googleplay上下载新的移动应用程序，而且我不确定它们是否是最新的。 您能否提供任何指导和良好操作技巧，以使这些升级顺利进行，并且对客户没有风险？ 我需要“版本”的哪个组件？即使客户端不升级其移动应用程序，如何确保一切正常？我应该强迫他升级以简化工作吗？ 简而言之，我应该如何组织才能使我的多面项目随着时间的推移而上线？

14 design  architecture  project-management  deployment  release-management 

我们是一家小型公司，拥有多个团队管理自己的git存储库。这是一个Web平台，每个团队的工件都在一天结束时部署以进行夜间测试。我们正在尝试使围绕版本控制和打包的过程正式化。 每个团队都有一个主分支，负责日常开发。每个团队的质量保证成员都希望将他们团队变更中的工件部署到测试台中，由厨师将所有组件组合在一起。工件是压缩包，但我想将其转换为RPM，以便我们可以正确思考和推理版本。 发布过程涉及从每个git存储库的开发分支（在大多数情况下为master）切断发布分支。然后将其提供给质量保证，由质量保证对一组工件进行测试和签核。 例如，这是一个典型的git存储库及其相关的发行分支： 0-0-0-0-0-0-0-0-0-0 (master) | | 0 0 (rel-1) | 0 (rel-2) 我一直在试图找出一种方案来执行来自开发分支的软件包的版本控制。我们不想过多地标记每个仓库的主分支，并限制标签仅释放分支。但是我们应该能够使用标准的yum / rpm语义查询测试机器中已部署的软件包。当master分支没有标签时，开发版本会是什么样？我知道这git describe可以为我提供构建版本的有用表示，但是当标记分支上的各个发行点时，它可以很好地工作。 编辑1：响应@ Urban48的答案 我认为我应该多解释一下发布过程。为了便于讨论，我们假设master在所有存储库中都有分支。该master分支被视为开发分支，并且已部署到支持CI-CD的自动化QA环境。这是每晚测试的子集，用于确保主服务器的稳定性。在削减发行分支之前，我们先看一下这一系列工作。我们的发行分支是短暂的。假设（从稳定的主服务器上）剪切了一个发布分支之后，将运行完全回归，进行修复并将其部署到生产中。这大约需要一周的时间。我们几乎每两周发布一次产品。 我们的功能分支总是从母版中剪切下来的，并在与母版合并之前经过一定量的开发人员测试，然后对它们进行CI-CD稳定性检查。 修补程序是在修补程序分支（从发行版分支切下的）上进行的，并以最小的影响测试将其部署到生产环境中。 以下是我们针对发行版和修补程序分支的版本控制策略。在质量检查周期中，发行分支会经历的版本v2.0.0-rc1，v2.0.0-rc2最后在质量检查批准后变为v2.0.0。 有时，我们会针对一些小功能进行点发布，这些小功能会合并到版本变为的版本分支（然后合并到母版）中v2.1.0。修补程序采用该v2.1.1模式。 但是，问题不在于对这些分支进行版本控制。我不希望完全更改此版本控制方案。唯一的变化来自开发部门。主。如何在CI-CD环境中可靠地指示在生产中的先前发行版中存在哪个版本。理想情况下，这可以通过智能git标记完成，但最好不要过度标记master分支。

13 git  continuous-integration  versioning  release-management  packages 

因此，我有一个程序要追溯到2011年，直到2012年为止，但最后一个版本是2011年12 月。我一直在积极地研究它，但是特征蠕变吸引了它丑陋的头，现在它充满了许多未完成的特征。 不好的部分是，随着我实现一项功能，一个新的功能应运而生。为了避免将来出现功能蠕变，我该怎么做，以便实际上可以在一年内发布它？ 该项目基于iOS，过去每个iOS版本更新都有发行版本，但最后一个版本是5.1（2011）。我希望能够恢复到稳定的发布周期，但是事实证明这太困难了。

12 programming-practices  release-management  scope-creep 

最近，我越来越被描述为我在该行业中最令人沮丧和士气低落的经历之一困扰：必须坐在经过测试，重新测试，上演的发行版上，并且出于所有目的并且已经准备好装运/部署目的。 作为一个全方位解决方案的人，而不仅仅是一个顽固的编码人员，我确实理解甚至提倡适当的变更控制。但是最近，在覆盖我们的基地和按时运输之间的微妙平衡已经变得不平衡了，在恢复到理智的状态上，我几乎没有成功。 我正在寻找有说服力的论据来帮助说服规避风险的管理人员： 开发团队应该（或必须）能够设置自己的发布时间表-在一定的范围内（除了最大的财富500强公司，对于所有其他公司，1-3个月应该足够保守）； 软件版本是重要的里程碑，不应轻率地对待。换句话说，不必要的延误/停工是极具破坏性的，应仅将其作为解决某些关键业务问题的最后手段；和 希望（或要求）作为利益相关者参与的外部（非dev / non-IT）实体有责任与开发团队合作，以达到发布时间表，尤其是在计划船交付前的最后一周左右日期（即用户测试/分期）。 以上是根据经验对我而言正确的断言，但看来我现在必须证明这一点-因此，如果存在这样的问题，我想在这里提出一些建议。 谁必须向管理层“出售”固定（或半柔性）发布周期的想法，才能指出一些论点/策略有效或有说服力，哪些无效？除了明显的时间表争用和沉没成本之外，即使在“公司”环境下，是否有任何硬数据/证据可用于证明运输实际上很重要？ 另外，我也乐于听取建设性的争论，即为什么时间表灵活性（即使在数周/数月的时间内）比按期交付更重要；我现在很难相信，但也许他们知道我不知道的东西。 请注意，我们已经分阶段发布了产品，除了生产之外，它经历了每个阶段。使用商业错误跟踪器跟踪问题，并且分配给此版本的每个问题（其中100％）均已解决。我意识到这很难让人相信，这才是真正的重点-出于无法解释的原因，管理层会延迟100％，功能完善，经过全面测试并且获得了利益相关者的批准，这是没有道理的，但这就是事实，这就是正在发生的事情，这是要解决的问题。

12 release  release-management  scheduling