在之前的文章里，我更多的介绍了DevOps理论，但对于它的实践，可能还是有很多人比较模糊的。因此，我想深入分享下如何推动实践企业的DevOps体系。
DevOps有效地解决了开发，运营和IT服务团队之间的鸿沟。为了培养DevOps文化，使用正确的DevOps流程实施正确的DevOps工具至关重要。持续集成/持续交付/持续部署（CI / CD / CD）可以帮助开发人员和测试人员在结构化环境中更快，更安全地发布软件。去年，有超过50％的组织采用DevOps，持续集成（CI）和持续交付（CD）拥有成为软件开发过程中不可或缺的一部分。
你的企业可能正在着手进行自己的DevOps转换。我们将讨论CI / CD最佳实践，无论你在DevOps旅途中的何处，都可以帮助加速采用。
但是首先，让我们退后一步，为我们为什么首先实践DevOps做好准备。
CI/CD保证连续进行所有操作
持续集成和持续交付是指在自动化基础上，以较短的构建，配置，部署，测试，发布周期开发和交付软件的过程。简而言之，我们使用CI / CD来频繁且可预测地交付更高质量的软件。
CI实际上已经成为软件开发中无处不在的东西。因此，作为开发的基础，CI成为DevOps组织中的关键实践不足为奇。
CD没有像CI那样被广泛采用，但是是左移的关键。CD从CI的开发，构建，单元测试，静态代码分析（SCA）和静态分析安全性测试（SAST）开始。最终，将自动化扩展到功能，集成，性能和安全测试以及配置管理和部署。这些是自动化的关键领域-在DevOps上下文中，它们是必不可少的。
如果你不做CD，那么你的DevOps就做得不好。为什么？因为直到真正的用户开始访问应用程序之后，传统的IT运营才涉及到生产部署之后。如果你的软件交付管道中存在巨大的，自动化的鸿沟，你如何期望IT运营接受DevOps的文化？如果你仅进行CI，则可能是“ Developer Island”的唯一居住者。那里可能很晴朗，但肯定只有你自己一个人，与其他业务分开。
我知道你在想什么，这一切都很有道理，那么为什么CD自动化不是规范？答案很简单……这些东西可能很难，而且转型并非一蹴而就。它通常从CI开始，并且随着DevOps计划的成熟，CD是下一个合乎逻辑的步骤。当然，它不是出于必要而串行的，但这是我们经常看到的采用模式。
实际上，DevOps转换不仅不会在一夜之间发生，而且永远不会结束。这一切都是关于持续改进的，这意味着没有停滞不前。当你掌握了这些最佳做法的那一刻，就会出现新的做法，因为每天都会在提供软件方面做得更好。
这使我想到了持续进行所有操作的主题！当同时具有CI和CD自动化时，从工具的角度来看，你处于最佳位置。这是从问题检测到预防的观点转变，这意味着越来越早地进行测试-有效地缩短了测试周期，同时又保持了代码质量。结果？是更好的软件，更快地交付，缩短了最终用户和开发人员之间的反馈循环。
但是这不仅是工具。这也与人和实践有关–众所周知的DevOps三位一体。这意味着每个人都在可靠，可重复交付的高价值软件中承担着责任。这意味着在为发布选择故事时，文档团队也将加入工程团队。这意味着产品营销会在同一次会议上讨论这种功能的市场机会。这意味着产品经理会与分析师关系团队一起进行分析师询问。这意味着热情的客户会进行beta测试功能，并提供可以立即采取行动的有意义的反馈。这意味着甚至在发布功能之前，都要对销售进行培训，准备和准备好进行流水线生成。这意味着DevOps是业务的核心，从构思到开发，从营销到销售再到支持和服务的所有功能都将得到全面的信息和投资。
有效和全面的测量和监控
这样你就有了CI / CD策略。测量是DevOps转换中至关重要的且经常被忽略的步骤。是时候让你对自己的成就越来越惊奇了！（或者了解你的不足之处，DevOps就是诚实地接受和解决故障或提高效率的）。为了知道在持续改进的道路上下一步该拉什么杠杆。你正在以前所未有的速度交付代码！但是质量怎么样？测试失败了吗？生产不稳定吗？需要多少返工？你将不知道是否不追踪它。如果你希望随着时间的流逝加快自动化周期，那么实现和衡量DevOps最佳实践的成功至关重要。如果像许多人一样，在没有进行监视的情况下直接跳入DevOps旅程，那还不算太晚。考虑跟踪部署频率，更改交付时间，更改成功/失败率，平均恢复时间（MTTR）以及组织中通过的安全测试率，以保持对DevOps转换的关注。
8种CI / CD最佳实践，帮助你开始使用DevOps
1.采取“安全第一”的方针
在当今世界，漏洞继续给各种规模和能力的企业造成巨大的声誉和财务损失，在这个世界上，过分强调安全性是不可能的。由于CI / CD系统可以访问你的代码库和凭据，以在各种环境中进行部署，因此它通常是主要目标。回想一下臭名昭著的Uber漏洞，黑客可以访问嵌入在GitHub软件存储库中的AWS凭证-窃取5700万用户和60万驱动程序的个人信息 。然后，Uber付费以掩盖它，但这是另一回事。出于自动化目的，将凭据存储在私有存储库中并不少见。因此，你应该考虑隔离CI / CD系统，并将其放置在安全的内部网络中。VPN，强大的两因素身份验证以及身份和访问管理系统将帮助你实施“最小特权原则”并限制受到威胁的可能性。例如，将你的代理容器化并将其放置在安全网络上。此外，你还应确保从始至终将安全性纳入开发过程。这通常称为DevSecOps。
2.评估你的组织是否准备好使用微服务架构
为了有效实施DevOps，微服务架构是最好的方法。但是，重新架构现有应用程序可能是一项艰巨的任务，并且你可以考虑采用增量方法来维护关键任务系统并围绕其构建新架构。这将帮助你逐步用新体系结构替换旧系统。
3.实施跟踪和版本控制工具
诸如Jira和Bugzilla之类的工具 可以帮助你更好地了解软件的进度，并轻松地与分布式团队协作。你还需要一个类似Git的版本控制系统，它可以为你的团队创建“单一事实来源”，允许跟踪代码库中的更改，并且在需要回滚时可以节省生命。通过使团队能够协作并将更改集成到共享存储库中，GitOps可以显着提高你的MTTR。
4.每天提交，减少分支
减少分支的目的是要花更多的时间在开发上，而花更少的时间在版本控制上。但是，为了充分利用GitOps，开发人员应至少每天一次直接提交到主分支或合并其本地分支中的更改。这将迫使开发人员处理更小，更小规模的集成难题，而不是试图在发布之前尝试将许多分支合并到主干中时发生的大规模集成难题（以及相关的返工）。
5.只建一次
消除了多次构建源代码的任何做法。即使必须构建，打包或捆绑软件，你也应该只执行一次该步骤并升级二进制文件。大多数成功的CI实施都将构建过程作为CI / CD周期的第一步，以将软件打包在干净的环境中。这消除了监督，并减少了以后随时引入和/或遗漏错误的机会。此外，每次都应对生成的工件进行版本控制并将其上载到Git，以便每当拉取它时，构建都不会更改。
6.确定首先要执行哪些流程和测试
尽管采用渐进式自动化方法听起来不错，但是从手动流程过渡到自动化流程的组织通常发现很难确定首先要自动化的流程。例如，首先自动化编译代码的过程是有益的。由于开发人员需要每天提交代码，因此进行自动烟雾测试很有意义。单元测试通常首先自动进行，以减少开发人员的工作量。
因此，你可以自动化功能测试，然后进行UI测试。功能测试通常不需要自动化脚本中的频繁更新，这与UI测试不同，而UI测试具有更频繁的更改。主要思想是考虑所有可能的依赖关系并评估其影响，以合理地确定自动化的优先级。
7.频繁发布
仅当软件处于可发布状态且你已经在生产环境中进行了测试时，才可能发布频繁版本。这就是为什么最佳实践是在发布之前添加一个与生产环境非常相似的部署阶段的原因。一些发行最佳实践包括：
- 单元部署。释放一部分用户，使用该基础进行测试，如果成功，则将其扩展到更广泛的人群中；如果不成功，则将其滚动回进行迭代。
- 预部署。你将从两个相同的生产环境开始。一种是现场生产。另一个空闲。推出新版本时，更改将推送到空闲环境。然后他们切换–包含新版本的环境变为实时环境。如果出现问题，你可以立即回滚到另一个环境（不包含新版本的环境）。如果一切顺利，环境将再次达到平价。
- A / B测试。 A / B测试的风格类似于-但不要与预部署混淆。A / B测试是一种测试应用程序中功能（例如可用性）的方法。性能更好的变种胜出。这不是发布方法。
8.使用按需测试环境
你应该考虑在容器中运行测试，因为这种方法使质量保证团队可以减少环境变量的数量以及开发和生产环境之间存在的更改。使用这种短暂测试环境的主要优点是它们为你的CI / CD周期增加了灵活性。QA团队不必从CI服务器提取构建并将其安装在单独的测试环境中。相反，它可以针对容器映像运行测试。旋转容器（它们没有单独的安装或配置要求）并在不需要时销毁它们也容易得多。
从哪里开始？
DevOps或CI / CD最佳实践的主要目标是自动化构建，测试和发布软件的过程。这意味着你将需要访问DevOps工具，这些工具可帮助你简化自动化并更好地了解软件的进度。此外，应该有一种机制可以 在整个软件交付生命周期中跟踪DevOps性能指标，并在发行或部署中出现问题时发出警报以快速恢复。
即使在已经进行了一段时间的DevOps转换工作的组织中，决定实施哪些DevOps工具以及首先在何处进行投资也可能导致“分析瘫痪”。之后会分享更多的DevOps工具，敬请关注。
如果有想了解的运维工具或者运维开发的技术栈，可以留言备注，我尽量满足大家。谢谢关注和支持。
