共计 2664 个字符，预计需要花费 7 分钟才能阅读完成。
| 导读 | 企业可以在自己的云平台上利用开源软件开发应用程序以提高创新能力，而无需为创新支付更多的费用。 |
企业可以在自己的云平台上利用开源软件开发应用程序以提高创新能力，而无需为创新支付更多的费用。
在大多数企业中，最主要的成本是人力资源。但是通过智能地利用开源软件，可以显著降低成本，即拥有 GitHub 的用户群能够为企业“免费”工作。但 GitHub 有 6500 万个注册用户帐户，必须假设其中大多数成员是开发人员。如果围绕 GitHub 巧妙地构建，实际上可以让这些开发人员都成为企业的人力资源，从而使企业的工作效率远远超过亚马逊、Facebook 和微软等大型公司，并显著降低成本。首先说明这个问题，以便了解这个解决方案。
一名资深的开发人员表示，在他曾经就职的一家公司有一个这样的案例，有人克隆了一个开源 git 存储库，然后将其代码添加到该公司私有企业云的 git 存储库中，然后对这个存储库进行修改。而在两年之后，该公司的开发人员花费 6 周的时间进行更新，以使用其他开发人员在 GitHub 上创建的最新版本，并尝试在这一过程中尽可能多地保留自定义功能。行业专家并不认同这个可能降低代码质量的做法，因为他所在的公司要负责代码质量。
如果可以的话，使用他所说的“Gitless Cloud Pipelines”要好得多。也就是在使用开源项目时，通常不会创建自己的 git 存储库，这意味着直接链接到开源 git 存储库。其结果是如果主要开源维护者发布了新的开源版本，这样一来只要想更新自己的软件，就可以从开源存储库中提取并更改，因为新的开源版本是由主要开源维护者发布的。这允许从企业内部利用开源软件，这样开发人员就可以不断地改进他们自己的软件，当然，这对于企业是免费的。
以这名开发人员展示在其日常工作中如何使用 Magic 为例。其中最关键的一点是，他从未克隆 Magic，而是创建了一个直接指向 Magic 的 GitHub 存储库的 Azure 管道，并注意到了“Get sources”部分的一些特性。
需要注意源代码如何指向 GitHub，而不是 Azure 存储库。在上面的截图中，只是将它直接指向主分支。在实时生产环境中，可能更愿意将其指向特定标签，除非与项目维护者有非常密切的关系。只是因为即使它是“主”分支，它仍然可能包含临时提交。其标签基本上是在创建项目的新版本时创建的，这通常可以更好地保证项目的稳定状态，然后是一些随机的主提交。
由于这名开发人员是 Magic 的主要维护者，因此对此很熟悉，因为非常清楚当前的“主”分支在任何特定时间点有多好。此外，他还关闭了管道上的 CI 触发器，为提交到主分支的每个更改构建项目。最后一部分至关重要，因为不希望任何随机提交触发新构建，尤其是对于生产环境来说。这使得这一过程的自动化程度较低，因为必须人工触发管道而不是使用 CI 触发器，但这也能够 100% 地控制从开放源代码存储库创建新构建的时间。
之后，这个管道将克隆 Babel 和 Babelfish。这些技巧允许在特定的最终结果中使用想要的任何 Magic 微服务填充模块文件夹。
这允许将模块动态安装到 Magic 后端，作为管道的一个集成部分。
对于这个特定的管道，想为 Magic 启用 Windows 自动身份验证，只需在构建后端之前将 NuGet 包添加到核心即可轻松完成。
这允许使用任何插槽动态填充 Magic 后端，这些插槽是需要该特定管道的 C# 绑定。由于 Magic 的模块化，这实际上会改变 Magic 的行为，而不需要任何代码更改。
在部署后端后，将不得不应用变量替换，只需在主要部署操作上启用 JSON 变量替换即可轻松完成此操作，然后在管道的变量部分中引用想要替换的变量。
需要注意的是，出于安全原因，无法展示它们的值，但它们会在部署后端时动态交换相关的“appsettings.json”值。
前端使用类似的机制构建，在 Angular 项目中有一个 npmrun-script 部分，可以参考它来创建生产构建。
诚然，前端有点混乱，因为 Angular 在构建过程中将所有内容打包到随机生成的文件中，因此很难在这里智能地引用变量，除非在其代码中对此进行了调整。因此为了简单起见，在构建管道阶段在这里应用变量替换。这会降低灵活性，因为必须为每个环境构建变量，当然，假设需要在每个环境中覆盖这些变量的话。但这对于这个特定项目来说并不是什么大问题。
也可以使用替代机制，但这包括用看起来很奇怪的 #{xxx} 部分散布 Angular 代码，使其无法在开箱即用的调试 / 开发环境中使用，而无需先更改一大堆无用配置值。因此，对于 Magic 的额外“每个环境一个构建管道”要求的代价并不高，因为它能够保持一切尽可能通用，零开发依赖性或配置要求使其在开发环境中工作。
基本上，这只替换了一个变量，即后端的 URL，当然可以与使用后端变量类似的方式创建这一变量，除了这发生在构建步骤中，而不是在部署步骤中。
也可以部署任何认为合适的方式。在日常工作的 DEV 环境中，只是在虚拟机上使用 IIS 服务器，因为这允许在一台机器上部署 30/50 个 Web 应用程序，从而显著降低了成本。当然，可能需要考虑采用其他应用程序，例如 Azure WebApps 等。
通过创建这样的“Gitless 云系统”，直接指向开源 GitHub 存储库，可以不断利用添加到这些项目中的任何创新，而不必采用人工进行合并更改。
然而，并非所有项目都可以使用这种方法，例如因为它们需要修改代码才能在环境中工作，不允许通过配置设置重写其行为等。或者它们需要附加功能，并且不提供插件架构，允许像 Magic 那样动态注入动态功能。因此，该项目在其核心架构中必须是“超级敏捷”的，允许可能需要的任何方式拦截并添加到其核心。很少有 GitHub 项目在本质上像 Magic 一样“敏捷”，所以这可能是一个挑战。
如果放弃了对核心项目的所有控制权，这对于像 Magic 这样的项目来说可能意义不大，因为它的灵活性和插件架构。但是，不能再像控制在自己的 git 存储库中拥有源代码的项目那样“控制”项目。然而，大多数 GitHub 项目的开发人员和维护人员都非常愿意接受提供给他们的变更请求。
或者，可以激励项目背后的开发人员，以加快项目开发，并让维护人员优先考虑问题。如果企业可以免费利用 6500 万开发人员以及他们所有的创新，那么在项目的开发人员和企业之间建立一种共生关系，可能是一种采用更多创新并且成本极其低廉的方法。
