https://jenkins-zh.cn/tags/devops/ Recent content in Devops on Jenkins 中文社区 Hugo -- gohugo.io zh-CN Mon, 01 Jun 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-01-Your-DevOps-Brain-Ways-of-Thinking-Ways-of-Working/ Mon, 01 Jun 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-01-Your-DevOps-Brain-Ways-of-Thinking-Ways-of-Working/ 我经常不得不说的 DevOps 神话之一就是 DevOps 完全是关于自动化和工具的。尽管二者是达到 DevOps 目标的基本要素（ DevOps 的目标是为了更快更安全地交付更有价值成果而优化从创意到价值实现的过程），但在 DevOps 的发展初期，Damon Edwards 和 John Willis 提出了 CALMS 这一缩写词来帮助解释有关 DevOps 的问题，其中字母 C 表示的文化也是一个重要元素。该想法得到了 Gartner 一篇文章的支持。该文章提到研究表明有 50％的受访者表示人的问题（与流程、技术和信息的问题相对）是目前采用 DevOps 原理和实践的最大障碍。我对自己客户的观察也支持这一想法，我的客户说文化是他们当下面临的最困难的挑战。 客户从一开始就这么说。大约七年前，当我们启动 Ranger4 的 DevOps 业务时，我们以为正在构建的是一个围绕软件和工具的业务。我们之前做么做过，并且这样做也是作为技术人员的合理选择。我们惊讶于客户一遍又一遍地问我们该如何改变文化。我们习惯于谈论技术；情感和感觉这些“软性”的东西是在饮水机旁闲谈的内容，或者用英式术语，说是酒吧里的话题。但是，当我们立即开始帮助客户后就迅速弄清了，文化可以被量化并文化生成的东西可以被确定。显而易见，文化本质上是行为，这很关键，因为我们意识到，可以使用一种在想到改变文化时常常令人感到莫名其妙的方式来影响行为，而文化这种模糊、多面的东西是很难理解的。 帮助组织采用 DevOps 原则意味着我们必须支持组织变革的推动者和领导者，帮助训练大量人力的大脑来理解和实践新的工作方式，从以项目为中心过渡到以产品、自治、价值流或链式思考以及跨职能、渐进式方法的重要转变。 工作做的越多，就越能意识到改变行为是核心，而其关键在于了解驱动行为的因素：我们的大脑。在过去的几年中，我发现神经科学在帮助组织变革上提供了大量指导。由于这是一门科学，是由数据驱动的，所以我们可以信任它。 关于我们都拥有的大脑的一些事实包括： 重 3 磅（体重的 2％） 使用人体内 20％的血液和氧气 干重的 60％是脂肪（那是相当多的） 100,000 英里的血管 2％的脱水时会影响认知能力 每分钟有一公升的血液流过大脑 人类的大脑与体重的比例是最大的 包含 860 亿个神经元 重要提示：如果您想了解更多有关大脑不同部位的信息，可以使用 Wellcome Trust 的交互式 3D 模型 AMAZE 。 关于神经元的一些事实： 它们使用电信号和化学信号相互沟通 神经元通过轴突链接产生神经回路 不同的回路执行不同的任务 一个神经元每秒可以传输 1,000 次神经冲动 大脑中有 10,000 种特定类型的神经元 脑信息以每小时 268 英里的速度传播 学习和不学习( unlearning ) 无一例外，我们客户都将努力从瀑布式过渡到敏捷作为业务和技术挑战核心。他们认识到自己正受到数字化的干扰。如果想要生存，能够蓬勃发展那更好，那么他们就需要在吞吐量和稳定性方面都能做得更好。但是，如果组织中的所有人（无论是 200 人还是 20,000 人）都接受过以项目为导向的工作方式的培训，资金也是以项目为导向，系统随着自身的发展而变成紧密耦合的整体，组织结构被孤立，组织中有负责变革咨询和发布管理团队，组织的工作被外包，技术发展滞后，那么组织中的人将很难改变自己的行为。实际上他们必须忘记（ unlearn ）多年甚至几十年已经学习到并坚信的东西。 https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-20-devops-with-docker-kubernetes-and-azure-devops/ Wed, 20 May 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-20-devops-with-docker-kubernetes-and-azure-devops/ 这篇文章，我们将会分解关于你想了解的 DevOps 的所有知识，因而你可以着手构建自己的 CI/CD 流水线。 这篇文章，我们将注意力集中于 DevOps 上。 什么是 DevOps？它跟 Agile 有什么不同？有哪些受欢迎的 DevOps 工具？在 DevOps 中，Docker、Kubernetes 和 Azure DevOps 又是充当了什么样的角色。让我们从一个简单的使用场景开始这次的内容。 你将会学习 什么是 DevOps？ 为什么我们需要 DevOps？ DevOps 和 Agile 有什么区别？ 有哪些重要的 DevOps 工具？ Docker 怎样能够帮助到 DevOps？ Kubernetes 怎样能够帮助到 DevOps？ Azure DevOps 怎样能够帮助到 DevOps？ 什么是持续集成，持续交付？ 什么是基础设施即代码？ Terraform 和 Ansible 怎样能够帮助 DevOps？ 免费课程 - 10 步速成 10 步学习 Docker https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-19-jenkins-kubesphere-partner/ Tue, 19 May 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-19-jenkins-kubesphere-partner/ 今天，Jenkins 中文社区 与 KubeSphere 开源社区 联合官宣，两大开源社区从今天开始正式合作，携手共建 DevOps 技术生态！ 4 月 14 日，Jenkins 中文社区负责人 Rick 与 KubeSphere 社区多名成员，在技术层面、内容层面、开源社区建设等三个方向进行深入地探讨，最终对两个社区的合作不约而同地达成了一致。 在此次交流会上，KubeSphere 社区 Maintainer @runze xia 先向 Jenkins 中文社区介绍了 KubeSphere DevOps 的技术实现方案，以及为什么采用 Jenkins 作为 KubeSphere DevOps 的引擎。同时，Rick 也向 KubeSphere 社区介绍了 Jenkins-formulas 项目，该项目将来可用来替换 KubeSphere 当前的 Nginx 作为下载插件的 Update Center 方案。 并且，两个社区还将在开源协作与技术内容输出方向共同努力，为社区的开发者和用户带来 DevOps 相关的优质技术文章与实践案例。当然，有一些开发者和社区用户表示，两个社区都开始紧密合作了，两个社区的小伙伴们是不是要约时间面基了？这些要求我们都可以统统安排上！两大社区后续计划联合举办线上的技术直播分享活动、在线研讨会，以及线下 Meetup，欢迎社区小伙伴持续关注我们的动态。 交流会后，Rick 表示自己非常希望加入 KubeSphere 社区，参与 KubeSphere 社区贡献。KubeSphere 社区非常欢迎 Jenkins 中文社区的所有对 KubeSphere 与云原生技术兴趣的同学参与社区开发和文档贡献，KubeSphere 所有的代码、文档、沟通均在 GitHub、Slack 和论坛可见，对于 Jenkins 爱好者我们还在社区设立了 SIG-DevOps 供开发者交流，欢迎大家加入 Slack Channel。 https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-06-using-a-k3s-kubernetes-cluster-for-your-gitlab-project/ Wed, 06 May 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-06-using-a-k3s-kubernetes-cluster-for-your-gitlab-project/ TL;DR k3s 是一个轻量级的 Kubernetes 发行版（小于 40 MB），它非常容易安装，仅需要 512 MB 的 RAM。对 IoT 设备、边缘计算以及运行 CI 任务来说均是一个完美的选择。这篇文章中，我将创建一个 k3s 集群然后向你们展示怎样将它集成到一个 GitLab 项目中。 关于 k3s k3s 是一款由 Rancher Labs 开发的轻量级的 Kubernetes 发行版。 它作为 Kubernetes 认证的发行版使用最低的系统要求: Linux 3.10+ 每个服务器 521 MB ram 每个节点 75 MB ram 200 MB 磁盘空间 x86_64，ARMv7，ARM64 这使得 k3s 非常适合 IoT 相关的事物。 在 GitLab 创建一个项目 在安装 k3s 之前，我们先在 GitLab 上创建一个名为 api 的新项目。 创建完成后，我们进入到 Operation > Kubernetes 菜单。 这里我们有两种选择: 我们可以在 GKE（Google Kubernetes Engine）上创建一个 Kubernetes 集群。 我们可以导入一个已存在的 Kubernetes 集群的配置（不管在哪里创建的）。 注意: 最新版本的 GitLab，新集群只能在 GKE 中创建。GitLab，有没有允许在其他 Kubernetes 提供商（AKS、EKS、DOKS…）创建集群的计划呢？:) https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-24-7-devops-toolchains-orchestration-solutions-you-may-not-know/ Tue, 24 Mar 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-24-7-devops-toolchains-orchestration-solutions-you-may-not-know/ 这七款 DevOps 工具将会帮助你用来考虑将哪个工具包含到你的工具链中。 团队之间的透明化沟通在应用程序开发过程中成为了一项巨大的挑战。一个组织中的大部分团队的独立性已经有相当长时间了。这也就意味着开发团队、业务分析团队、QA 以及业务运营团队之间的工作距离越来越疏远。 在交付结果的时候，公司也因此遭受了不少损失。太长的软件交付流程导致了大多数操作的延迟。业务领域的任何人都能理解这意味着什么。仅仅是没有足够的产品创新。似乎这还不够，对市场需求的反应还不是那么令人满意。 根据一位来自于提供安全编排解决方案的著名公司 Siemplify 的 CEO，Amos Stern 的说法，“使用带有安全编排解决方案的 DevOps 方法可以让你的公司在提高生产力这件事上变得一切皆有可能。” 这些实践尝试将团队凝聚在一起从而避免各自为战。它们以在应用交付时确保高效为目标。这种方法提升了公司软件交付的功能性并且确保产生更少的风险。它们同样负责消除在 IT 响应中出现的各种障碍。 但是这些实践没有工具是不能正常运转的。在不同 DevOps 环境下使用不同的控制工具的解决方案称为“DevOps 工具链编排解决方案”。主要有以下工具组成。 或许你同样感兴趣: 2019 年你应该知道的 5 款 DveOps 工具 1. 源码管理（SCM） 你为公司构建的所有公司想要表达的东西都是通过代码实现的。但是代码同样有窍门的，你必须确保它能尽可能容易地被理解。你必须对它们进行控制和操作分支。如果做不到这些，就有可能面临乱糟糟的情况。 为此，它们拥有的 SCM 包括 GitHub 和 Gitlab。 2. 持续集成（CI） 现在软件开发已经完全需要依赖 CI。这项可操作的技术可以让开发任何东西变得容易。安装一个可设置的 CI 是很重要的，这可以: 减少与集成相关的任何问题 提升代码质量 提升沟通交流 提高发布速度 减少 bug 3. 构建工具 在继续构建组织时，你需要确定哪些工具是重要的哪些又不是你需要的。这不仅仅是重要的，如果你想削减开销这也是必须的。记住，一个公司不注意开支花销的话是很容易出现财务问题的。为此，你需要最好的构建工具来发展你的公司。 4. 测试 任何业务都存在风险。除了危险的风险之外，还有质量保证的整个方面。如果你想实现你的业务目标的话，拥有准确实时这两方面的考量就变得至关重要。 例如 JUnit 和 Mocha 以及其他的一些测试工具可以在追踪它们怎样运行这方面成为可能。 5. 制品管理 一旦你的项目能顺利推进，你需要存储你在流水线中生成的产物。它们需要跟源码存放在 SCM 一样的方式进行保存。存储制品是在需要获取过去产品版本并进行优化时最可靠的方法。 https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-10-create-a-ci-cd-pipeline-with-kubernetes-and-jenkins/ Tue, 10 Mar 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-10-create-a-ci-cd-pipeline-with-kubernetes-and-jenkins/ CI/CD 尝试解决什么问题？ CI/CD 同 DevOps、Agile、Scrum、Kanban、自动化以及其他术语一样，是一个一起被经常提及的专用术语。有时候，它被当做工作流的一部分，但是并没有搞清楚这是什么或者为什么它会被采用。对于年轻的 DevOps 工程师来说，使用 CI/CD 理所当然已经成为了常态，可能他们并没有看到“传统”的软件发布流程而因此不欣赏 CI/CD。 CI/CD 表示持续集成/持续交付和/或部署。如果一个团队不接入 CI/CD 流程就必须要在产生一个新的软件产品时经历如下的阶段： 产品经理（代表了客户利益）提供了产品需要有的功能以及产品需要遵从的行为。文档必须要越详实越好。 具有业务分析能力的开发人员开始对应用进行编码，执行单元测试，然后将结果提交到版本控制系统（例如 git）。 一旦开发阶段完成，项目移交到 QA。对产品进行多轮测试，比如用户验收测试，集成测试，性能测试。在此期间，直到 QA 阶段完成之前都不会有任何代码上的改动。如果有任何 bug 被发现，需要回退给开发人员做修改，然后再将产品移交给 QA。 一旦 QA 完成，操作团队会将代码部署到生产环境中。 上述工作流存在一些弊端： 首先，从产品经理提出需求到产品具备开发条件中间会消耗太多时间。 对开发人员来说，从写了一个月甚至更长时间的代码中去定位问题真的很困难。请记住，bug 只能是在开发阶段完成 QA 阶段开始后被发现。 当有一个*紧急的*代码修复比如像一个严重的 bug 需要热修复时，QA 阶段可能会因为需要尽快部署而被缩短。 不同的团队之间很少会有协作，当 bug 出现的时候，人们就开始互相甩锅互相指责。每个人从一开始只是关心项目中自己的那部分工作而忽视了共同的目标。 CI/CD 通过引入自动化来解决上述的问题。代码中的每次改动一旦推送至版本控制系统，进行测试，然后在部署到用户使用的生产环境之前部署至预生产/UAT 环境进行进一步的测试。自动化确保了整体流程的快速，可信赖，可重复，以及不容易出错。 所以，什么是 CI/CD 呢？ 关于这个主题已经有著作撰写完毕。如何，为什么，以及什么时候在你的架构中使用。然而，我们总是倾向于轻理论重实践。话虽如此，下文简单介绍了一下一旦修改的代码被提交后会执行哪些自动化步骤： 持续集成（CI）：第一步不包括 QA。换句话说，它不关注代码是否提供了用户需要的功能。相反，它确保了代码的质量。通过单元测试，集成测试，开发人员能很快的就会发现代码质量中的缺陷。我们可以增加代码覆盖率的检查以及静态分析让代码质量保证做的更加完善。 用户验收测试：这是 CD 流程的第一部分。这个阶段，会对代码执行自动化测试从而确保代码符合用户的期望。比如说，一个 web 应用没有任何报错产生能正常运行，但是客户想让访问者在导航到主页之前先进入到登录页面。但是当前的代码直接让访问者导航到了主页面，这与客户的需求不相符。这种问题会在 UAT 测试时被指出。而在非 CD 环境，就成了人工的 QA 测试人员的工作。 https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-09-feature-flags-and-gitops-5-use-cases-to-help-you-git-r-done-45ga/ Mon, 09 Mar 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-09-feature-flags-and-gitops-5-use-cases-to-help-you-git-r-done-45ga/ GitOps 的实践是持续交付的下一个替代。它允许开发人员进入 IT 运维的传统工作范围-许多历史关卡的所在地-自动更新生产环境的应用程序和运行程序的基础设施。在 GitOps 中，所有变更管理和版本控制的唯一可信来源是软件配置管理（SCM）。GitOps 抛弃了传统 ITIL 类型的管理，将基础设施和应用程序视为版本化的制品，包括在软件开发期间捕获的相同粒度的审计轨迹（提交 ID，时间戳等）。 我的看法 GitOps 的思想是通过 Git 提交将整个系统的期望状态存储在版本控制系统中。从本质上，您可以将 GitOps 视为一个文件版本控制系统。GitOps 一个关键的原则是通过使用遵守声明式规范的配置文件描述应用程序和环境的期望状态。 这意味着配置根据实际情况而不是操作指南列表管理。它给你一个规则来检查结果是否正确，而不是给你一个配置清单去创建一个系统。你可以用这种方式描述你整个的 CI/CD 流水线并将其放在代码仓库中。为了变更到期望的状态，开发人员发出一个 Pull rquest ，这基本上告诉所有人您已发布到仓库的变更，并告知仓库将变更拉入。通过使用Git，您可以获得版本历史记录、审核日志、回滚功能以及查看谁更改了什么以及何时更改的功能。 特性开关 + GitOps 当我们考虑 GitOps 时，会立即想到的用例是容器编排和集群管理—特别是使用声明性工具 Kubernetes。没有多少人会立即想到[特性标志][1]。那么为什么我们认为特性标志这么重要？这很重要，因为 GitOps 的愿景是对整个系统的全面控制。特性开关通常被视为“规则之外”的活动。我们相信，特性开关-尤其是达到一定规模-将成为一个非常强大的工具，如果它们的管理方式与代码的其他部分一样严格、管理和受重视。如果要使用 GitOps 来管理特性开关，则必须使用配置文件描述它们所需的状态。但这还不是全部。 有一种正确的方法可以将 GitOps 应用于特性开关 特性开关是一个粘性的小窗口。它们拥有进行生产变更的能力，但它们不会像其他代码一样承担生产准备就绪的检验的责任。如果它要成为软件交付生命周期的一部分，就需要不断发展。 如果我们想用 GitOps 管理特性标志，那么所需的状态（由声明性规范描述）必须保存到配置文件中。我们使用 YAML，以便它是人类可读和可编辑的。当需要更新到期望的状态时，只需简单的合并配置即可。此变更通过建立了审核跟踪的PR提交，并确保正确的人员正在验证更改—这正是当有人更改应用程序中的代码或更新基础设施设置时所发生的更改。我们相信这是用 GitOps 管理特性开关的正确方法。这也是最符合供应商中立的愿望的做法。 据我们所知，只有[ CloudBees Rollout ][2]能够支持这一点。我们的一些竞争对手也有一个配置文件，他们的SDK知道如何读取和更改它。但是，它不是可编辑的。它也不会自动保存在像 GitHub 这样的 SCM 中。它们迫使用户绕过管理代码的既定过程，以便管理特性开关。例如，如果需要功能回滚，客户将被迫使用第三方仪表板，而不是 Git。 使用 CloudBees Rollout 管理特性开关的一些‘Git’用例 [配置即代码][3]，这个术语经常与基础设施作为代码（IaC）互换使用，但它实际上是不同的。IaC 是关于基础设施栈的管理和配置，而 CaC 是关于在环境之间自动迁移配置。这都是为了进行环境配置的有力工具。不允许有雪花。我们对待特性开关的方式与配置对待应用程序的方式相同（我们在这里使用 CaC 术语而不是 IaC，因为特性开关不是基础设施的一部分，而是在软件应用程序上）。当我们讨论 GitOps 时，这意味着我们可以用 PR 跟踪 SCM 中应用程序的变更和版本控制的方式，记录特性开关中发生的更改和版本控制。将更改推送到主分支通过 SDK 触发一个待处理的事件。然后，系统知道如何将特性开关更新到 YAML 文件配置所期望的状态。 https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-02-good-to-great-with-devops/ Mon, 02 Mar 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-02-good-to-great-with-devops/ DevOps 不断发展，自从2009年提出此术语以来，DevOps 的状态每年都呈指数级增长。在2019年飞速发展的过程中，各种规模和形态的组织（从企业到初创公司）在 DevOps 方面都展现了极大的热情。每个组织都有其自己的 DevOps故事，其中一些故事尚未开始，一些故事还处于婴儿期，有些故事已经成熟，有些故事已经达到顶峰。 不同于其他故事，DevOps 故事源于不断改进。 随着企业逐渐变得数字化和软件驱动，人们对 DevOps 旅程的本质和可能性有了更大的认识。不仅工程师或技术领导者，甚至商业领导者都对 DevOps 的概念、实践和应用非常感兴趣。对于实现商业成功的 DevOps 的需求已得到越来越广泛的接受。 《 2019 年 DevOps 状态报告》作为大量在线资源的提供者之一，可用于解和学习 DevOps 如何塑造跨行业的软件交付。该报告极大地总结了软件交付的趋势和挑战，它可以帮助团队研究可用于提升软件交付能力并最终成就卓越。 在此报告中，IT 性能称为软件交付能力，以区分软件交付工作与 IT 服务台和其他支撑功能。这是一个期待已久的可喜变化。我也喜欢的关键更改之一是增加了运营指标以完成软件交付周期。该报告重点介绍了五个被称为“软件交付和运营（SDO）性能指标”的度量或指标，它们侧重于系统级结果。这有助于避免软件度量标准的常见陷阱，后者常常使不同的功能相互冲突，并导致以牺牲总结果为代价的局部优化。 该报告重点介绍了软件交付能力的四个方面，如下所示： 部署频率 – 对于您从事的主应用程序或服务，您的组织多久部署一次代码？ 变更的前置时间 – 对于您从事的主应用程序或服务，您的变更前置时间是多少（即，从代码提交到成功在生产中运行的代码需要多长时间）？ 恢复服务的时间 – 对于您正在使用的主应用程序或服务，发生服务事件（例如计划外中断或服务受损）时，恢复服务通常需要多长时间？ 变更失败率 – 对于您使用的主应用程序或服务，导致服务质量下降或随后需要修复（例如，导致服务受损、服务中断，需要修改程序、回滚、向前修复、修补程序）的变更的百分比？ 然后对这四个方面进行度量，以对四个类别的性能进行排名：精英、高级、中级和低级。下表（从报告中引用）指示了各个方面的详细信息。 我强烈建议添加到此列表中的另一个方面是“团队敬业度指数”，即团队的快乐程度和参与度。我认为团队绩效与团队敬业度成正比。团队敬业度越高，即团队越快乐越敬业，他们产生的结果就越好。 报告中的另一个主题是“ J 转换曲线”。下图突出显示了自动化如何帮助绩效低下的人员提升到中等性能水平，然后测试需求、技术负担和复杂性增加导致手动操作，从而导致进度变慢。这是一个有趣且值得注意的观察。它强调了自动化并不总是答案。如果您使错误的流程自动化，那么您得到的只是错误的结果，而且更快。 无休止的改进、学习、共享和利用专业知识可将您带到高水平或精英绩效水平 – 将团队提升为精英绩效的旅程需要的不仅仅是工具。在各个级别（即团队级别、领导级别和赞助者级别）的坚持、恒心和毅力对于从低绩效水平或中绩效水平取得突破以发挥团队最大潜力至关重要。如果我们踏上精英绩效之旅，您会发现自动化、技术实践和持续改进计划是您旅途的催化剂。鉴于测试需求、技术债务和日益增加的复杂性将成为您的阻碍，我发现锚定和引擎（帆船回顾展）格式提供了一种快速而有趣的方法，可在一幅图片中（如下所示）可视化催化剂（引擎）和阻滞剂（锚定）。 行业看到了更高的精英绩效 该报告证实，精英表演者的比例几乎增加了两倍，低表现者的比例下降了，中等表演者的比例上升了。要注意的一项主要观察结果是，从低性能到中性能再到高性能的移动不是单向的。当面对复杂性增加时，团队（从 J 曲线中突出显示）可以从高位降为中级，也可以从中级降为低级。总体而言，很高兴看到向上增加。 前进之路 软件交付性能可以通过多种方式确定业务成果。 组织推动软件交付绩效的能力包括文化，技术实践，清晰的变更流程，持续交付和基于价值的成果。 这些功能并不是一蹴而就的，需要对组织 DNA 进行根本性的改变。 根据我在不同行业和公司中工作的经验，我可以确认这些软件交付能力集群不是静态的。上面列出的任何功能的更改都会对软件交付能力产生影响，您可能会发现能力集群在两个方向上都从一个级别波动到另一个级别。关键是要保持专注并通过定期将其嵌入组织的工作方式中来维持它。 https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-21-the-abc-of-devops-implementation-with-containerization-and-docker/ Fri, 21 Feb 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-21-the-abc-of-devops-implementation-with-containerization-and-docker/ DevOps 在 IT 行业中风靡一时。维基百科中阐述 DevOps 是将软件开发（Dev）和信息技术维护（Ops）结合在一起的一组实践，旨在缩短系统开发生命周期并提供高质量的持续交付。 DevOps 普及的主要原因是，它使企业可以比传统软件开发方法更快地开发和改进产品。 随着我们工作环境的变化越来越快，对软件开发市场中的快速交付和修复的需求正在上升。 因此，对在短时间内生产高质量输出且有限的后期错误需求催生了 DevOps。 你可能感兴趣：Docker 和 DevOps：开发有状态的应用程序并在 Docker 中进行部署 正如我们已经讨论了转变为 DevOps 软件开发方式的重要性一样，我们现在将对话更改为容器化，这是一种易于使用的技术，经常被用来使 DevOps 的实现更流畅、更便捷。 容器化是一项使 DevOps 实践更容易遵循的技术。 但是容器化到底是什么？ 让我们一探究竟！ 什么是容器化？ 容器化是将应用程序及其所需的库、框架和配置文件打包在一起的过程，以便可以在各种计算环境中高效运行它。简单来说，容器化就是应用程序及其所需环境的封装。 近来，它克服了运行虚拟机所带来的挑战，从而获得了广泛的关注。虚拟机模拟主机操作系统内部的整个操作系统，并且需要固定比例的硬件分配才能运行操作系统的所有进程。因此，由于很大的开销，这导致不必要的计算资源浪费。 同时，设置虚拟机需要花费时间，在每个虚拟机中设置特定应用程序的过程也需要时间。这导致仅在设置环境时就花费了大量时间和精力。由开源项目 “Docker” 普及的容器化解决了这些问题，并且通过将所有必需的依赖项与软件一起打包在便携的镜像文件中，从而提高了可移植性。 让我们更深入地研究容器化，它的好处、它的工作原理、选择容器化工具的方式以及它如何胜过虚拟机（VM）的使用。 一些流行的容器提供程序如下： Linux 容器，例如 LXC 和 LCD Docker Windows Server 容器 什么是 Docker？ Docker 已经成为 IT 行业中的一个流行术语。 Docker 可以定义为一个开源软件平台，它提供了一种在容器内构建、测试、保护和部署应用程序的简化方法。 Docker 鼓励软件开发人员与云、Linux 和 Windows 操作系统进行协作，以轻松、快速地交付服务。 Docker 是提供容器化的平台。它允许将应用程序及其依赖项打包到一个容器中，从而有助于简化开发并加快软件的部署。它消除了在应该测试解决方案的每台机器上复制本地环境的需求，从而帮助实现了输出的最大化，从而节省了宝贵的时间和精力，而这些宝贵的时间和精力将用于进一步的开发。 Dockerfile 可以在工作人员之间快速传输和测试。 Docker 还简化了容器镜像管理的过程，并迅速改变了我们大规模开发和测试应用程序的方式。 容器化——实现 DevOps Docker 已普及了容器化的概念。 Docker 容器中的应用程序具有能够在多种操作系统和云环境（例如 Amazon ECS 等）上运行的能力。没有技术或供应商局限。 https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-14-devops-trends-to-watch-for-in-2020/ Fri, 14 Feb 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-14-devops-trends-to-watch-for-in-2020/ Netscape 的创始人 Marc Andreessen 很久之前就谈到过软件是如何吞噬整个世界的。他还说过，当今，每一家公司都可谓是软件公司，它们已经做好准备来接管广阔的经济领域。在 2020 年，您会清晰地看到 DevOps 持续不断的更新是如何改变交付方式的，将软件交付到几乎是无限的市场中。在这个技术竞争激烈的世界中，DevOps 已成为蓬勃发展的必需品了。 导引 虽然每个企业对 DevOps 有着不同的理解，但我们仍然可以将 DevOps 定义为一个团队为了将其工程能力提升到新的高度而采用的一种心态。DevOps 的主要目的是消除工程实践上的障碍，重点是那些存在于想法和实践之间的文化障碍，从而使软件的交付过程变的更好、更快、更廉价和更安全。 无论您怎样称呼 DevOps，它最终都应该归结为自动化，而自动化反过来又应该有助于公司的快速发展、快速交付、快速失败、快速恢复以及快速学习。 从 SDLC（System Development Life Cycle，系统生命周期）模型的出现到今天，情况已经发生了巨大的变化。在 2009 年，DevOps 诞生了，它倡导文化的转型和一些将所有事物都视为代码的技术原则。随后出现了诸如 CI/CD 之类的理念，但是，软件曾经是作为一个巨大的单体被编写的，这个转变过程带来了许多挑战。 因此，在 2011 年引入了微服务架构，它提倡细粒度和松耦合的组件划分方式，其中每个组件都承担特定的职责。 遵循这种松耦合、微服务架构而编写的应用程序被称为云原生应用。当前，众多企业根据其业务需求和目标，正在从虚拟机过渡到 Kubernetes 和 Serverless。 根据 Kelly Shortridge 和 Nicole Forsgren 博士在 Black Hat USA 2019 上发布的幻灯片，在与 DevOps 行业中卓越的实践者进行对标时，有四个因素特别关键，分别是： 变更前置时间 发布频率 恢复时长 变更失败率 在本文中，我们将会了解到 DevOps 在未来的发展趋势。 云原生将成为必然 Diamanti 对 500 多位 IT 主管进行了调查。结果表明，从所有方面来看，容器技术已经远远超出了预期，它在一年内迅速成熟，并从开发者试验转向了生产环境。云原生技术将会上升到一个新的高度，尤其是对 Kubernetes 的采用。云原生为公司提供了更大的优势，使其以更快的速度将产品推向市场。 什么是云原生 采用云原生意味着更好的创新、更先进的转型以及更丰富的客户体验。如我在的另一篇文章“ Cloud-Native DevOps”中所述，云原生从根本上促进了云自动化，这里指的是云计算服务的安装、配置和监控的自动化管理，它是关于使用技术在恰当的时间为您的云计算资源做出更可靠的业务决策。 https://jenkins-zh.cn/wechat/articles/2019/11/2019-11-06-building-new-operating-model-devops/ Wed, 06 Nov 2019 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2019/11/2019-11-06-building-new-operating-model-devops/ 我一直在撰写有关企业面临的 DevOps 挑战的文章。从根本上讲，它是关于规模的：当企业尝试将其扩展到大型企业通常拥有的 800 多个应用程序中时，它们正努力实现在小型 DevOps 概念验证中看到的相同收益。 如果 DevOps 能够兑现其诺言并为企业带来可观的价值，那么就必须克服这一规模挑战。 重塑业务 今天，我想看看企业内部的关键变化，在实现 DevOps 的好处之前，这绝对是必须发生的：运营转型。 如今，大多数企业都围绕具有单向命令和控制结构的分层模型工作。这是自去年以来建立企业的方式：公司高层的“高级主管”领导层以相当专制的方式设定了公司的目标和战略。在此模型中，经理和业务部门负责人是高级管理人员意愿的执行者，以确保公司其他所有人都可以执行其战略方向。DevOps 的发展方向相反-从开发人员和运营人员的基层运动开始，然后逐步发展到如今在董事会席位上占有一席之地。 民主发展 为了使 DevOps 大规模发展，需要用更加有机、松散和自治的东西来代替这种结构。如果旧模式是专制的，那么新模式与现代政治革命家在松散连接和组织上“扁平”的结构中融合的方式有更多的共同点。 DevOps 的理想运营模式是一种权力民主化的模式，并且公司中的每个人都有权发挥自己的领导作用。在这里，高级主管确定了出行的方向，但是然后相信他们熟练的开发人员会做些必要的事情。在这种模式下，管理者促进和授权，而不是直接参与；确保开发人员拥有实现目标所需的一切，同时在这里和那里轻轻地推动，以确保他们的工作与整体公司议程和战略路线图保持一致。这涉及到我们在流动的劳动力中看到的宏观变化，并逐渐过渡到非中介的世界。 毋庸置疑，进行这种转换并不容易。这意味着要颠覆数百年来公认的惯例，放弃某些人认为晋升和任期使他们有权获得的精细控制。而且要明确一点：IT 部门将首当其冲。长期以来，控制权的守卫者需要转变为促进者。IT 将围绕应用程序开发设置指南和策略，并在需要时进行干预，但在日常工作中，IT 部门将需要退后一步，让 DevOps 开发人员继续前进，然后一定会建立信任和真正创新的文化，并蓬勃发展。 让专家掌控 开发人员团队比公司中的其他任何人都更了解他们的业务所面临的软件工程挑战。他们是理想的解决方案，同时敏捷的 DevOps 流程将帮助他们做到这一点。但是，如果开发人员大规模利用 DevOps，则需要摆脱来自 IT 和更广泛业务的严格监督。这不是关于信任的问题-人力资源和分析技术可供企业领导者远程监视和分析开发人员的效率。它只是归结为效率：以一种更加敏捷和有效的开发方法来消除障碍。以一种可以为您提供广泛、以业务为中心并且与供应商无关的方式执行此关键操作。如果没有民主变革的能力，并根据我们的经验来衡量结果，您将永远无法完全成功并获得真正的利益。 在我的下一个博客中，我将探讨帮助 DevOps 扩展的另一个关键因素：度量。 因此，请再次访问。 https://jenkins-zh.cn/wechat/articles/2019/08/2019-08-14-continuous-testing-what-why-and-how/ Wed, 14 Aug 2019 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2019/08/2019-08-14-continuous-testing-what-why-and-how/ 敏捷，DevOps 和持续交付已然存在于现今每个技术人员的词汇当中。我们都想要像硅谷里的巨头和初创公司一样，敏捷开发，快速发布软件，做出创新的产品。 向敏捷转型在多方面都已有总结，并且到了能被顺利实践的程度。然而，测试仍然是一个有思想困惑和实践挑战的领域。 当软件发布周期从以年、月缩短到以周、天为单位，或者更短时； 我们该如何重塑测试实践，以保证当软件发布到生产环境时能令用户满意， 而不是掉链子？ 鉴于大多数 DevOps 实践仍然把测试视为软件生产中最令人头疼的瓶颈，显然，这是一个常见的挑战。 持续测试就是答案，但持续测试究竟是什么？你又如何实现它呢？ 维基百科定义持续测试为「在软件交付流水线中执行自动化测试的过程，目的是为了获得关于预发布软件业务风险的即时反馈」。 但是这个定义缺少了本质，缺少了持续测试所示意的转变的量纲。 除了自动化是一个重要的部分以外，持续测试从根本上转变了测试， 它把线性过程中的时间点事件嵌入到整个过程当中去，作为基础贯穿于整个软件交付周期的所有活动中。 敏捷环境里持续测试的目标应该是「迭代内测试（in-sprint testing）」。 不管你的迭代是两周还是四周，目标都应该是完成迭代内所有类型的测试，这样每个迭代都可以得到一个测试完备的，准备交付的软件。 事实上很多持续交付的最佳实践都会告诉你，你不能简单的在没有持续测试的情况下去做持续交付。 如果你认为你的迭代时间不允许你去做一个综合的测试，很有可能是你对它的理解有误。 七个步骤实现持续测试 1. 尽早规划测试，甚至早于写代码 描述不清的要求或者有不正确的理解，都可能导致返工甚至延期。 使用像行为驱动开发(BDD)， 验收测试驱动开发(ATDD)和 基于模型的测试这类技术所使用的工具，如 cucumber/gherkin 和 CA Agile Requirements Designer (ARD)， 可以确保业务主管，产品经理，开发人员和测试人员充分沟通并记录需求，定义清晰的测试用例，提早编写测试脚本，以达到一个流畅的测试过程。 2. 优化测试覆盖率 一些组织默认「每次运行所有的测试」来保证代码覆盖率。这不但浪费资源还延长了测试周期，而且没有真正的保证代码覆盖率。 测试那些需要测试的部分，以节省时间、金钱和资源。可视化模型可以让各种路径被探索优化，以便只用少量的测试用例就能提供最大化的覆盖率。 可以借助 Rally, Jira, HP ALM, JIRA 等此类工具导入测试用例、移除重复用例、分发优化过的用例。 3. 测试左移 为了实现「迭代内(in-sprint)」测试，将测试前置——这样测试可以在开发周期的早期运行。开发人员自己测自己的；卓越中心提供专家，定制系统和服务。 自动化测试覆盖 UI, 功能，性能和安全。各个团队一起工作，一起以要交付给客户的业务价值为专注点。这需要对开发者友好的工具以及文化转变。 4. 提供完整的测试环境 提供测试环境的能力对实现持续测试是至关重要的。 通过友好型（例如编码、CI/CD 集成、被开源支持的软件）开发工具按照需求提供的完整的测试环境来消除障碍和减少等待时间。 这些环境应该包括： 虚拟服务——给那些不可达，不可访问的，还在开发中的服务提供鲁棒的模拟。开发和测试可以根据虚拟服务模拟实际服务返回的结果持续并行工作。 按照需求测试数据——帮助并保证各个团队可以使用与生产环境类似的数据来运行综合的测试。 预发环境——准备上线的需求，使用后退役。 5. 获取正确的测试数据 在很多应用发布周期，获取鲁棒性测试数据能力的缺乏会造成严重延期。为了准确的测试新功能，测试数据应该尽可能的跟生产环境时所应用遇到的数据相近。 如果测试数据缺乏特定真实世界的特征（例如具体字段、数据定义、负面场景等），测试就很难找到许多潜在问题和应用的弱点。 理解数据模型并提取出正确的数据是一种特殊的技巧。尽管使用生产环境数据测试是最接近真实的，但数据隐私条例通常都会限制使用生产数据。 下面，我们来看看 CA Test Data Manager 是如何复制生产数据，抹掉敏感信息的同时保持了测试所希望的生产数据特征（接近现实，并且多行指征完整）的。 生产数据不可用时，测试数据也可以使用 TDM 工具根据模版生成。 https://jenkins-zh.cn/wechat/articles/2019/06/2019-06-17-10-courses-to-learn-devops-engineering-in-depth/ Mon, 17 Jun 2019 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2019/06/2019-06-17-10-courses-to-learn-devops-engineering-in-depth/ DevOps 现在真的很热门，对于杰出的工程师和 DevOps 专业人员来说有许多工作机会。 如果你想成为一名 DevOps 工程师，那么你来对地方了。在本文中，我将分享一下最好的在线培训课程， 让你成为 DevOps 专业人员。 Devops 最重要的优势，它可以帮助你更好地发布软件并且利用现代自动化工具对环境和软件开发过程中提供更多控制。这就是 DevOps 专业人员需求呈指数增长的原因。除了 Data Science 和 Machine Learning 外，它也是薪酬最高的 IT 工作之一。 根据 Glassdoor 的数据，DevOps 的工程师每年的收入从105000美元到146000美元不等。这意味着，如果你正在寻找加薪或想在美好年纪从事一些令人兴奋的工作赚更多的钱，学习 DevOps 可能是一个不错的选择。 学习像 Jenkins 这样的持续集成工具和像 Docker 这样的容器以及一般的 DevOps 技能，在技术领域获得了巨大的动力。这与几年前的移动应用程序开发类似。 公司希望新的开发人员能够管理 Web 应用程序的整个生命周期。这意味着开发和部署应用程序。 为了成为一名有效的 DevOps 工程师，您必须扩展对软件开发中使用的不同工具的知识，包括构建工具（如 Maven、 Ant 和 Gradle ）、单元测试工具（如 Junit 和 Selenium ）、部署工具（如 Docker ）、监控工具（如 New Relic ）、基础设施自动化工具（如 Chef 和 Puppet ）、源代码控制工具，如 Git 和 Github，以及持续集成工具，如 Jenkins 和 TeamCity。这些课程为基本的 DevOps 工具提供了很好的介绍。 十节面向经验丰富的开发人员 DevOps 课程 在不浪费更多时间的情况下，这里列出了一些学习 DevOps 的最佳课程以及在软件开发和部署过程中实现自动化所需的基本工具。 https://jenkins-zh.cn/wechat/articles/2019/06/2019-06-05-devops-challenges-in-2019-how-to-overcome-them/ Wed, 05 Jun 2019 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2019/06/2019-06-05-devops-challenges-in-2019-how-to-overcome-them/ 随着 DevOps 逐渐成为主流，许多团队都在问自己应该从哪里开始采用 DevOps ， 他们将在此过程中面临哪些挑战，以及如何解决那些挑战。 每年都有越来越多的公司希望从传统的瀑布式方法转向 DevOps 。 许多软件开发公司将 DevOps 看作是一个公司在效率方面所能达到的顶峰，并且这有点难。 应对挑战可能大大降低你的生产力，同时适应 DevOps 方法会导致各种自动化工具和开发过程之间缺乏协调。 在本文中，我们将讨论 DevOps 在2019年面临的一些重大挑战，以及可以采取哪些措施来战胜它们。 关注遗留的应用程序和系统 DevOps 团队面临的第一个和主要挑战涉及到遗留应用程序的构建， 这些应用程序是在没有考虑 DevOps 的情况下构建的。 这似乎看起来有益无害，但这对于转变来说是相当棘手的。 即使你关注使用 DevOps 的新应用程序和系统，你也需要维护这些遗留系统。 对于遗留应用程序的转变这里还有其他原因。 一开始，你需要努力逐步将淘汰它们，或者逐渐将客户转移到使用 DevOps 系统维护的新版本。 否则，你可以尝试创建一个新的系统来维护遗留的应用程序，它不会干扰你的 DevOps 系统。 你也可以使用 Scala 性能度量工具，比如 AppOptics ，它有助于逐步淘汰非 DevOps 系统。 选择适合的项目 对于一个新的 DevOps 团队来说，为每个新项目选择 DevOps 似乎很明智，但事实并非总是如此。 DevOps 不是强制性的，因为如果没有正确地实现 DevOps ，有时会降低整个生产过程的速度。 因此，在选择要使用 DevOps 的项目时，你应该非常勤奋。 在考虑 DevOps 是否必要时，最好记住 DevOps 是一种运营策略，并不总是适合的。 如果你正在努力快速规模化的软件，并从其敏捷性中获得更快的速度，那么 DevOps 是一个明智的选择。 同样地，DevOps 并不是一直起作用，所以不应该把它当作解决所有问题的首选解决方案。 例如，如果你正在使用一个较旧的系统，那么最好坚持使用旧的方法和流程，因为不可能总是为这些方法和流程找到自动化的系统。 除此之外，规划和设计工作被认为不适合 DevOps ，因为进行设计和 UX 是处理流程的更成功的方法，而不是不断改进。 https://jenkins-zh.cn/wechat/articles/2019/05/2019-05-17-from-jenkins-to-jenkins-x/ Fri, 17 May 2019 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2019/05/2019-05-17-from-jenkins-to-jenkins-x/ 这是一个关于 dailymotion 从 Jenkins 到 Jenkins X 的旅程，我们遇到的问题，以及我们是如何解决它们的故事。 我们的上下文 在 dailymotion ，我们坚信 devops 最佳实践，并且在 Kubernetes 投入了大量投资。 我们的部分产品已经部署在 Kubernetes 上，但并不是全部。 因此，当迁移我们的广告技术平台的时候，我们想要完全采用“ Kubernetes 式”——或者云原生，以追随技术趋势！ 这意味着要重新定义整个 CI/CD 流水线，从静态/永久环境迁移，转向动态按需分配环境。 我们的目标是授权给我们的开发人员，缩短我们的上线时间以及降低我们的运营成本。 对于新的 CI/CD 平台我们的初始需求是: - 尽可能避免从零开始：我们的开发人员已经习惯使用 Jenkins 和声明式流水线，并且它们可以很好地满足我们当前的需求。 - 以公有云基础设施为目标——Google 云平台和 Kubernetes 集群 - 与 gitops 方法论兼容——因为我们喜欢版本控制、同行评审和自动化 在 CI/CD 生态系统中有相当多的参与者，但是只有一个符合我们的需求，Jenkins X ，它基于 Jenkins 和 Kubernetes ，原生支持预览环境和 gitops Kubernetes 之上的 Jenkins Jenkins X 的设置相当简单，并且在他们的官方网站上已经有很好的文档（译注：译者曾对 Jenkins X 文档中文本地化做了一些贡献，同时也期待更多的人参与以完善中文文档）。 由于我们已经使用了 Google Kubernetes Engine (GKE)，所以 jx 命令行工具自己创建了所有东西，包括 Kubernetes 集群。 这里有一个小小的*哇哦效果*，在几分钟内获得一个完整的工作系统是非常令人印象深刻的。 https://jenkins-zh.cn/wechat/articles/2019/05/2019-05-14-devops-jenkins-credential-manage/ Tue, 14 May 2019 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2019/05/2019-05-14-devops-jenkins-credential-manage/ 背景 了解到行业内有些团队是基于 Jenkins 开发 DevOps 平台。而基于 Jenkins 实现的 DevOps 平台，就不得不考虑凭证的管理问题。 本文就此问题进行讨论，尝试找出相对合理的管理凭证的方案。 一开始我们想到的方案可能是这样的：用户在 DevOps 平台增加凭证后，DevOps 再将凭证同步到 Jenkins 上。Jenkins 任务在使用凭证时，使用的是存储在 Jenkins 上的凭证，而不是 DevOps 平台上的。 但是，仔细想想，这样做会存在以下问题： * Jenkins 与 DevOps 平台之间的凭证数据会存在不一致问题。 * 存在一定的安全隐患。通过 Jenkins 脚本命令行很容易就把所有密码的明文拿到。哪天 Jenkins 被注入了，所有的凭证一下子就被扒走。 * 无法实现 Jenkins 高可用，因为凭证存在 Jenkins master 机器上。 那么，有没有更好的办法呢？ 期望实现的目标 先定我们觉得更合理的目标，然后讨论如何实现。以下是笔者觉得合理的目标： > 用户还是在 DevOps 管理自己的凭证。但是 DevOps 不需要将自己凭证同步到 Jenkins 上。Jenkins 任务在使用凭证时，从 DevOps 上取。 实现方式 Jenkins 有一个 Credentials Binding Plugin 插件，在 Jenkins pipeline 中的用法如下： withCredentials([usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')]) { sh ''' curl -u "$USERPASS" https://private. https://jenkins-zh.cn/wechat/articles/2019/04/2019-04-28-devsecops/ Sun, 28 Apr 2019 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2019/04/2019-04-28-devsecops/ Helen Beal 曾经在一次讨论什么是 DevSecOps 工程师的会议上发言。令她惊讶的是，在与会人员中，许多人都没有将安全机制引入 DevOps。在与人们讨论之后，她将大家的问题总结为三类：安全机制会制造额外的隔阂；组织中的人很难理解 DevOps，因此安全机制可能会造成更多困惑；可能没有为安全机制预留空间。 当然，Helen 不同意这些观点。她在技术领域从业近20年，专注于软件开发生命周期，对于 DevOps 和DevSecOps 有一些自己的理解。她自称为 Ranger4 的 「DevOpsologist」，因为她帮助那里的组织实现 DevOps。她在世界各地分享知识，并且她将参加我们在 2018 年的 Nexus User Conference ，讨论工具仓库及其在 DevSecOps 工具链中的角色。 从高层次来看，Helen 为 DevSecOps 提出了一些重要建议： 确保安全是每一个人的职责 认识到安全人员的匹配限制。平均而言，人员比例为 100 名开发人员 : 10 名运维人员 : 1名安全人员 尽早移交产品进行测试和验证。缺乏足够的安全人员会造成一定的约束，移交并自动执行任务可以减少瓶颈并提前解决问题。 积极主动地降低风险 培养安全文化 Helen 花了一些时间阐述如何培养安全文化，组织在维护系统和人员行为安全时可以采用的一些关键原则和行动。 行为安全使个人和团队能够以安全的方式行事。为了培养行为安全，她建议： 让人们意识到，失败是一个学习机会 确保团队之间有共同的责任和目标 不要吝啬花时间做实验 使用可协作的平台来分享学习经验和最佳实践 对实验的过程进行回顾，并确保有后续 她提到了几个真实的例子，例如 Esty，LEGO 还有 P&G 的「失败奖励」以及 Spotify 用来展示和追踪失败的「失败墙」。 系统安全能够保障你的基础设施安全，她关于培养系统安全的建议包括： 用持续集成进行构建 使用部署自动化来驱动一致性和可审计性，并允许即时重新部署上一个已知的可用版本 用 ChatOps 来归类问题和事件 使用应用程序性能管理以提早发现问题并警告 降低出现问题波及范围，例如使用功能开关，金丝雀测试，蓝／绿环境和微服务 将产品需求与服务台相结合 养成使用混沌工程来找到失败原因的习惯 在讲述 DevSecOps 案例并说明如何灌输安全文化后，她将话题转向如何使用制品仓库。 毕竟，这是一个 Nexus 会议，制品仓库是 Nexus 的特色。 https://jenkins-zh.cn/wechat/articles/2019/04/2019-04-22-jenkins-weekly-2.173/ Mon, 22 Apr 2019 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2019/04/2019-04-22-jenkins-weekly-2.173/ 本次更新移除了一些不太推荐的功能，请管理员及时关注，如果希望能恢复的旧的形态，可以按照下面的提示操作。 另外，有一项重要的更新，使得我们可以把所有的中文本地化资源文件从 Jenkins 核心中移除。因此， 请关注 Jenkins 简体中文插件后续的动态，我们会及时完成所有的迁移。 移除对 CCtray 文件的内置支持。 如果要继续使用该功能的话，请安装CCtray XML Plugin (issue 40750) 调整代码在远程计算节点上运行时的流刷新行为，使得具有更好的性能。 这可能导致插件在节点集群上输出日志，但是没有刷新时，丢失消息。 使用 -Dhudson.util.StreamTaskListener.AUTO_FLUSH=true 恢复自由风格构建之前的行为。注意，流水线的构建总是需要远程刷新。 (pull 3961) 增加用于将新创建的 API token 拷贝到粘贴板的按钮。 (issue 56733) 使得 Jenkins 经典界面上的表单提交按钮，对 Firefox 的 bug 修复是兼容的。 (issue 53462, Firefox bug 1370630) 如果一个工作空间已经被跨节点重连的流水线正在使用，那么，不会提供给新的构建。 (issue 50504) 从核心中移除 Mailer 相关的本地化字符串。确保你使用 Mailer Plugin 1.23。 (issue 55292) 从 Maven 控制台装饰器中适当地刷新输出。 (issue 56995) 开发者：更新 Stapler 1.256 到 1.257，增加对从任意插件中加载本地化 webapp 资源的支持。 增加接口 jenkins.PluginLocaleDrivenResourceProvider 使得插件可以参与本地化资源的查找。 (JEP-216, 完整的变更日志) 开发者：SystemProperties 可以在计算节点中使用。 参考 SystemProperties#allowOnAgent。 (pull 3961) 开发者：增加 LineTransformationOutputStream#Delegating 使得更加方便。 (pull 3959) 开发者：hudson. https://jenkins-zh.cn/wechat/articles/2019/04/2019-04-19-the-business-value-of-cd/ Fri, 19 Apr 2019 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2019/04/2019-04-19-the-business-value-of-cd/ 持续交付使你能够以更低地风险、更快低交付新软件或是更新已有软件。 降低风险很重要，但是，支持持续交付的流程将转化为对业务更重要的价值： - 加速价值时间。 一个小企业不需要一个 MBA 就可以认识到持续交付可以帮助他们完成工作。 一家大型企业已经规划了其价值流， 并且在整个大型组织中拥有复杂的投资和合约， 将发现持续交付有助于加速实现价值的时间。 - 数据驱动决策。 部署、度量和调整。 你仍然可以推动更大规模的发布，但你的流程将更适合于持续的数据收集。 这将缩短与客户的反馈循环。 它提高了你的反应能力，计划你的下一步行动，并保持领先的竞争力。 - 质量。 你持续发布的行为使你必须提高你的质量标准以及完全的自动化测试实践。 更好的质量意味着更快乐的客户、更低的成本、更少的消防演习和更少的计划外工作。 - 试验 = 创新。 开发人员和业务线可以自由地以较低的成本尝试新的想法， 从而释放出长期高投资发布周期背后的创新想法。 - 降低成本。 大的发布会有巨大的成本，如果出现错误会有严重的后果。 保持可交付成果处于可发布状态会降低交付成本。 对企业来说，这些价值一起使持续交付成为真正的游戏变革者。 尽管可以在团队或项目级别开始采用和验证，但持续交付的本质是它以需要真正投资和自上而下承诺的方式跨越了组织边界。 选择与现有投资互补并共存的持续交付工具链是走向成功的关键一步， 特别是因为 CD 可以引导你的组织采用 DevOps 文化。 持续交付为创建更好的软件开辟了全新的道路。 CD 是商业层面的热门话题，这有很多的原因： - 早期的采用者已经证明了它的价值。 主流采用者都观察到了它的优势，并感觉到竞争的刺痛，因为他们更灵活的竞争对手超过了他们。 - DevOps 作为一种运动获得了关注。 业务人员理解，在开发和运营之间有一个共同的理解，打破孤立的行为，并在整个组织内发展一种责任文化，是提高效率和上市时间的关键步骤。 在许多方面，持续交付等同于 DevOps 。 - 随着软件“吞噬世界”，商业领袖们越来越清楚 IT 必须被用作战略资产。 在正确处理安全性、可用性和合规性的同时，能够缩短交付时间、提高质量并快速适应变化是一项挑战。 持续交付，强调自动化和尽早的、直接的反馈，是实现这些目标的方法。 - 当你通过持续交付实现廉价的、低风险的试验时，你可以用更多的信息指导业务投资，并发现你可能完全错过的机会。 持续交付正在改变企业使用其 IT 资产与客户和合作伙伴联系的方式。 CD 建立在多年来之不易的敏捷过程和持续集成经验的基础上， 将这些好处提升到业务级别，而不是简单地成为开发团队使用的技术， 并最终导致 DevOps 。 随着开发和运营人员学习如何协作和分担责任时，许多成功的关键都植根于组织和文化的变革。 无论是在组织范围内还是在本地，实现这种变革的技术工具链可能包括 Jenkins 。 CloudBees Jenkins 企业版，通过扩展开源 Jenkins 的使用范围， 提供了一个支持 Jenkins 混合模型（本地部署、云上部署或混合部署）的平台， 是组织在今天转向持续交付和在不久的将来实施 DevOps 的必要工具。 https://jenkins-zh.cn/wechat/articles/2019/04/2019-04-17-aiops/ Wed, 17 Apr 2019 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2019/04/2019-04-17-aiops/ DevOps 和云技术正在逼近极限 范式转变往往会产生意想不到的后果，这些后果可能需要数年才能被完全消化。 云计算就是一个很好的例子。 云计算迎来了灵活的基础设施和低资本要求的时代，由于资源只是一个API调用，工程师们无需等待部署。 然而，这一切只是开始。 敏捷的公司利用云来打破开发和运维之间的隔阂，并采用敏捷方法以缩短开发周期，从而创造战略优势。 他们将应用程序生命周期中的工程师团队分工从之前的开发和测试变为部署和运维， 并创建了需要一系列新技能的职位。这些公司使用 CI/CD 和 DevOps 进一步推动自动化流水线， 以实现更快的交付。 这样有隐患吗？去问你的 DevOps 团队 DevOps 团队的任务是维护一个工具链，以便自动交付新代码，按需扩展，以及五个 9 的正常运行时间。 在空闲时间，他们致力于提高性能和控制成本。 对于大的应用程序，可以有数千个虚拟机或容器，每个虚拟机或容器都有一堆软件， 还有负载平衡器和自动扩容等云服务，所有这些都必须进行配置和维护。 这一切都在不断发展中。 我之前了解过的一个大型独角兽公司拥有数百名开发人员，每天更新代码超过 100 次， 云上有超过 4000 台虚拟机，每月收集数 PB 的数据。 而他们的 DevOps 团队只有十几个人手，直到去年才有 VP。 对他们来说，这是一个艰巨且繁重的任务。 应付这无数的挑战已经超出了人类的能力范围。 幸好，AIOps 正在成为一种解决方案。 AIOps 一词是由 Gartner 创造的， 他将其解释为： AIOps 结合了大数据，机器学习和可视化技术，通过更强的洞察力来优化 IT 运维。 IT 的领导者应该开始部署 AIOps，以优化当前的性能分析， 并在未来两到五年内将使用范围扩展到 IT 服务管理和自动化。 虽然 Gartner 创造了这个术语，但以我拙见，这还没达到标准。 他的定义以循环中的人为中心，以他的描述 AIOps 基本上是一种高级的大数据分析。 要解决 DevOps 困境，我们要定一个更高的目标。 那么，AIOps 应该是什么？ 我们先从它不应该是什么开始：一个对现有的运维系统的修饰，软件供应商将”以 AI 驱动”作为卖点。 这种情况已经发生了，当新的技术威胁到现有利益时，往往会发生这种情况。 仅仅向已有工具添加一个 API 是不够的，如果决策需要人为干预，那就不能算是 AIOps。