在两年前的用户会议上，我们自己的Noel Seaton介绍了electronic commander的最佳实践，这是我们CloudBees Flow解决方案的基础自动化平台。这次演示受到了广泛的欢迎，我们已经把它列入了我们的培训材料中。因此，大约一年半之后，我想与我们的CloudBees Flow客户联系，分享我最近使用您最喜欢的自动化平台的一些经验，以及您可能希望将其纳入日常运营的一些最佳实践。如果您尚未升级到我们最新的长期支持版本（LTS）5.0.3或在我们的一个特性版本（5.1、5.2或5.3）中，我强烈建议您开始学习升级所需的工作。主要的变化是jobId现在是一个universaluniqueidentifier（UUID），它由一个32个字符的字符串表示，以前它是一个整数。有关升级的详细信息可以在安装指南中找到。建议您更改作业和工作流名称模板，以便为每个项目使用自动递增的全局计数器。我们甚至提供了一个脚本来帮助你。但是，如果在作业名称和工作流名称模板之外的其他位置使用作业ID（或工作流ID），例如比较对象、检索工件……则必须手动修改代码，因为32位uuid的顺序不可比较。很多这方面的工作都可以在当前的4.x测试服务器上完成，所以越早开始，转换效果越好be.BackupI公司仍有许多客户没有认真的备份计划。所以，如果这仍然是你的情况，请回到我关于这个主题的原始文章。EC-Admin有一些新的程序可以帮助您，它可以在我们的github站点上找到。相信我，总有一天你会感谢我的多级备份策略。另外，快照也是虚拟环境的一个重要特性。如果你在使用虚拟环境，在任何重大改变（比如升级）之前，我鼓励你使用它们。插件和项目你们中的一些人正在使用插件来帮助跟踪在开发和测试"Dev"服务器后安装在生产环境中的项目版本。我希望您在插件和自动化过程的开发中使用敏捷和CI原则，并且不要在未经测试的情况下向您的"Prod"服务器推送任何新内容。我们发布了自己的测试框架来帮助你。安装插件并只修改次要版本或内部版本号（第三个或第四个）的一个副作用是新版本会覆盖以前的版本。和任何普通项目一样，当它被删除时，附加的作业也会被删除。如果你想保存它们，你有几个选项：仅修改插件的第一位或第二位，因此它保留旧版本，因此保留相关联的乔布斯。写电子商务中的一些代码_安装程序.pl在晋升时保留那些工作。"moveJobs（）"API可能很方便那个。用电子商务管理中的新选项自动。分开代码和数据当CloudBees流自动化平台（ElectricCommander）的用户将一个项目从一个开发转移到另一个产品时，我看到的最大的痛苦之一就是数据的管理。通常，在创建过程时，会将一组属性附加到同一个项目。那么当这些属性在Dev和Prod环境中不同时会发生什么呢？让我们考虑一些示例：服务端口：您可以通过将匹配属性附加到资源或资源池来解决此问题。一个buildId：如果这个属性被附加到项目本身，并且您将一个新版本更新到生产环境中，您将丢失当前值并用Dev-one替换它。这样做会丢失数据，并冒着某些作业名被复制的风险，从而导致运行失败。考虑将buildId/jobCounters附加到/server/。一般属性呢，比如产品列表、发送电子邮件的地址等等…。？它们在Dev和Prod中通常有不同的值，当您将插件或项目的新版本推送到Prod时，您不想修改所有这些值。您可以编写一个过程来执行此操作，但总有一个风险，您可能会错过一些或忘记运行整个过程。我的建议是把代码和数据分开。代码包括您的过程、包含代码的属性、通知程序（请确保使用"to"字段的属性来区分Dev和Prod）…数据包括属性和可能的计划，因为它们可能在每个服务器上采用不同的参数和频率。我希望这些建议对您有意义。如果你有其他你想分享的，请在下面留言告诉我。