每个人或多或少总会碰到要使用并且自己完成编写一个最基础的Bash脚本的情况。真实情况是，没有人会说“哇哦，我喜欢写这些脚本”。所以这也是为什么很少有人在写的时候专注在这些脚本上。
我本身也不是一个Bash脚本专家，但是我会在本文中跟你展示一个最基础最简单的安全脚本模板，会让你写的Bash脚本更加安全实用，你掌握了之后肯定会受益匪浅。
其实关于Bash脚本最好的解释如下：
The opposite of "it's like riding a bike" is "it's like programming in bash".
A phrase which means that no matter how many times you do something, you will have to re-learn it every single time.
— Jake Wharton (@JakeWharton)
December 2, 2020
作为一名开发者，您在开发完自己的应用之后，是否有去了解过它是如何部署交付出去的吗？它们都是通过什么工具来完成这些工作的呢？ 如果您从来都没有思考过这个问题，每天重复着类似的CRUD业务实现。那么对于“持续交付”的知识是你跳出舒适区，往更高方向发展所必须学习的内容。 虽然持续交付本身与业务软件的实现没有多大关系，但是这对你理解技术架构与组织管理将会有着非常大的帮助。 最近读了博文视点刚出版的一本新书：《Java持续交付》，个人强烈推荐想要继续提升的Java开发者，基础架构和运维开发来读一下。
注：本文要求读者对Ansible和 Jenkins有一定的认识。
题记: 幸福的家庭都是相似的 不幸的家庭各有各的不幸
行业内各巨头的自动化运维架构都各种功能各种酷炫，如下图，让人可望不可及。现在最终的样子大家都知道了，但问题是如何根据自己团队当前的情况一步步向那个目标演进？
笔者所在团队，三个半开发，要维护几十台云机器，部署了十来个应用，这些应用90%都是遗留系统。应用系统的编译打包基本在程序员自己的电脑上。分支管理也清一色的 dev 分支开发，测试通过后，再合并到 master 分支。生产环境的应用配置要登录上具体的机器看才知道，更不用说配置中心及配置版本化了。
Google和Netflix联合发布了全新的开源Canary分析工具Kayenta。Canary(金丝雀部署)是现代Devops和持续交付中重要的一环，指的是把少量(通常1%-3%)的流量导到含有新版本的canary部署上运行一段时间并和当前的生产环境比较，再决定是否将新版本部署到所有机器的过程。转载请注明出处和原文链接。 以下是项目代码:
将应用程序部署到 Kubernetes 时，有很多选择。像 Helm 和 Ksonnet 这样的工具使得打包应用程序并将其部署到多个 Kubernetes 环境变得非常简单。但是，这些工具只能解决部分问题。部署到生产很少像 helm install my-chart 一样如此简单。他们可以涉及多个步骤，并保证所涉及的应用程序正常运行。我从 Kubernetes 用户那里听到的一个最常见的问题是“如何部署我的数据库变更？”。这是我一遍又一遍地问自己的问题。在 Skuid ，我们花了很多时间试图找出最安全和高可用的方式来执行这些数据库迁移，作为我们部署 Pipeline 的一部分。我们写的代码来做到这一小步在我们的 Pipeline 步骤是很复杂的。
Spinnaker 是 Netflix 开源出来的持续交付工具，目的是为研发团队提供灵活的持续交付流水线，并且支持部署到测试/生产环境。Netflix 目前通过 Spinnaker 实现每天4000次的发布。它的优势在于：
Jenkins Pipeline 插件对于 Jenkins 用户来说可以让用户能够改变游戏规则。基于 Groovy 中的领域特定语言（DSL），Pipeline 插件使 Pipelines 可以有脚本来定义，并且提供了非常强大的方法来开发复杂的、多步 DevOps Pipeline 。本文记录了编写 Jenkins Pipeline 的一些的最佳实践和不推荐的代码示例和说明。
不要使用像 Build Pipeline 插件或者 Buildflow 插件这样的旧插件。而是使用真正的 Jenkins Pipiline 插件套装。
