Questions tagged «deployment»

部署是使软件系统可用的所有活动。与部署软件有关的问题在此标签下。

7
专用构建机器的目的是什么？
由于多种原因导致上一个构建周期的部署不佳，我竞选办公室使用专用的构建机器执行所有将来的部署，而我的老板接受了这个建议。 但是，我们不必在办公室使用一台实际的机器，而必须与其他几个小组共享一台机器-麻烦的是必须带着所有必要的信息离开我的办公室然后走上楼梯到另一个办公室来执行简单的构建，这让我想知道为什么我一开始就提出这个建议。 最初，拥有一台单独的构建机器的想法是，将我自己的本地编写的代码与其他几名开发人员的代码分开，并从部署中分离出我在机器上拥有的所有劫持文件。这也是为了解决我对ClearCase文件管理系统日益增长的担忧，该系统通常拒绝让我部署某些构建活动，除非我还包括了另一个具有“依赖关系”的活动。 现在，我实际上正在执行此过程，我想知道我是否误解了使用构建机器的全部目的-并且由于我们仅使用该机器将代码部署到我们的测试，登台和生产环境，以及不是针对我们的个人开发人员测试部署，我不确定它是否有任何用途。 那么，使用构建机器的真正原因是什么，我什至接近正确使用它？
4
与其他更接近Unix二进制语言的语言相比，使用Java时使用Docker的开发优势是否被否定？
我有一个朋友说： Docker很棒。您可以使用它在本地计算机上复制生产及其所有怪癖。然后，您可以超快速地通过所有登台工作流直接部署该实例。 现在，如果开发人员正在编写Ruby，PHP或Go（存在指向操作系统的定向二进制链接），这将是正确的。 但是当使用Java时 - 操作系统和语言之间已经存在一个虚拟层，无论底层操作系统如何，都可以确保操作的一致性。 可以说，在这种情况下，否定了为本地开发人员运行Docker来复制生产环境的好处。（与Ruby，PHP或Go相比）。 我愿意就此进行讨论，并热切希望听到持异议的观点（有证据）。 与其他更接近Unix二进制语言的语言相比，使用Java时使用Docker的开发优势是否被否定？
53 java  deployment  jvm  docker 
7
有期限的待办事项？
背景 我正在一个团队中实施零停机时间部署。为了实现此目标，我们正计划使用蓝/绿部署策略。我在进行研究时意识到的一件事是进行数据库更改变得多么复杂。重命名列之类的简单操作可能需要3个完整的发布周期，直到完成！ 在我看来，全面实施变更需要多个发布周期，这会带来很多潜在的人为错误。在链接的文章中，它表明2个发行版需要更改代码，而3个发行版需要数据库迁移。 我在寻找什么 当前，如果我们想记住要做的事情，可以在我们的问题管理系统中创建票证，这会造成混乱，并且还可能被管理层转移到以后的冲刺或待办事项中；或者我们可以创建一个TODO注释，它可能会完全被遗忘。 我正在寻找的方式是TODO注释可以有一个截止日期，并且，如果该截止日期已过期，我们的持续集成系统（当前将使用的未定）将拒绝该构建。 例如，如果我们重命名列，则可以为其创建初始迁移，然后创建两个TODO注释以确保创建其余的两个迁移： // TODO by v55: Create migration to move constraints to new column, remove references to old column in app // TODO by v56: Create migration to drop old column 这似乎很容易实现，但是我想知道是否已经存在类似的东西，因为我不想重新发明轮子。 其他想法 考虑到滚动部署和蓝/绿部署被认为是最佳实践，我觉得自己可能在这里遇到了XY问题，但我找不到能够减轻数据库更新麻烦的解决方案，这似乎很奇怪。如果您认为我正在完全研究错误的内容，请在评论中告诉我！就是说，我给出的数据库示例只是一个示例，我认为带有到期日期的TODO注释在其他情况下也将很有用，因此即使我正在接近这种特定情况，我还是很想回答我的问题也是实际问题。谢谢！ 编辑：我只是想这可能会有所帮助的另一种情况。如果在准备就绪时使用Feature Toggles来打开应用程序的某些部分，则必须小心清理它们，否则最终可能会出现Toggle Debt。带有截止日期的评论可能是记住这一点的好方法。
4
实现零停机时间部署
我正在尝试实现零停机时间部署，因此在理论上，我可以在下班时间减少部署，而在“更慢”的时间内部署更多。 我当前的设置，有些简化： Web服务器A（.NET App） Web服务器B（.NET App） 数据库服务器（SQL Server） 我当前的部署过程： “停止” Web服务器A和B上的站点 升级数据库架构以获取正在部署的应用程序的版本 更新Web服务器A 更新Web服务器B 将所有内容恢复在线 当前问题 每月导致少量的停机时间-大约30分钟。我在下班时间这样做，所以这不是一个大问题-但这是我想摆脱的事情。 另外-没有办法真正退缩。我通常不制作回滚DB脚本-仅升级脚本。 利用负载均衡器 我希望能够一次升级一台Web服务器。从负载均衡器中取出Web服务器A，对其进行升级，使其重新联机，然后对Web服务器B重复上述步骤。 问题是数据库。我的软件的每个版本都需要针对不同版本的数据库执行-所以我有点“卡住了”。 可能的解决方案 我正在考虑的当前解决方案采用以下规则： 切勿删除数据库表。 永远不要删除数据库列。 切勿重命名数据库列。 切勿重新排列列。 每个存储过程都必须进行版本控制。 含义-编辑后，“ spFindAllThings”将变为“ spFindAllThings_2”。 然后在再次编辑时变成“ spFindAllThings_3”。 相同的规则适用于视图。 虽然，这似乎有点极端-我认为它可以解决问题。该应用程序的每个版本都将以不间断的方式访问数据库。该代码期望视图/存储过程产生某些结果-并使该“合同”有效。问题是-它只是马虎了。我知道我可以在应用程序部署一段时间后清理旧的存储过程，但是感觉很脏。另外-这取决于所有遵循这些规则的开发人员，这大部分都会发生，但是我想有人会犯错。 最后-我的问题 这是草率的还是朴拙的？ 还有其他人这样做吗？ 其他人如何解决这个问题？
15
如何在不感到极端焦虑的情况下自动化生产部署？
在我们的工厂中，我们使用SVN进行源代码控制，使用Cruise Cruise进行CI处理处理针对我们的开发，测试和集成环境的自动构建和部署。 所有这些都可以顺利进行，但是由于硬件和资源的限制，我们的集成环境不是像生产环境那样的2服务器负载平衡环境。尽管其他所有条件都相同，但这将是我们的集成和生产环境之间的唯一区别（尽管很大！） 从理论上讲，区别是我们的应用程序服务器的配置稍有不同，并且部署脚本仅需将构建工件放到两台服务器中，而不是仅仅放到两台服务器中，但是为什么我如此紧张地自动化我们的生产部署？ 我通常不是控制狂，但是我总是感到需要手动将生产部署到生产中。我从同事那里听说，这通常是Really BAD Thing™，但他们没有提出反对的理由。 我知道，当我手动执行操作时，可以看到我正在物理上复制正确的文件，正在物理上关闭应用程序服务器并确保它们成功关闭，我正在物理上启动服务器，然后进行物理检查以创建日志确保启动正常并且部署成功。它使我安心。 对于自动脚本化生产部署，反对此OR参数的参数是什么？
10
您如何通过代码更改来更新实时网站？
我知道这是一个非常基本的问题。如果有人能使我幽默并告诉我他们将如何处理，我将不胜感激。 我决定发布此内容，因为我将要安装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 …
2
NET中如何构造多个重叠的解决方案/项目？
我最近开始为具有旧的旧版代码库的新客户工作，在旧版代码库中有多个.net解决方案，每个解决方案通常托管一些对该解决方案唯一的项目，然后“借用” /“链接”（添加现有项目）其他一些项目从技术上讲，它属于其他解决方案（至少如果您按TFS中的文件夹结构进行操作） 我从未见过如此交错的设置，没有明确的构建顺序，有时解决方案A中的项目只是直接从解决方案B中托管的项目的输出目录中引用dll，有时即使已驻留该项目，也直接将其包括在内FAR在文件夹结构中消失。 似乎所有内容都已针对开发人员的延迟进行了优化。 当我面对他们为什么没有CI服务器时，他们回答说，很难像这样组织代码。（我现在正在设置它并咒骂此代码组织） 这些解决方案是围绕部署工件（需要一起部署的东西在同一个解决方案中）组织的，我认为这是一个明智的决定，但是这些解决方案（项目）的内容无处不在。 在多个解决方案/部署工件之间重用公共类库时，是否存在最佳实践的共识， 如何在VCS中构造代码 如何促进在单独的部署工件之间共享业务逻辑
2
数据库迁移和Azure部署插槽
我打算将新的Web应用程序推送到Azure Web App Service（以前的Azure网站）。我想利用部署插槽来测试我的部署，然后再将其投入生产。只要不需要更改数据库架构就可以了。但是，如果发生模式更改，则不能在同一数据库版本上运行两个软件版本。由于我使用的是EF迁移，因此将其推入暂存插槽将立即导致数据库更新到最新版本。 所以我的问题是，当需要进行数据库迁移时，是否会使用部署槽？ 对于大型SaaS提供商，该如何做。他们是否正在使用新版本立即执行数据库迁移？这肯定会导致一些停机时间。 我只能想到解决这个问题的相当复杂的方法，有没有简单的方法？
5
我应该发布源代码来修复错误吗
我正在构建的应用程序中存在一个错误。我问了一个关于SO的问题，其中一个用户要求我发布或将所有代码发送给他，以便他可以查看。 我完全理解要求。这是有效且可以理解的。但是，我对是否应该存有疑问。显然，我给了他/她王国的钥匙，如果他/她会做出恶意的事情，我将没有任何追索权。 我还想补充一点，我的意思是不尊重提供帮助的用户。我只是在表达担忧。 我确实想修复我的错误，但不能保证此人可以修复它。 我应该发布完整的源代码并希望获得最好的结果吗？还是保留它并尝试自己解决？ 你会怎么做？
4
用于内部业务应用程序的Windows Installer有意义吗？
我正在尝试对这种情况下的普遍性建立一个普遍的了解，以便我可以决定进一步进行下去是否有意义。 在具有以下特征的典型公司环境中是否欢迎安装程序？ 变更控制程序 开发/质量保证/生产环境 在各个领域（防火墙，数据库，窗口等）的指定部署团队。 是否可以将“石蕊试纸”应用于应用程序，以查看它是否是创建安装程序的理想选择？* 安装程序是否足够简单，每个应用程序都应该有一个？ 安装人员甚至是正确的工具吗？ 期望开发人员学习诸如WiX之类的东西来支持安装程序是否合理？ 一般而言，可维护性是一个问题，例如，创建安装程序是否是利基技能？ * 例如，我在生产服务器上的共享目录中有一组winform应用程序。特定的组可以从此目录运行应用程序，但是只有系统管理员才能修改可执行文件。当前的部署过程包括让管理员将可执行文件和库复制/粘贴到共享目录。 由于应用程序未安装在个人用户的计算机上，因此创建一个安装程序以将这些应用程序的新版本部署到共享目录是否有意义？ 编辑 - 我觉得这里的答案提供了扎实的建议，所以我想分享我为当前项目提出的想法，在这个项目中我需要构建大量应用程序并将它们部署到单个文件夹中。 我找到了一个名为_PublishedApplications的NuGet程序包，该程序包模仿了Web项目的_PublishedWebsites的行为。想法是将NuGet软件包安装到项目中，并添加一个目标，该目标会将构建工件复制到输出路径中的_PublishedApplications目录中。通过从命令行运行MSBuild并指定outdir属性来激活此行为： msbuild /p:Configuration=Release /p:outdir=C:\path\to\outdir MySolution.sln 这将为您提供类似于以下内容的目录结构： C：\ path \ to \ outdir _PublishedApplications \ 专案1 \ dlls, exes, etc. 专案2 \ ... 从那里创建一个可以在各种环境中提取的zip相当简单。
2
零停机时间部署-过渡Db模式
实现零停机时间部署也涉及到同一问题，但我需要一些有关正在考虑的策略的建议。 语境 一个基于Web的应用程序，其中Apache / PHP用于服务器端处理，而MySQL DB /文件系统用于持久性。 我们目前正在建设基础设施。所有网络硬件都将具有冗余，并且所有主网络电缆都将在绑定对中使用以实现容错。服务器被配置为具有硬件容错能力的高可用性对，并且将为虚拟机容错能力和总体性能进行负载平衡。 我的目的是我们能够在不停机的情况下将更新应用到应用程序。在设计基础架构以确保可以提供100％的正常运行时间时，我付出了极大的努力。每次应用更新会有10-15分钟的停机时间，这将是非常令人失望的。这一点特别重要，因为我们打算有一个非常快速的发布周期（有时每天可能达到一个或多个发布）。 网络拓扑结构 这是网络的摘要： Load Balancer |----------------------------| / / \ \ / / \ \ | Web Server | DB Server | Web Server | DB Server | |-------------------------|-------------------------| | Host-1 | Host-2 | Host-1 | Host-2 | |-------------------------|-------------------------| Node A \ / …
3
我们如何跟踪每种环境中的代码版本？
我的团队目前使用相当简单的分支/部署过程，如下所示： ┌────────┐ ┌────┐ ┌──────┐ Environments: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ Builds: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ Branches: │ …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.