4 ms·

Or since it is an engineering CLI tool, why not have engineers: 1. clone cli repo 2. run goreleaser 3. copy binary to desired path sure, it's not 1 step (can

by bfung 6y ago

Or since it is an engineering CLI tool, why not have engineers: 1. clone cli repo 2. run goreleaser 3. copy binary to desired path sure, it's not 1 step (can be condensed with a build script), but it does teach the other engineers how to roll their own cli tool and contribute back if they fix a bug in it. Or if the blog indicated that not all engineers understand golang and build tools, and there's too many teams - that'd be good for blog context. Hopefully the author didn't spend much time in figuring out or being too clever in making this "hack".

emeraldd 6y ago
As the number of tools grow and the number of teams using/developing them grow this becomes more and more untenable. You not only have to maintain the tool itself, but also the build stacks associated with them and it becomes the task of the user to make sure they are running the most recent version. This leads to more complex support situations. Basically, you need a deployment methodology that allows for: * Ease of use by "novice" developers * Only introduces minimal overhead for those developers * Makes it easy to upgrade or remove a tool you installed 6 months ago * Doesn't require a tool development team to come up with their own solution This is a surprisingly tricky to do on a diverse environment with 1000+ internal users.