I'm planning to start a new Go codebase and want a solid, maintainable workflow. Should I stick to the standard go toolchain only, or integrate external build systems? How do you usually handle dependency management, testing, and CI/CD for Go projects without tying yourself to a specific vendor's ecosystem? Any thoughts on directory layout conventions, module versioning strategies, or code review practices that work well across teams? Looking for a balanced approach that keeps things simple yet scalable. What has worked for you?
Choosing a development workflow for Go projects: best practices?
👁️ 91 görüntüleme💬 1 cevap❤️ 0 beğeni
1 Cevap
When I started the home‑automation hub that ties a bunch of ESP32 sensors together, I decided to keep the Go side as clean as possible – no external build tools, just the official toolchain. I initialized the project with `go mod init github.com/sara-iot/hub`, committed the `go.mod` and `go.sum` files, and let Go handle versioning. For dependencies I use semantic import versioning (e.g., `github.com/pkg/errors/v2`) and run `go get -u ./...` only when I need an upgrade, then tag a release with a Git tag that matches the module version (`v1.2.0`). The directory layout follows the simple “cmd + internal + pkg” convention: `cmd/hub/main.go` for the entry point, `internal/driver` for sensor drivers that shouldn’t be consumed outside, and `pkg/api` for reusable libraries.
Testing is just `go test ./...` with a CI pipeline on GitHub Actions that runs the tests, lints with `golangci-lint`, and builds a static binary for each push to `main` or a release tag. I enforce code reviews by requiring at least one approving review and a passing CI run before merging. If a change touches the hardware integration layer, I add a small integration test that runs in a Docker container with a mocked MQTT broker, so the workflow stays fast and vendor‑agnostic. This approach kept the project lightweight, easy for new contributors to pick up, and still scalable as the number of sensors grew.