3 ms·
Not GP, but one of my previous jobs used to have a deploy method of "ping one of the ops team on Slack to release a certain commit SHA to prod/staging/etc", whi
by WJW 3y ago
Not GP, but one of my previous jobs used to have a deploy method of "ping one of the ops team on Slack to release a certain commit SHA to prod/staging/etc", which might easily take an hour or more if they were busy and/or you asked around lunchtime. Even if they were available immediately it would still take 20 minutes.
After we moved to k8s, the release model went to "every dev can use kubectl to deploy" and it took a minute or ten to release something to prod. Needless to say, we all loved it much more than the previous setup. Even more so after someone whipped up a script to automate all the kubectl invocations.
One of my former colleagues wrote an article about it here: https://wetransfer.com/engineering/migrating-frontend-to-kubernetes/ https://wetransfer.com/engineering/migrating-frontend-to-kub...
- renaudg 3y ago"every dev can use kubectl to deploy" may be less horrific than the previous situation but it's still pretty bad practice tbh. So is "a script to automate all the kubectl invocations". There's existing tooling for that : Skaffold, ArgoCD ...
- WJW 3y agoOf course, but those were not yet available in 2017. Skaffold v0.1.0 was released in february 2018, v1.0 (first version number which we would've seriously considered) not until november 2019. ArgoCD v1.0 was released in may 2019. When we were first releasing this Helm charts were considered pretty unproven and AWS didn't have a managed k8s offering yet. It was very early days.