> Tests should be easy and you should want to write them.
I must be using go wrong then because I've always felt they were easy and wanted to write them. The last big project I built with it had great test coverage.
> be opinionated about deployment, so that those rube goldberg tricks you have to do to put into prod are testable and reproducible.
Of all the languages I feel like go's deployment is probably the simplest, if it's hard for you you're probably doing something pretty wacky.
Considering how infrequently this happens and how utterly trivial it is to recompile, I'd take this every time over complex deployments on the happy path.
Deploy isn't just dropping a binary into place, it's everything else. If you're in ec2, what sorts of vms or security group are you using, how do you talk to AWS, if you're on a bare Linux, are you putting in apparmor and fail2ban? If you're in eks, the reams and reams of yaml. What is your restart strategy for your process when it crashes... How do you connect your process to the cluster and instrument it with secrets...
I mean your mileage may vary on usage but we generally just build a new ec2 image, basically Amazon Linux + Go Binary, set the autoscaler to use that, and if we need the old one cycled out fast kill the older instances. We rarely need to do that, we try to avoid it.
We let the AWS autoscaler health monitoring just kill unhealthy ec2 instances. No need to worry about any sort of restart policy. It is VERY rare we actually get a Go process in an unhealthy state.
We’ve always handled banning in app, so that’s never been a consideration. Our rules around that are very complicated as we sell into institutions that have thousands of people behind a single IP address, so blocking a full IP incorrectly could mean institution wide downtime and possible loss of a client.
Our secrets get set with a little come-online script in the ec2 image. Secrets change? Kill the instances and autoscale more. Instrumentation is via REST api.
It’s basically the same way we deploy anything else but without worrying about library and language versions. Its reasonably simple, and been very easy especially compared to the previous ways we used to deploy apps.
I must be using go wrong then because I've always felt they were easy and wanted to write them. The last big project I built with it had great test coverage.
> be opinionated about deployment, so that those rube goldberg tricks you have to do to put into prod are testable and reproducible.
Of all the languages I feel like go's deployment is probably the simplest, if it's hard for you you're probably doing something pretty wacky.