为什么jenkins不喜欢简单的bash脚本？

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

我知道詹金斯是什么，它做什么。现在让我们进行比较

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

现在，我可以做的是，当git钩子发生时，我将运行bash脚本，bash脚本将完成这些事情（比如从存储库中提取代码、运行构建、进行测试，然后通过ssh将其上传到远程机器）

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

问题是：我看不出有多大的优势

---

那么，你能尽你所能，用非常简单的术语解释一下为什么这有很大的优势吗？我知道Jenkins有很多插件，但这不是进行比较的最佳方式。

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

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

为了节省对生产率的巨大影响，更好的选择是用Jenkins构建服务器和管道配置替换这些脚本

何时更换脚本

有一些明显的迹象表明，也许是时候用更健壮的方法来取代脚本化的部署方法了

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

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

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

---

来源：

Jenkins可能在项目按照标准行进行结构时工作得最好（最普通的例子是Linux上带有git repo的Makefile/gcc项目）

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

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

---

Jenkins在将工作负载分配到多台机器时可能还有另一个优势。

有趣的是，大家都说，对于添加到应用程序中的每一部分，脚本都必须更新。詹金斯不会自动做，除非你也改变它。Jenkins还用于运行bash脚本。你写的答案根本不实用。提供一些例子，说明为什么使用bash脚本会变得更加困难，我们可以对此进行讨论。在Jenkins中，您还必须手动添加这些更改。但是，您不能将此视为处理常见部署问题的有组织的方法吗？。从操作的角度考虑，使用常见的git流更改和一些特定于项目的脚本格式更改来维护每个项目的许多bash脚本是容易的还是插件格式的容易？在队友改变的情况下，知识转换过程和依赖关系的减少是多么容易，从头开始阅读别人的脚本并理解它并不是那么容易，但是Jenkins喜欢基于插件的解决方案会让它变得容易。这不是一个好的回应。我将在远程机器上安装部署脚本，一旦git hook被执行，它就会处理好所有事情。您可能看不到在bash脚本上使用Jenkins有多大的附加值。我认识一些人，他们开着30年前的旧车，车上的燃油表已经不工作了。从技术上讲，这些汽车仍然可以让你从一个地方到另一个地方，因此这些人也可能看不到现代汽车的附加值。也就是说，如果你问的问题超出了车辆的最低要求，那么，就像bash脚本一样，你的里程可能会随着他们说的不同而变化（双关语是无意的）。类似地，bash脚本方法在生产或企业环境中也不可行。