我花了一段时间才开始理解红帽OpenShift给Kubernetes世界带来的力量。作为一个应该为OpenShift做宣传的人，我首先需要知道为什么会使用这项技术，然后才能宣传。这篇文章解释了让我心动的一个附加价值。好了，让我们开始吧!
如果你是一个被鼓励甚至被要求转移到云原生生态系统的人，在Kubernetes（或OpenShift）上运行一个应用程序可能会让人不知所措。如果你访问CNCF云原生交互式景观地图，看看你可以插入一个虚构的Kubernetes的所有选项，可以说这是令人生畏的。我每次看的时候都是这样。
OpenShift的第一个优势是，它是Kubernetes的一个有意见的部署。红帽花了很多时间和精力来创建一个适当的生产级的云原生平台的安装，并给你权力来直接 "使用它"。你不再需要筛选所有不同的选项；OpenShift只是给了你选择，让你专注于业务增值，并希望比竞争对手更快地推出你的功能。
那么这与Git分支和项目有什么关系呢？让我们设身处地的想一想，让我们来看看这些商业增值功能是如何实现的（项目）。
如果你生活在开发的世界里，你可能会合作编写一些代码来帮助推动你的业务。你可能有诸如JIRA之类的东西来跟踪你的任务，并希望能在一个敏捷式的团队中工作。你可能采用了Git作为你的分布式版本控制系统（DVCS），并且你可以自如地创建功能分支，在功能完成并准备部署时合并到你的主分支。你每天都在做这些事情，你的开发环境可能是模仿你的生产环境的东西，但不是100%相同。
项目只是vanilla Kubernetes中的 "强化 "命名空间。它们给你带来很多好处，包括基于角色的访问控制（RBAC），与其他外部访问控制相联系，分配给特定资源的配额，以及对设置进行一些调整后的更实质性的隔离。有一件事让我对这个功能的威力有了新的认识，那就是项目的内置 "短暂 "性质。
假设你有一个叫做BILLING-1234 的票据，你需要把这个功能放到你的应用程序中。在你的OpenShift集群中有几个项目，分别叫BILLING-PROD 、BILLING-STAGING 和BILLING-DEV 。BILLING-PROD 是生产环境，你知道它在那里，但你不能访问它。BILLING-STAGING 通过持续集成从你的主分支部署一个夜间构建，并在上面运行集成测试。最后，BILLING-DEV 是一个共享的DEVELOP 环境，以防你的团队需要协作。
你必须做的第一件事是创建一个新的特性分支，例如git checkout -b BILLING-1234 。现在你必须把它部署到你的OpenShift集群，只是为了确保你的一切都安全。假设你有正确的权限，你可以很快就打出oc new-project BILLING-1234-2021-06-15 ，然后把你的应用部署到它。
当你完成功能添加后，你可以提出你的拉动请求，把它部署到诸如BILLING-DEV ，以获得更多的关注，然后，如果它被合并到主分支，也许它可以被部署到BILLING-STAGING 。 然后，当你完成工作后，你可以通过使用oc delete project BILLING-1234-2021-06-15 ，快速删除你的项目，并重新开始这个过程。
希望这个解释能突出工作流程和使用git 功能分支和OpenShift项目的自然赞美。你可以用vanilla Kubernetes做一些这样的事情，但这需要更多的扩展设置和努力。而对于开发者来说，如果所有这些在第一天就可以使用，你就可以专注于你对业务的增值，增加你的竞争优势。
