为什么使用 jenkins 而不是简单的 bash 脚本？

Question

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

我知道詹金斯是什么以及它的作用。现在我们来做个比较。

我们使用 jenkins，以便一旦代码通过 git hooks 推送到存储库，我们就运行 jenkins 作业来提取该代码，进行构建，运行测试，然后如果需要，将其上传到代码实际运行的远程计算机。

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

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

问题是：我没有看到那么大的优势。

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

Answer 1

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

\n\n

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

\n\n

为了避免对生产力造成巨大影响，更好的选择是用 Jenkins 构建服务器和管道配置替换这些脚本。

\n\n

当\xe2\x80\x99s时需要替换脚本

\n\n

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

\n\n

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

\n\n

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

\n\n

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

\n\n

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

\n