No, they would just use whatever tool is more appropriate for the job.
Fabric would be fine, ansible would be fine, salt would be fine, putting it on Docker and deploying via compose would be fine. None of these tools force you to learn the implementation details of the application.
That still leaves them the problem of "If I don't know this tech stack, what do I do?"
You are working on the assumption that everyone already knows Fabric, Ansible, salt or Docker.
Whichever poison you choose, people who don't know that particular poison won't know how to install to a different provider anyway!
You're making an argument against one particular poison, but I don't see it as any better or any worse than the others, which all have enough complexities to fill a book.
If you don't know how to use a tool that does one job, either you learn it or you just delegate that job to someone who knows it already. But defending the practice of having your application code also responsible in dealing with deployment and packaging smells a lot of "coders are gonna code".
How is that different from "If you don't know how to use the tool (Go), either you learn it or you just delegate that job to someone who knows it."?
> But defending the practice
Woah there cowboy, I wasn't advocating an architectural decision suitable for a FAANG. I was "defending" the position of "why you an extra tool for this one program that has no other dependencies?"
> of having your application code also responsible in dealing with deployment and packaging smells a lot of "coders are gonna code".
In much the same vein, switching to Ansible, Fabric, etc simply to install a single binary to a single place smells a lot like "resume-driven-development".
I already started replacing parts of my shell scripts with Golang programs and the experience is miles ahead.
And if the project is already written in Golang, it makes even more sense if the dev is also partially the DevOps. Why wouldn't they make the experience as seamless as possible for themselves and the rest of the dev team? What good would Ansible do if everyone has to yet learn it?
As for the person you originally replied to, I'd definitely make a separate program that provides tooling related to the main program... but that's the only different thing I'd do.
Your snarky "coders gonna code" comment is detached from reality, we have jobs to do, and within deadlines.
You could say the same thing about Java or C++. Would you argue then that the best way to deploy java applications is by writing a java library and embed into your program?
> if the project is already written in Golang, it makes even more sense if the dev is also partially the DevOps.
I really don't see how that one follows from the other, and I really don't understand this conflation between roles and tooling. There is a lot more to "DevOps" than packaging/distributing/deploying. It's not just because your application code is in Go that your tooling needs to be as well.
> Why wouldn't they make the experience as seamless as possible for themselves and the rest of the dev team?
Because it's a fragile solution. You are tying the implementation of your problem to a very narrow space out of immediate convenience. I've had my share of projects with "experienced" node.js developers who are trying to do everything in node instead of reaching out of their comfort zone and looking for existing solutions elsewhere.
> we have jobs to do, and within deadlines.
Yeah, and a lot of those jobs could have been made in a fraction of the time if the developers were not trying to use their screwdrivers as hammers, and put some effort to figure out how to use the hammer in the first place.
