如何在云中利用开源软件进行开发以提高创新能力

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

[[412034]]

问题

一名资深的开发人员表示，在他曾经就职的一家公司有一个这样的案例，有人克隆了一个开源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万开发人员以及他们所有的创新，那么在项目的开发人员和企业之间建立一种共生关系，可能是一种采用更多创新并且成本极其低廉的方法。