企业可以使用开源软件在自己的云平台上开发应用，提高创新能力，无需创新支付更多的。

在大多数公司中，最重要的成本是人力资源。但是通过开源软件的智能使用，可以显着降低成本，即拥有GitHub的用户群可以为企业“免费”工作。但是 GitHub 有 6500 万注册用户帐户，必须假设其中大多数是开发人员。如果巧妙地围绕GitHub构建，这些开发人员实际上可以成为企业的人力资源，使企业的效率远远超过亚马逊、Facebook、微软等大公司，并显着降低成本。首先解释问题以了解解决方案。

问题

一位资深开发者说，在他以前工作的公司里就有这样一个案例。有人克隆了一个开源的git仓库，并将其代码添加到公司私有企业云的git仓库，然后修改这个仓库。两年后，该公司的开发人员花了 6 周时间更新使用 GitHub 上其他开发人员创建的最新版本，并尝试在此过程中保留尽可能多的自定义功能。行业专家不同意这种可能会降低代码质量的方法，因为他的公司对代码质量负责。

如果可以，最好使用他所谓的“Gitless？云？管道”。即在使用开源项目时，通常不会创建自己的git仓库，即直接链接到开源git仓库。结果是，如果主要的开源维护者发布了一个新的开源版本，那么只要你想更新自己的软件，就可以从开源库中提取并更改它，因为新的开源版本是由主要的开源维护者。这允许在企业内部使用开源软件，以便开发人员可以不断改进自己的软件，这对于企业来说当然是免费的。

后端

以这位开发人员为例，展示如何在日常工作中使用 Magic。最重要的一点是，他从来没有克隆过 Magic，而是创建了一个直接指向 Magic 的 GitHub 存储库的 Azure 管道，并注意到了“获取？源代码”部分的一些功能。

您需要注意源代码如何指向 GitHub，而不是 Azure 存储库。在上面的屏幕截图中，只需将其直接指向主分支即可。在实时生产环境中，您可能更愿意将其指向特定标签，除非您与项目维护者关系非常密切。仅仅因为即使它是“主”分支，它仍然可能包含临时提交。标签基本上是在项目新版本创建的时候创建的，通常可以更好的保证项目的稳定状态，后面是一些随机的主提交。

由于这个开发者是 Magic 的主要维护者，他对它很熟悉，因为他知道当前的“master”分支在任何给定的时间点有多好。此外，他关闭了管道上的 CI 触发器，并为提交到主分支的每个更改构建了项目。最后一部分至关重要，因为您不希望任何随机提交触发新构建，尤其是对于生产环境。这使得流程的自动化程度降低，因为必须手动触发管道而不是使用 CI 触发器，但它也允许 100% 控制从开源存储库创建新构建的时间。

之后，这个管道将克隆 Babel 和 Babelfish。这些技术允许使用特定最终结果中所需的任何 Magic 微服务填充模块文件夹。

这允许模块作为管道的集成部分动态安装到 Magic 后端。

对于这个特定的管道，如果你想为 Magic 启用 Windows 自动身份验证，你只需要在构建后端之前将 NuGet 包添加到核心。

这允许使用需要特定管道的 C# 绑定的任何插槽动态填充 Magic 后端。由于 Magic 的模块化，这实际上会改变 Magic 的行为，而无需更改任何代码。

部署后端后，您将不得不应用变量替换。这可以通过在主要部署操作上启用 JSON 变量替换来轻松完成，然后引用要替换变量的管道的变量部分。

需要注意的是，出于安全考虑，它们的值无法显示，但在部署后端时会动态交换相关的“appsettings.json”值。

前端

前端使用类似的机制构建。 Angular 项目中有一个 npmrun-script 部分，可用于创建生产构建。

诚然，前端有点乱，因为Angular在构建过程中将所有东西打包成随机生成的文件，所以这里很难智能地引用变量，除非在其代码中对此进行调整。所以为了简单起见，在构建流水线阶段在这里应用了变量替换。这降低了灵活性，因为必须为每个环境构建变量，当然，假设需要在每个环境中覆盖这些变量。但这对于这个特定项目来说并不是什么大问题。

也可以使用替代机制，但这包括使用看起来很奇怪的#parts 传播 Angular 代码，这样它就不能在没有首先更改主要内容的情况下在开箱即用的调试/开发环境中使用堆无用的配置值。因此，Magic 额外的“每个环境一个构建管道”要求的成本并不高，因为它可以让一切尽可能多才多艺，零开发依赖或配置要求，使其在开发环境中工作。