为什么詹金斯胜过简单的 bash 脚本？ [关闭]答案

【问题标题】：Why jenkins over simple bash scripts? [closed]为什么詹金斯胜过简单的 bash 脚本？ [关闭]
【发布时间】：2019-09-27 03:03:19
【问题描述】：

如果你能让我理解这个简单的话题，我会非常高兴。

我知道 jenkins 是什么以及它的作用。现在让我们进行比较。

我们使用 jenkins，因此一旦代码被推送到存储库，通过 git 钩子，我们运行 jenkins 作业，该作业会拉取该代码，进行构建，运行测试，然后如果需要，将其上传到代码所在的远程机器实际运行。

现在，我可以做的是，当 git hook 发生时，我将运行 bash 脚本，而该 bash 脚本将执行这些操作（例如从存储库中提取代码、运行构建、进行测试，然后通过ssh）。

所以，我可以通过 bash 脚本来做同样的事情。

问题是：我看不出有那么大的优势。

那么，您能否尽力而为，用非常简单的语言解释为什么这有很大的优势？我知道 Jenkins 有很多插件，但这不是进行比较的最佳方式。

【问题讨论】：

不是一个好的回应。我将在远程机器上拥有部署脚本，它会在 git hook 执行后立即处理所有事情
您可能看不到在 bash 脚本上使用 Jenkins 的附加值。我认识一些人，他们开着 30 年的旧车，油表不再工作。这些汽车在技术上仍然可以让你从一个地方到另一个地方，所以这些人也可能看不到现代汽车的附加值。话虽如此，如果您询问超出车辆最低限度的任何内容，就像 bash 脚本一样，您的里程可能会像他们所说的那样有所不同（双关语无意）。类似地，bash 脚本方法在生产或企业环境中也不可行。

标签： bash git jenkins devops

【解决方案1】：

当项目按照标准方式构建时，Jenkins 可能效果最好（因为最普通的例子是在 Linux 上使用带有 git repo 的 Makefile/gcc 项目）。

对于这样的项目，Jenkins 可以通过几个步骤来自动检查、构建、测试和记录这些测试。 DIY 方法只会重新发明轮子。

另一方面，如果该项目有很多不寻常的工具，将 cygwin/POSIX 的东西与 Windows 工具混合，并依赖大量的遗留脚本将东西粘合在一起，则必须自定义 Jenkins 工作流。必须维护重要的 groovy 代码来调用 bash、perl 和 cmd 脚本的特殊组合，其中一些使用 Windows，一些使用 POSIX 命令行语法，从 ClearCase 输出中去除回车，移动工具工件等等。这也许也可以通过手动脚本来完成。尽管从用户的角度来看，Jenkins 仍然具有优势，因为它内置了 Web 界面。例如，它提供了对构建进行参数化的表单，并通过链接提供了计划、运行或已完成作业的图形概览。

在将工作负载分配到 Jenkins has built-in support 的几台机器上时，Jenkins 可能还有另一个优势。

【讨论】：

【解决方案2】：

这解释了为什么我们应该避免使用脚本并寻找工具。此外，Jenkins 和类似工具提供了处理此类部署问题的标准方法。

当新软件项目的开发开始时，编写持续集成 (CI) 流程的许多步骤的脚本通常是一种流行的选择。随着项目发展到需要更复杂的基础架构、单元和端到端测试以及强大、可重复的部署过程，简单的脚本不再是最佳解决方案。

为了大大降低生产力，更好的选择是用 Jenkins 构建服务器和管道配置替换这些脚本。

何时需要替换脚本

有一些明显的迹象表明，可能是时候用更强大的方法替换脚本化部署方法了。

当它无法扩展时：对于添加到应用程序的每个新片段，都必须更新脚本。无论您使用的是 bash、python 还是其他东西，这都会很快失控。为将新文件放在不同位置、更新权限和重新启动过程而添加的每一行代码都会增加复杂性并增加出错的风险。

当它变得不可维护时：越来越复杂，例如添加条件逻辑以根据系统状态更改部署，不可避免地导致一组脚本只有少数的开发人员可以解释。像这样一个通过有机增长来快速满足部署应用程序的即时需求的流程会产生很大的问题。

当它变得昂贵时：在这种情况下，费用以开发人员的时间和生产力的形式出现。准备和执行发布所涉及的手动流程所需的开销将开始对新功能开发产生重大负面影响。

来源：https://www.bandwidth.com/blog/replacing-scripted-software-deployments-jenkins-pipeline/

【讨论】：

有趣的是，你们都说对于添加到应用程序的每个片段，都必须更新脚本。除非您也更改它，否则 Jenkins 不会自动执行此操作。 Jenkins 也用于运行 bash 脚本。你写的答案根本不实用。仅提供示例为什么它会使使用 bash 脚本变得更加困难，我们可以对此进行争论。
在 Jenkins 中，您还必须手动添加这些更改。但是您不能将其视为处理常见部署问题的有组织的方式吗？从操作的角度考虑，每个项目维护许多 bash-script 并使用常见的 git 流程更改以及脚本格式的一些项目特定更改很容易，还是插件格式很容易？在队友改变的情况下，这种知识转换过程和减少依赖是多么容易从头开始阅读别人的脚本并理解并不是那么容易，但像 Jenkins 这样的基于插件的解决方案将使它变得容易。