即使在今天，DevOps仍然是大多数优化管道的核心。持续交付变成了规范，而不是要实现的目标。应用的开发是迭代的，新的更新被推送到云端，用zero down代替部分或整个环境。因为有了DevOps，即使是大型的多部分更新也更加易于管理。
然而，就结合软件开发和IT运维而言，DevOps这个术语并非唯一。它有着许多变体和子类型——以及概念的修改——它们被不同的软件开发团队广泛采用。对于许多人来说，DevOps为跨团队的良好流程（包括自动化）奠定了基础。但是为了改进方法论，团队可以采用下面的一种或多种主要方法——因为大多数被考虑的方法都是为了实现“更好的”DevOps文化而进行的调整。
那么，其他需要考虑的“Ops”是什么呢？它们与DevOps相比如何？
DevOps vs. NoOps
NoOps背后的方法是以一种不需要内部团队进行操作的方式来自动化IT基础设施。在这种方法中，操作团队的所有维护和类似任务都是完全自动化的，这意味着不需要手动干预过程。NoOps的意图与DevOps相似，因为它专注于完全自动化工具和基础设施，以改进软件部署。然而，它较少关注敏捷和流程管理，因为它的工作假设是开发人员拥有自动化的工具和流程，他们不需要知道如何使用它们的具体细节。
为了实现这一目标，该方法的一部分“减轻”了开发人员的所有基础设施顾虑，从而从云计算中获得更多价值。与DevOps一样，这是为了防止他们执行耗时的任务，这些任务涉及与IT运营团队就基础架构问题进行的所有交互。
在NoOps中，开发人员不需要为资源及其分布操心，因为这正是云的作用所在。在产品完成后，云提供商还将运行进一步的运维、监视和维护。NoOps模型使用持续集成技术，允许开发人员只专注于应用程序开发。
当组织开始选择NoOps时，许多人认为这将是DevOps的终结。但在现实中，DevOps已经发展了，NoOps并不是一个万无一失的过程，尽管它加快了部署过程。我要警告不要孤立地采用NoOps，因为它缺乏流程和团队管理，而开放的沟通通常会带来更好的结果和生产力。
DevOps vs. DevSecOps
从这两种方法的名称来看，很容易相信这两种方法有一个主要区别：将安全性集成到管道中。然而，我认为它们是同一个概念。如果DevOps是“在制品”（WIP）的减少，那么自然的进展是在管道中进一步提高安全性。如果您需要提升或提升组织对多个因素的安全关注，那么这种方法非常有用。
DevSecOps采用了传统的DevOps方法，并在工作流程中添加了额外的安全检查、代码验证和深入测试。DevSecOps从流程的一开始就集成了安全性，而不是在周期结束时让安全性成为一个问题。
两者有相似之处，也有相似的主要优势。DevOps和DevSecOps都允许CI/CD管道实现更大的自动化。只要速度和交付处于优先级列表的顶端，DevOps和DevSecOps就会继续在工作流的不同部分利用自动化。
两者还依赖于在沟通和协作的帮助下持续运行的过程。团队沟通是保持敏捷性和交付速度的关键部分。开发人员、安全专家和运维人员之间的协作也至关重要。
DevOps vs. GitOps
GitOps是DevOps的另一个广受欢迎的分支，在过去的一年里得到了广泛的关注。顾名思义，GitOps更关注于使用Git作为一种方法来自动化其余的持续交付管道。有了Git作为唯一的数据源，从长远来看，GitOps被认为更健壮、更可管理。
可以说，实施GitOps有一些潜在的优势。对于初学者来说，每个开发人员都熟悉Git和pull请求，因此集成GitOps作为一种加快交付速度的方法是一种简单的过程，不需要掌握复杂的工具，也不需要总是对工作流进行更改。
GitOps还得到了市场上一些最好的云服务的支持。像AWS CodePipeline和AWS CodeBuild这样的工具是为使用Git工具而设计的，这意味着自动构建更新、测试错误、审查代码以及将更新推送到生产环境的过程非常容易实现。
GitOps还提供了一套详细的审计工具，并能够随时回滚更新。这是因为Git是每次更新的主要来源，这意味着整个管道也可以依赖Git日志来进行简单地审计。然而，由于Git是唯一的事实来源，有必要对Git存储库进行足够的保护，以避免不必要的提交或请求。
简而言之，GitOps是DevOps的一个子集，旨在利用Git的强大优势。因此，大多数GitOps工作流严重依赖Kubernetes作为主要的容器化运行时。
