即使在今天,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作为主要的容器化运行时。