克服 DevOps 的 5 大痛点

DevOps 是一个相对较新的概念，被越来越多的企业采用，它打破了开发、质量保证 （QA） 和 IT 运营之间的障碍，从而实现了更快速、更流畅的软件开发生命周期 （SDLC）。然而，几乎可以肯定的是，存在许多组织和技术问题，这些问题会使您在 DevOps 中的体验不如您想要的无缝（而且更令人沮丧......

我们与 DevOps 的讨论广泛而多样，但我们确实听到了一些反复出现的痛点。您认同其中的几个？

1） “测试太费力了！” – 手动测试

成功的 DevOps 的一个关键要素是持续集成/交付，它依赖于自动化测试，但许多组织仍然主要依赖手动测试流程。

手动测试也更容易出错，因此系统稳定性会受到影响。这会导致以后的痛苦，因为顺畅的 DevOps SDLC 流程被需要实施计划外修复所打断。

防止集成失败代码的自动化测试工具是必不可少的。这也导致开发人员承担了更多的测试和 QA 责任。TestComplete 是一个不错的选择，它为 Web、移动和桌面软件提供全面的自动化测试。 对于仅使用 Web UI 进行自动化测试，Selenium 也是一个流行的选项。

在容器化环境（例如 Docker）中运行时，您的 CI/CD 管道将成为构建软件容器和运行整个测试范围的重心。在这里，我们推荐 drone.io 或 codefresh 等工具。

2） “它在那里工作，但在这里不起作用！” – 不一致的环境配置

在理想情况下，所有环境（开发、测试和生产）的配置都相似，主要在规模上有所不同。这使代码能够在环境之间无缝移动，直到投入生产，而不会产生戏剧性。

不幸的是，这还不是世界的运作方式，环境之间的不一致会导致代码破解。这在很大程度上阻碍了支撑 DevOps 的“无缝和快速”SDLC 概念。

与 DevOps 中的许多问题一样，Docker 等软件容器就是补救措施。由于容器化软件是完全独立的，包括所有依赖项，因此无论它在什么环境中运行，它都应该以相同的方式运行。

3） “行动一直在拖慢我们的速度！– 开发和运营之间的目标冲突

也许组织转向 DevOps 工作方式的最大挑战是开发和运营历来相互竞争的角色。从本质上讲，开发喜欢改变事物，而运维喜欢保持稳定。

如果开发和运营只是放在一个团队中，那么文化冲突是不可避免的。相反，管理层需要将速度、质量和可靠性的共同目标传授给这两个群体。为了“在中间相遇”，开发人员需要承担更多的责任（这样他们就不能只是“把代码扔过栅栏”给 QA），而运维人员需要相信上游发生的事情，并接受更快的发布周转。

4） “我们不可能这么快就完成 SDLC 的每一步！” – 非敏捷组织

DevOps 和敏捷虽然是不同的方法，但有很多共同点。它们之间的关键交叉是，对于开发组织来说，实践敏捷开发对于开发运营方式的成功几乎是必不可少的。瀑布流太慢了。

“在你能走路之前先跑”很重要。任何组织变革，包括 DevOps 和敏捷开发，都是一项艰巨的任务，因此公司需要现实地看待他们改变长期工作方式的速度。特别值得注意的是，许多审批和签字流程需要消除和/或整合，以避免成为瓶颈。对于开发人员来说，在尝试全面的 DevOps 组织重组之前完善敏捷可能是有意义的。

5） “一切都移动得太快了，以至于无法遵循适当的安全流程！” – 流程和容器安全

如果等到流程结束，就在进入生产环境之前，才通过传统的安全门和控制点提交结果，那么安全性可能会成为 DevOps 的障碍。这与前面关于手动测试的观点相呼应——如果组织依赖手动测试，则测试（包括与安全相关的测试）将不可避免地被跳过或匆忙满足更短的可用测试时间，从而导致安全漏洞。因此，与其他所有事情一样，安全性也必须在 DevOps 环境中实现自动化，并尽早集成到流程中。

Docker 容器就是一个很好的例子。容器通常是从存储在注册表中的基础映像构建或实例化的。开发人员提取映像，然后按原样使用或进一步开发，然后通常构建自己的映像。此生命周期可能非常快，尤其是在完整的 CI/CD 环境中，开发人员每次提交代码都会生成一个新映像。传统的手动安全检查根本无法每天处理如此大量的新代码涌入。

自动化流程 - 在每个阶段扫描镜像漏洞，确保在整个过程中保持镜像完整性，实施允许运行镜像的安全策略，并提供对流程的全面可见性，允许安全团队对其进行监控和审计 - 是满足安全要求的唯一方法，而不会影响 DevOps 速度或更改其方法。

此外，将此类自动化映像保障流程连接到您现有的 CI/CD 管道（例如 Jenkins、GO-CD drone.io 等）使您能够同时享受两个世界的快速开发，同时您的安全策略作为流程的一部分实施。Aqua 自己的持续形象保证正是这样做的。