linuxea: 有趣的devops 并不是每个公司都适合devops，但这并不能说devops不好，其中对人员的要求和新技术的引入而引起的问题远比现实复杂。devops在当下不是一个难以实现的问题，但在很多时候它出现引起了很多误解。？？9012年后，许多公司对devops热衷，寻求不断被放大。我不断的在听到大家谈论devops，但似乎与原本的初衷并不一致。devops定义是改善开发到生产周期，缩短开发周期，通过devops更快的部署 ，通常而言，如下代码所示：1/6 sonarqube: stage: code-check script: - sonarqube - date 2/6 code_quality: <<: *job_docker_group script: - code_quality - date 2/6 code_quality_Increment: <<: *job_docker_group script: - code_quality_Increment - date # Static Application Security Testing 3/6 SAST: <<: *job_docker_group script: - SAST - date 4/6 dependency-scanning: <<: *job_docker_group script: - dependency_scanning - date 5/6 dependency-check: stage: code-check script: - dependency_check - date 6/6 license_management: <<: *job_docker_group script: - license_management - date # Dynamic Application Security Testing 1/2 DAST_ZAP_JSON: <<: *zap_docker_group script: - DAST_ZAP_JSON - date 2/2 DAST_ZAP_HTML: <<: *zap_docker_group script: - DAST_ZAP_HTML - date deploy: stage: deploy-test environment: name: staging url: https://www.linuxea.com only: - master script:当然，这只是部分信息。除了开发过程外i，能够自动处理的可控范围内的问题，不会影响到用户，并且能够进行有效且高质量的监控。。现实情况：手动测试或者不测试，亦或者单独的伪自动化测试监控没有导向的事情不改善工作流程继续在迭代中执行上述操作等并尝试在出现火灾的时候进行救火devops均在解决这些等问题，从而来完成更高质量的的产品。最终的目的是提供生产力。在此基础上，仍然需要与各部门良好的协作和沟通，以及对系统和产品的熟悉，缩短开发周期和质量测试。这些都包含在自动化中。devops职位的分析在招聘网站的devops这些招聘信息与devops有很直接的关系吗？后端架构设计和研发平台构建devops需要建设CMDB,发布，部署，监控，日志系统，并且需要服务优化，缓存，存储集群设计和落地？CMDB建设，包含部署设计，监控，优化等，在我理解中，有运维开发和资深运维来做。这不是自动化运维的职责内容吗？其中甚至没有提到持续集成和持续交付。看到这里，你大致可以明白，devops信息中实际需要运维开发，或者资深运维工程师，或者云运维工程师，在或者自动化运维工程师，甚至没有考虑到需要持续集成和持续交付。很明显，他们理解错了。如果认为devops就是开发和运维，那是错误的，devops在开发运维之上。当谈论到devops时候，往往意味着：开发和运营的密切关系至少应该是熟悉彼此，这样开发知道他们正在编写的系统，并和运维部署的代码。了解这些才能够在不影响系统的情况下进行调整出更好的方式。在短时间内开发，并且快速部署，在出错后尽快修复这其中就包含了自动化，自动化包含测试和运维，并且最终放在管道中运行。但是这些取决于基础架构是否完善。从哪里开始偏离了？devops方法是抽象和复杂的概念，它不是一个工具那么简单。采用什么工具和技能，并将其命名为devops。这些工具使用和所需的技能附加到职位描述。现在devops一词开始描述知道如何进行开发和自动化的人。要知道devops不是一件事情，dev 同 ops，而不是dev和ops。在更多时候devops是一个团队在做的事情，并不是某一个人做的。不要采用流行的一个单词，而是背后的流程与方法的实际理念。不管如何，我们是将产品最终交付到生产。另外，不要认为使用了cmdb,使用了容器技术，使用了kubernetes,ansible，就认为在做devops。延伸阅读Devops

linuxea: 连续测试的5个要素 我们在做持续集成的时候，或者说是在做连续测试的时候，目的是为了让代码健康，健壮有效。其中，持续交付CD和持续部署能够让运维人员快速的随时随地的将代码推送到线上。而随着devops推进中，生产环境中开发人员需要自己解决代码bug问题，开发人员需要立即知道他们正在进行修改的代码会有那些问题。连续测试唯一保证代码良好的方式就是测试他们，这也是我们进行持续测试原因。在进行这种转变或者参与的团队中，性能测试和自动化测试从早先的测试工作转变为促进测试到开发人员个人测试，维持提供支持和协作。每个人都构建他们的代码，每个人也进行不断的测试自己的代码。但持续测试成为新的常态中。测试将变得更加灵活，测试人员或者开发人员配置了功能测试和测试工具，并且能够对任何新的修改或者更新进行单元测试。并且随测试到预生产环节，在到生产环节，甚至到上线后的监控等。团体只需要最短的时间来怎么代码的可用性并且可以接收新流量。连续测试的过程中会出现很多未曾出现的问题，必然是充满挑战。我们必须确保如下几点：尽早的定义好测试我们需要有明确的需求来定制测试，并且使用行为驱动开发BDD,验收测试驱动开发ATDD和使用工具基于模型的测试，以便于清晰的记录和传达所有需求。为了避免浪费不必要的时间和延误。至少需要明确需求后定义测试用例和测试脚本，以便于在生产的每个阶段都能够进行连续测试代码。优化测试流程和测试覆盖率仅测试需要测试的内容，删除不必要的重复项，对时间较久的测试环节采用旁路测试，在不影响管道运行的情况下精简。测试最大的覆盖范围就需要可视化的模型。早期和后期测试在开发周期早期准备，开发人员/测试人员准备好测试工具和用例或者脚本，包括但不局限自动化测试，功能测试，性能测试，监控，安全测试等。必须满足易于开发，方便使用和采用。生产环境中仍然需要后期跟踪，包括代码检测，持续监控，用户监控，蓝绿发布等。环境一致性提供虚拟化测试环境的能力对于实现持续测试至关重要。通过一些列工具ci/cd，在被需要提供的情况下，提供完整的测试环境。这些环境中应该包括按需测试的数据，以确保团队可以使用与生产环境中类似的参加执行全面测试。这些环境的构建是暂时性的。在使用完成后就会被释放。获取真实的测试数据如果不能够获取真是的测试数据可能会导致应用程序发布更新出现延迟。新的更新大多建立在旧的代码智商，要尽可能的接近应用程序在生产中遇到的内容。如果缺乏某些特征，则测试不太可能主动发现需要潜在问题和bug。如何提取这些数据，也是一个值得讨论的话题。对于这些生产中的真实数据，通常来说都需要限制。在被采用的时候屏蔽一些敏感信息，同时还要保持生产数据测试所需的特性。最后持续交付和持续测试需要时间才能成功实施。在团队中，基于数据的持续反馈和正确的工具集可以较少不必要的麻烦。其他阅读Devopsdocker

linuxea: 自动化测试和连续测试有何差异？ 测试团队一直在自动化测试上面花费的大量的时间和尽力。这样的开销似乎并不符合预期。另外，应用程序的架构，开发的使用方式也在不断的发生变化，这样一来也增加了测试的复杂性和软件故障。鉴于当下应用程序交付的复杂性和交付速度的增加，软件测试人员如何辅助控制业务风险？--进入连续测试。连续测试？？持续测试是将自动化测试作为软件交付管道的一部分的执行过程。便于尽快获得与软件发布相关业务风险的反馈。自动化测试皆在生成一个应用程序定义好或相关的"通过"/"失败"的数据点。另外，持续测试侧重于业务风险，并提供有关软件是否可以继续发布的“见解”。要实现上述，我们必须从“我们是否进行测试某个功能？”我们是否进行了测试？“转到”即将发布的应用程序的风险是否在可接受的范围内。“为什么需要持续测试？？当下的测试内容更多，使用传统工具和方法作用于自动化测试上实现更困难。1, 应用程序体现结构分散和复杂，包括云，API，微服务等，并且这些在业务中通常都是不同的协议和技术组合。2，对于Devops中的持续交付中，更多的应用程序从每周发布一两次，到每天发布无数次。因此，用于测试设计，维护和执行时间也会大大缩小。3，软件程序故障也就是业务故障，如果影响到用户体验，即使看起来微不足道的小故障也会产生不可预计的后果。因此，与应用相关的风险仍然是非技术性业务支撑团队需要关注的点。自动化测试与连续测试不同？连续测试与自动化测试最大的区别可分为：风险，广度，时间风险在当下企业中，应用程序涉及到的业务范畴非常广，例如：一个购物商城不单单只有我们看到的货架种类，推荐消费等，还有积分处理，账单处理，物流信息等。向用户提供越多的功能同时也意味着的潜在故障点的数量，种类和复杂性。如果测试用例中没有考虑到业务风险，那么测试结果将无法评估风险中所需的洞察力。如果测试皆在提供产品是否实现需求的低层次信息，而不是评估发布的版本是否存在高风险。如果没有，那么你的测试与业务风险不一致。在进行低粒度测试的同时仍然需要更多的措施来评估或者阻止高风险的发生。广度即使一些微不足道的故障，也会带来不必要的麻烦。特别是在用户体验差强人意的时候，亦或者某些部分出现问题的时候。单单从单元测试和UI测试通过并不是说这些修改会影响到用户整体体验。为了更好的保护用户的最终体验，需要足够广泛的测试来检测应用程序更改没有在无意中影响到用户所依赖的功能。时间当下，软件迭代的速度也成为了许多团队的竞争优势，很多都在转向敏捷和devops以加速其交付流程。当自动化测试出现，测试根据瀑布式开发过程构建和更新。这种条件下，在测试没有完成之前，当下进度将会暂停。这并不敏捷。测试必然需要和开发并行开始，否则，产品不太可能在极短的时间内完成迭代，并进行测试宣告完成。如果已经开始devops并且正在执行持续交付，则可能每个小时或更频繁的发布应用软件。这种情况下，每个阶段的过程反馈不能只是快速，几乎是瞬间完成的。如果质量不是应用程序首要考虑因素(例如：生产中发生缺陷影响较小)，则在每个版本运行一些单元测试和冒烟测试就足够了。但是，如果企业希望最大限度的降低故障，则需要一些方法来实现必要的风险覆盖水平并快速测试。对于测试，有几个重要的影响：测试必须成为开发过程的一部分，而不是在开发完成时处理”尿不湿“的任务几乎在使用相关功能后，测试必须准备好并运行团队必须有办法确定在交付管道中的不同阶段进行正确有效的测试，如：烟雾测试，集成后的API和消息层测试，系统级别的端对端测试等等。每组测试必须足够快的执行，以避免软件交付的某个阶段产生瓶颈需要一种稳定的测试环境方法来避免频繁更改造成的大量报警自动化测试不等于连续测试自动化测试不等于连续测试，连续测试大于自动化测试。即使是使用传统测试自动化早已成熟的团结，当采用交付方法时候，也会出现很多问题，比如：无法足够快或足够频繁的创建和执行测试持续应用程序更改会导致大量的错误报告，这些大多可能都是误报，需要看似永无止境的测试维护量无法即时了解发布版本是否存在风险太大而无法通过交付管道最后，我想说没有任何工具或者技术可以立即做好连续测试，与敏捷和Devops一样，连续测试需要在整个人员，流程，技术方面进行变革。然而，当目前技术不能够完成任务，尝试做一些人员和流程的变化。这仍然可能会导致失败。其他阅读Devopsdocker

linuxea: 持续集成的7个要素 大多数公司认为他们已经在使用持续集成(CI)，但当谈到是否遵循CI的关键实践时，如：运行测试来验证每个构件，其中许多并没有。今天我们来讨论如下几点：1，我们是否每天更改或至少每天多次构建我们的应用程序代码？2，我们是否有意识到避免长时间在分支开发代码功能？3，我们是否优先考虑修改构件中出现的已知故障而并非进行新的迭代？如果上述三个问题的答案是否定的，那么你做的并不是真正意义上CI。持续交付(CD)是Devops的基础，他建立在持续集成基础之上，因此，在使用CD和Devops真正取得有效进展之前，必须正确实施CI。换句话说，我们必须解决这些问题才能在后面进行飞跃的提升。掌握持续集成的步骤为了实现业务目的，以下是必须采用的七种实践来掌握CI1.自动化构建在实施持续集成之前，开发人员在桌面进行本地构建，或者让构建人员手动集成代码。再者通过手动撸一个烦躁的步骤。但是让人疑惑的是，这种“CI”形式的确存在。简单来讲，持续集成的构建应该运行一个集中管理的控制器单元上，能够完全无人值守的运行并自动化，以便于相同的每次输入都会产生相同的输出结果。2.尽可能频繁的进行构建在测试环境中每天都会进行大量的构建工作，理想情况下除拉取外，合并，提交时候都会触发每次更改的构建，每次提交构建可以在引入错误后立即找出错误，在这样的情况下有利于修复bug持续集成(整合)中，“持续”尽可能的采用字面意思。通常，在一个公司中，当讨论到构建频率时，答案如下：1，通过某些按钮触发构建，每周X次2，每天晚上都进行构建，每周一次3，每天在某个时间段进行构建一次这些并不是真正的持续构建，他们可能是集中管理一台管理服务器，自动构建或者预订构建。但这些不提供持续集成的好处。倘若现在由于某些原因，10个开发人员在两天内进行了多达30多次代码提交，对于出现的BUG则可能需要对这些工作排序并且找出更正的原因。这样情况下生产力将会下降。3.经常提交或合并到主线在已有CI的团队中可能在每次更改时或每天至少一次对主线或者主要部分代码进行合并。例如：长时间维护一个功能分支，则无法频繁的确验证集成更改。如果分支很长一段时间没有进行合并验证，当合并时大概率会出现冲突或者错误需要解决，这延迟了项目进度。4.快速构建假如你的测试环境中的CI，每次构建在5-10分钟完成是正常的。如果构建需要更长的时间（有的构建长达三四个小时），不仅会延迟进度，也无法得到有价值的反馈。花时间优化构建。这过程中可能需要分解CI构建过程，或者组件，这些与团队密切相关，而后将整个集成应用程序的验证作为整个开发过程中的单独步骤来做。5.验证构建CI中包括验证更改和生成的报告。这种测试应该是整个构建过程的一部分，如果你是唯一验证仅基于确认软件编译结果，那这并不是真正的实践CI。大多数实践CI团队都包括CI构建中的代码扫描和单元测试，以及后续的黑白盒等。6.在类似生产环境中验证成熟的CI可确保开发，测试和预生成环境之间的一致性。最成熟的方案莫过于虚拟机和容器技术，服务器虚拟化和其他技术来确保在类似的生产环境进行验证，并且当在集成这些更改之后，就可以降低在预生产和生产中出现错误的风险。7.立即修复崩溃的构建如上所述，团队发现并快速解决问题以便他们不会向下推进也至关重要。使用CI，可以建立流程，在这些流程中，构建可以持续验证和提交，如果出现问题，则更容易修复。如果忽略了错误的构建，则问题在此后更难以找到并修复，但更糟的是这背后的文化。CI是基于质量优先的方法，如果构建中断，停止并修复。从长远来看，得益于每个参与的人。最后的文化问题这些看起来似乎很简单，但是当结合起来后，结果必然是显著的。不能说不遵循这几条的团队可能会在定期提供构建功能就会出现问题。但是如果 持续集成推进失败，团队成员将会恢复此前的方式。不仅存在流程问题，也存在文化问题，这也是多数团队陷入困境的原因之一。团队必须改变工作的方式并且确保他们的思维方式一致。CI对团队有很多好处，但不要忘记CI本身是为了正面发现问题，解决问题并不是通过CI来避免和消除问题。持续集成构建一个系统，开发人员可以快速发现BUG，有利于及早，快速的找到问题并修复。持续集成是真正的Devops转型的基本要素之一，众所周知，这是许多当前 团队的首要任务，真正使用它是为了跟上现代商业需求至关重要的一小节。

linuxea: 向大众解释devops定义 如果你问一个普通人，“DevOps对你意味着什么？” 对方很大可能是茫然的。还有一些人并没有直接参与，而是模糊地意识到DevOps是一个概念。虽然模糊的理解总比没有好，但它留下了误解和错误信息的空间，从长远来看这可能是个问题。DevOps的准确定义是必要的。如何为非技术受众提供DevOps的准确定义？长期DevOps从业者Alex Honor回应了早期的敏捷软件开发原则，他创造了“人们过度使用工具”这一短语。这个口头禅提供了一个简单的DevOps优先级列表，因此提供了一个有用的框架，可以轻松理解DevOps的。从大众开始每个人都喜欢一个好的组织结构图，并讨论DevOps团队如何组织，是了解DevOps如何在实践中发挥作用的有用方法。DevOps非常关注传统上独立的开发和运营部门的桥接，但这不仅仅是增加团队之间的协作。在传统设置中，开发人员构建应用程序并在必要时修复它们，而运营团队则负责维护，支持和监视这些应用程序。在DevOps中，划分这两个世界的墙就消失了。但这不仅仅是让开发和运营团队更紧密地合作 - 而是创建一个开发人员和工程师在产品生命周期的每个阶段彼此协同工作的环境。换句话说，dev和ops之间应该没有分离，只是一个统一的DevOps团队。通过强调人员因素并将DevOps团队结构与更传统的安排进行对比，可以更容易地看到DevOps在现实世界中的表现。对于技术水平较低的受众来说，揭开DevOps的神秘色彩，这是一个很好的起点。持续改进流程当投入实践时，DevOps应该比更传统的软件工程方法更快，更高效，更可靠 - 一旦组织结构到位，这些好处就可以通过创新的DevOps流程实现。在传统的开发和操作中，手动操作任务的习惯意味着减慢进程并妨碍高频部署。但是在基于作为代码的基础架构的DevOps流程中，团队可以自动化资源的提供和管理。例如，承担配置服务器资源的任务。过去，开发人员会通过电子邮件向基础架构团队发送电子邮件(或者其他即时通讯)，并要求在特定配置中提供一组特定资源。然后，基础架构团队中的某个人会在最终部署服务器之前查看文档并遵循任务清单。在DevOps流程中，开发人员和基础架构工程师不仅在同一个团队中彼此协同工作，他们还通过基础架构作为代码（IAC）实施流程。在IAC的环境中，通过代码自动配置IT资源，因此开发人员只需单击按钮即可手动配置服务器。然后，所需的基础架构自动执行，加速整个流程，并为DevOps团队提供更频繁，更高效的部署方式。通过描述IAC实现的自动化流程，DevOps与更传统的实践之间的差异变得更加清晰。对于技术含量较低的员工，这种解释为DevOps团队的日常工作提供了一些急需的背景。工具技术及自动化和管理方面带来的好处是DevOps的关键驱动因素。云计算和虚拟化的成熟，特别是基础架构即服务（IaaS）的出现，提供了DevOps所需的灵活性和速度。借助IaaS，可以立即为高度定制和不断变化的IT需求提供计算资源，而无需使用本地硬件或手动配置。这反过来又使基础设施成为上面详述的代码（IaC）流程，以及DevOps团队运行所需的自动化水平。因此，IaaS和IAC形式的云计算奠定了DevOps的技术基础。这是最重要的东西，但那些非技术人员可能真正听说过的那些品牌工具呢？Docker，Kubernetes，GitHub/GitLab，Jenkins，Travis CI ......类似这个列表还有很多，但这些对于DevOps的核心概念有多重要？可以说，不是很好。虽然容器化，源代码控制和持续集成工具都可以在DevOps上下文中执行非常重要的角色，但它们很难定义DevOps本身的功能。Puppet和Chef等连续配置自动化解决方案更直接在IAC保护伞下实现，可实现数据中心资源的自动配置和扩展。但与其他设备一样，这些工具在更传统的设置中同样适用于每一个公司。从这个意义上说，没有“DevOps工具”这样的东西，只有可以在DevOps组织中用于DevOps进程的工具。这就是如何使用它们真正重要的。因此，当为新手提供DevOps的定义时，不要陷入简单的工具列表陷阱。DevOps更多的是关于人员，组织和流程。虽然它非常依赖于IaaS和IAC技术，但DevOps团队使用的许多工具或多或少都是偶然的。DevOps的提醒DevOps的最终目标不仅仅是统一开发和运营，而是缩短开发周期，更频繁的部署，更高质量的产品和满足客户。更直接的是，DevOps的最终目标不仅仅是说“我们做DevOps”，而是提高生产力并使业务更有利可图。如阿里巴巴，腾讯，谷歌，亚马逊。这些公司的成功取决于他们每天，甚至每小时多次部署新软件的能力。或许他们不同意该术语的精确定义，但他们所同意的是DevOps作为一套统一的软件工程实践，对其盈利能力至关重要。随着DevOps在过去几年中出现的广泛争议达成共识，DevOps的缺乏定义将随着其文化不断演变而变得不那么重要。与此同时，好消息是DevOps背后的重要思想也是向非技术受众解释最直接的。通过首先将DevOps打破，处理第二个和第三个工具，可以准确且相对简单地定义DevOps。DevOps基本上是关于人，开发人员和工程师如何组织自己，并作为一个统一的团队工作，以更快地提供更好的产品。在这个结构的基础上构建了DevOps流程，重点关注自动化和创新工具 - 始终在核心DevOps原则和实践的背景下。

linuxea: devops起源 devops在发展已经有近10年的历史，并且发展迅猛，在2016年的RightScale报告中估计有70％的中小企业采用DevOps方法。从那时起，每个迹象都表明百分比有所增加。现在我们重新审视DevOps方法的起源 - 甚至是术语本身 - 进行有一一回忆。2007在2007年之前，一系列情况汇集在一起，最终会产生我们今天所知的DevOps。“精益制造”已经成为一套制造业的最佳实践。通常被称为“丰田制造方法”，精益制造致力于在整个生产车间进行工艺优化。（丰田领导者最初的灵感来自福特汽车公司推出的巧妙装配线方法。）“持续改进”是精益制造的口号，从业者不断评估以下方式：保持库存至少。精益生产意味着手头的库存最少：原材料（用于生产商品的材料）和成品库存（等待分配到订单和/或运输的已完成产品）。最小化订单队列。理想情况下，收到的订单应立即进入履行模式。精益生产的关键指标始终是“发货顺序”时间。最大限度地提高制造过程的效率。流程重新设计和改进的自动化将结合到尽快生产货物的目标。沿途的每个操作站（切割，焊接，组装，测试等）都被评估为效率低下。在IT领域，应用程序开发的传统瀑布方法已经让位于敏捷等快速迭代方法。“速度”是运作的关键，即使在追求快速开发和部署时偶尔会损害质量输出。同样，在IT的运营和基础设施方面，云计算，特别是基础架构即服务（IaaS）和平台即服务（PaaS）正在成为他们自己的成熟服务产品。最后，一组刚刚起步的工具被归类为“持续集成（CI）”工具。CI工具的概念由Grady Brooch在1991年的Brooch Method中诞生并打上了品牌。2007-2008开发和运营合作的案例比利时顾问，项目经理和敏捷实践者Patrick Debois接受了比利时政府部门的任务，帮助他们进行数据中心迁移。特别是，他的角色是就绪测试。他的职责要求他跨越应用程序开发团队和运营团队（服务器，数据库网络）之间的活动和关系。这种过度到多个团队之间的应用协助方法和基础设施之间缺少凝聚力 - 为Debois埋下了不满的种子。他渴望更好的方式很快就会让他采取行动。2008年，在多伦多的敏捷会议上，Andrew Schafer发布了一项邀请，以审议一个特设的“羽毛之鸟”会议，讨论“敏捷基础设施”这一主题。只有一个人出席讨论这个话题：Patrick Debois。他们与其他人讨论和分享想法提出了“敏捷系统管理”的概念。同年，Debois和Shafer在Google上成立了一个敏捷系统管理员小组，但收效甚微。2010：DevOps在美国随着成长，参与者增多，Devopsdays会议首次在美国山景城举行，2013年：'凤凰计划'对于我们中的许多人来说，DevOps历史上另一个值得注意的时刻是由Gene Kim，Kevin Behr和George Spafford撰写的“凤凰计划”一书的出版。这部虚构的小说讲述了一个IT经理陷入看似无望的局面的故事，因为他负责打造一项关键任务电子商务开发项目。他的神秘导师，一个沉浸在精益制造学科中的董事会成员，指导主角进入IT和应用程序开发的新思维方式，并在此过程中介绍DevOps的概念。DevOps将DevOps描述为一个旅程，或者可能是一个愿望，而不是定义目的地是合理的。与精益制造一样，DevOps寻求持续改进，寻求更高的产量，更高的效率甚至持续部署。支持DevOps的自动化工具不断发展。自DevOps成立以来，在过去十年中取得了很大成就，预计未来及以后会有更多。