问题标签 [automated-deploy]

所以，以前我在签署代码时遇到问题，但我想通了。在我的下一次构建尝试中，我收到了：

我不确定下一步该做什么，而且我真的无法在网上找到任何资源。

为了匿名，我删除了部分输出，但这是其中的大部分：

我正在做一个关于持续集成的概念验证，以及我们的开发团队是否会从自动化构建和自动化部署中受益，以减少人为错误。我已经在这个过程中走了很远，但是对于如何配置我们的增量构建以避免重建没有代码更改的依赖项有一些问题。此外，我希望我们的部署工具能够仅识别和部署由于代码更改而重建的程序集。

我们已经使用 TFS 等 Microsoft 产品进行源代码控制，使用 Visual Studio 进行开发，使用 Team Foundation Build 进行持续集成构建。我们目前倾向于使用 InRelease 进行部署，因为它似乎与 Team Foundation Build 很好地集成。

但首先，这是我们当前的设置......

1. 有 200 多个 C# 解决方案文件，每个文件包含一个或多个项目。在环境中将这些项目组合成较少的解决方案（即通过设计）是不切实际的。解决方案中的项目使用项目引用来解决对其他解决方案中项目的依赖关系和文件引用。据我所知，这是微软在处理大量项目时推荐的方法。

2. 我们使用“按功能分支”策略，例如在并发功能分支上进行隔离开发，完成后合并到一个稳定的主分支。当需要发布时，发布会从主发布分支并隔离用于修补程序和部署。功能分支和主分支具有由代码签入触发的 CI 构建。发布主要是从 InRelease 对选定的发布分支手动执行。一个版本将通过各种环境部署，包括集成/测试、UAT，并最终部署到我们所有的客户。我们仍在充实分支策略的细节，但这是另一个问题。

目前要解决的问题：

1.避免重建没有代码更改的依赖项...

当我们向客户端部署新功能或补丁时，我们希望将文件中的绝对最小化。我们公司拥有庞大的客户群（数千名客户），有时互联网连接速度很慢，因此无法为每个客户全面部署所有组件（200 多个）。我通过设置增量构建部分解决了这个问题，该构建只正确重建了预期的更改项目，但也重建了所有依赖项目，即使没有对它们进行任何代码更改。这导致更改的程序集和依赖项都具有新的时间戳。如果我们使用时间戳的更改来识别要部署哪些程序集，那么这将导致部署功能未更改的程序集。

例如：

解决方案 B，有一个名为 Project B 的项目 解决方案 A，有一个名为 Project A 的项目

项目 B -> 项目 A（其中项目 A 对项目 B 有文件依赖关系）

当在项目 A 中进行非破坏性更改时，例如对方法的内部进行更改，那么预期的结果是：只构建了 A，因此是部署的候选者。当在项目 A 中进行重大更改时，这将破坏项目 B，预期结果是：A 和 B 都已构建，因此是部署的候选者。目前 MSBuild 无论如何都会重建所有依赖项，这不是我们想要的。

2.自动识别应该部署哪些程序集...

我对这个问题有部分解决方案。执行构建时，我的构建过程模板被配置为运行 MSBuild 脚本，其中包含以特定顺序构建的解决方案列表。此操作在构建代理的工作区中执行。每次执行新构建时，构建过程模板都会创建一个唯一的放置文件夹，格式为并将二进制文件从构建代理工作区复制到放置文件夹。这是标准构建过程模板处理的开箱即用功能。构建已配置为不清除构建代理工作区，因此它第一次运行时将构建解决方案中的所有项目，但后续构建将仅构建具有代码更改或依赖于其他项目的项目（增量构建？）。因此，未更改的程序集将具有原始时间戳，而更改的程序集将具有新的时间戳。我们有一个工具可以在放置文件夹之间进行文件夹比较并将结果输出到 txt 文件。这使我们能够识别自上次部署以来添加/更改/删除了哪些二进制文件。它还为我们提供了额外的好处，即将实际人工制品列表与开发人员定义的预期人工制品清单进行比较。这将确保不会部署尚未指定和证明经过单元测试的程序集。

问题是我们如何利用 InRelease 仅根据上面的示例部署所需的文件，而不是放置文件夹中的所有文件？

我正在使用 TeamCity 和 Octopus Deploy 的自动部署。每个构建都由对 SVN 存储库的提交触发。

我想使用提交消息，例如“对布局页面进行一些小的更改”，以用作我创建的 Octopus Deploy 版本的发行说明。有谁知道我可以在 TeamCity 中使用哪个变量来填充它？

我已经使用了几个参数（vcsroot.name.url、vcsroot.url 建议在另一个问题上）以及 vcsroot.labelingMessage 但这只是保留在默认消息中。

这可能吗？最好向业务测试用户发送一封电子邮件，告知他们发生了什么变化。然后我可以让开发人员更详细地描述他们所做的事情。

我正在使用 TeamCity 进行自动化测试，现在我想使用 Octopus 插件自动化我的部署。到目前为止，我可以使用我的 TeamCity 包手动从 octopus 服务器创建版本，但我想通过我的构建自动化它，并使跟踪我的项目版本变得更加容易。我已按照文档和视频中的说明进行操作：http: //docs.octopusdeploy.com/display/OD/TeamCity

我收到以下错误

八达通服务器错误（HTTP 401）：您必须登录才能执行此操作。请提供有效的 API 密钥或重新登录。

我正在从我的个人资料中创建一个 API 密钥，不管管理员是否生成密钥我没有访问权限。我的 Octopus 版本是 2.5.7.384 和 TeamCity Enterprise 版本 8.1.2

这是构建日志：

在开发时，我的团队显然使用development了我们的环境。

当我们运行自动化测试时，我们使用testing.

我们也有staging和production环境，分别用于我们的测试人员检查功能和最终的“现场”产品。

我们正在尝试设置一个内部 CI 服务器来运行我们的自动化测试并最终协助自动化部署。

由于 CI 服务器实际上是在运行自动化测试，因此有些人认为它应该在testing环境中运行。然而，为了让 CI 服务器真正有用，我的想法是它需要以production尽可能接近实际镜像的模式运行production环境镜像的模式运行（显然，不接触生产数据库）。

是否存在应在其下执行 CI 服务器的公认环境？production环境（具有不同的数据库）对我来说似乎是唯一合乎逻辑的答案，但我可能会遗漏一些东西......

出于某种原因，我的一个项目在我构建时没有构建。我在查看的每一页上不断收到的建议告诉我，我应该为我的解决方案“启用 Nuget 包还原”。我已经这样做了，但它似乎不起作用。

这是该构建的输出：

我的问题的简化示例...

我的公司有 4 个独立的应用程序：App A、B、C 和 D。我的公司有 2 个独立的生产服务器。

• 应用 A 的生产服务器 = 服务器 1
• 应用 B 的生产服务器 = 服务器 1
• 应用 C 的生产服务器 = 服务器 2
• App D 的生产服务器 = 服务器 2

Octopus Deploy 网站上的示例似乎假设您的生产“环境”对于您的所有“项目”都是相同的。

我的生产“环境”取决于将哪个应用程序部署到生产环境。

我可以创建一个以每台服务器命名的“环境”，但这最终会产生一些奇怪的 (web/app).config 名称进行转换（我更喜欢 App.Release.Config 而不是 App.Server1.Config） .

如果您有多个生产服务器，如何设置 Octopus Deploy？这是机器角色可以解决的问题吗？

谢谢，

亚当

我目前正在使用 JetBrains PhpStorm 开发一个 PHP 应用程序。此应用程序包含几个 .htaccess 文件。

由于目前此应用程序没有自动部署过程，我正在使用 PhpStorm 中的“上传到...”功能。使用此功能，应用程序被部署到多个服务器。

我的应用程序中的 .htaccess 文件需要在不同的服务器上具有不同的内容（暂存系统与生产等）。不幸的是，到目前为止，我还没有找到一种可靠地管理它的方法，并且反复用不适合我部署到的服务器的版本覆盖了 .htaccess 文件。

有没有办法让 PhpStorm 在部署之前转换我的 .htaccess 文件？或者我可以为不同的服务器定义同一个文件的不同版本吗？

我一直在尝试让虚拟机在 centos 上使用 cfg 文件，但不幸的是，我收到 ks.cfg 文件不存在的错误。

下面是我为启用虚拟机而运行的命令。

我是 VM 设置的新手，不确定我是否做得对。

任何有关如何解决此问题的建议将不胜感激。

另外，initrd-inject 有什么作用？是否可以将上述命令保存到文件中并运行该文件？

我正在研究将产品的特定版本自动部署到特定 Azure 云服务或 VM 的方法。

以下步骤将是自动化的，尽可能少的人工干预：

• 创建云服务或 VM
• 安装产品的特定版本（作为独立的 exe 或 Windows 服务，而不是 IIS）
• 调整配置文件
• 设置用户帐户
• 运行exe/服务

该代码当前位于 Visual Studio Online / TFS 中。我们已经设置了 Cruise Control .NET CI，我们正在考虑迁移到 TeamCity。这将用于通常的 QA 和生产类型环境，但也用于临时部署，例如，如果产品中添加了试用功能，并且我们希望将其部署到新 VM 以供特定客户使用。理想情况下，我们将能够使用命令行或 UI 来选择构建、创建 VM 并指定任何配置更改。

一种可能的解决方案可能是Octopus Deploy，尽管我认为这不能真正创建 Azure VM。我可能还会查看 Azure API，以及 TFS 部署。

基本上这是可行的，为了缩小我的研究范围，我是否缺少任何经过验证的替代方案？

提前致谢！