3 ms·

While coupling is convenient, there is a problem when you are not the only consumer of your code. If you have an open source project that is to be deployable by

While coupling is convenient, there is a problem when you are not the only consumer of your code. If you have an open source project that is to be deployable by anyone, you can't put Kubernetes files there (there's not really a way to write a generic Kubernetes manifest -- in addition to volumes and secrets, things like labels are environment-specific). This is also true for other things like .drone.yml for Drone. So you have to maintain a private "release fork" that you periodically rebase into. This becomes a workflow bottleneck, and the VCS history will not look good, either. Even worse if you have multiple branches you deploy from.

avitzurel 10y ago
This is true. It's especially true if you have services depending on one another. I think there's a middle-ground there. Right now, 99% of people I know use Github-Workflow, master is always deployable (often CD), other branches are able to deploy using "hubot deploy branch-name to xxx" I think if you take the latter and you make it easier to deploy an application on top of your cluster, you can gain a lot. The workflow today is more cumbersome. If you could create your application, attach some definitions to it and launch it to the scheduler, it would be better.