It took me a while to start to understand the power that Red Hat OpenShift brings to the Kubernetes world. As someone who is supposed to advocate for OpenShift, I first need to know why I would use the technology before I can advocate. This post explains one of the value adds that got me. OK, let’s get started!
If you are someone who is encouraged or even required to move to the cloud-native ecosystem, running an application on Kubernetes (or OpenShift) can be overwhelming. If you visit the CNCF Cloud Native Interactive Landscape map and look at all the options you can plug into a vanilla Kubernetes, it’s safe to say that it’s intimidating. I am every time I look at it.
One of the first advantages of OpenShift is that it’s an opinionated deployment of Kubernetes. Red Hat spent the time and effort to create a proper production-grade installation of a cloud-native platform and gave you the power to just “use it”. You no longer need to sift through all of the different options; OpenShift just gives you the choices to focus on the business value add and to hopefully get your features out faster than your competition.
So what does this have to do with Git branching and projects? Let’s put ourselves in the mind of someone making those business value adds and see how just one feature (projects) enables them.
If you live in the development world, you probably collaborate on some code to help drive your business. You probably have something such as JIRA to track your tasks and hopefully work on an agile-style team. You probably adopted Git as your distributed version control systems (DVCS) and you are comfortable creating feature branches to merge back into your main branch when the feature is complete and ready to be deployed. You do this day in and day out and your development environment is probably something cut down to mimic as close as you can get to your production environment, but not 100% the same.
Projects are just “souped-up” namespaces in vanilla Kubernetes. They give you many benefits, including role-based access control (RBAC) that ties into other external access controls, quotas assigned to specific resources, and more substantial isolation with some tweaks to the setup. The one thing that moved me over the edge into understanding the power of this feature is the built-in, “ephemeral” nature of projects.
Let’s pretend that you have a ticket called BILLING-1234 and you need to put this feature into your application. There are a couple of projects in your OpenShift cluster called BILLING-PROD, BILLING-STAGING, and BILLING-DEV. BILLING-PROD is the production environment and you know that it’s there, but you can’t access it. BILLING-STAGING deploys a nightly build via continuous integration from your main branch and runs integration tests on it. Finally, BILLING-DEV is a shared DEVELOP environment in case your team needs to collaborate.
The first thing you must do is create a new feature branch, such as git checkout -b BILLING-1234. Now you must deploy it to your OpenShift cluster just to ensure that you have everything safely. Assuming that you have the correct permissions, you could quickly just type out oc new-project BILLING-1234-2021-06-15 and then deploy your app to it.
When you’re done with the feature add, you can make your pull request, deploy it to something such as BILLING-DEV to get more eyes on it, and then, if it’s merged into the main branch, maybe it can be deployed to BILLING-STAGING. Then, when you’re done with your work, you can quickly delete your project by using oc delete project BILLING-1234-2021-06-15 and start the process all over again.
Hopefully, this explanation highlighted the workflow and the natural compliment of using git feature branching and OpenShift projects. You could do some of this with vanilla Kubernetes, but that would require more extended setup and effort. Whereas, for a developer, if all of this is available on day one, you can focus on your value add to the business and grow your competitive edge.
