go test 和 go build 一样建立标签，所以你可以调用 go test -tags=integration 。它也综合了 flag.Parse 包的 main，所以任何被声明和可见的 flags 将被处理和提供给你的测试。
通过验证，我的意思是静态代码验证。幸运的是，Go 有一些很好的工具。我发现当考虑使用哪种工具时考虑编写代码的阶段很有用。
当做这种事时使用这个保存 go fmt(或 goimports)
构建 go vet,golint, 或者 go test
部署 go test -tags=integration
插曲
到目前为止，还没东西过于疯狂。当做调查编撰这个列表的时候，让我注意的只是如何。。。。。。结论如何的无趣。让人沉闷。我想强调这些非常轻量，纯标准库的约定能真正推广到大群体的开发人员和多元化的项目生态系统。你绝对不会仅仅因为你的代码库已经超过一定的规模，或者只是因为它可能 增长超过一定行数， 而需要你自己的查错框架，或者测试库。你真的是不会需要它的。标准的语法和用法在代码大规模时仍然功能优雅。
依赖管理依赖管理! 呃! ᕕ( ᐛ )ᕗ
依赖管理的状态在 Go 生态系统中是一个热门的争论点，我们还没有想到完美的解决方案。但是，我们选用了一个似乎不错的妥协方案。
你的项目有多么重要?你的依赖管理方案是…嗯… go get -d,然后祈祷!
很好. VENDORING
(值得提出的是,我们有令人震惊数量的长期产品服务,依然依赖于第一个选项.然而,因为我们一般没有使用太多第三方代码,以及主要问题通常在编译阶段就被检测到,我们侥幸规避了这个问题.)
Vendoring意味着拷贝依赖到项目代码库,然后在编译的时候使用它们.依赖于你下载的内容,这里有两个vendoring的最佳实践.
下载Vendor目录名过程二进制 _vendor 加GOPATH前缀编译
库 vendor 重写import语句
如果下载二进制,就在代码库的根目录创建一个_vendor子目录.(带上下划线,这样,go工具就会在处理时忽略它,例如go test ./...)对待它就像对待GOPATH一样; 例如,拷贝这个依赖github.com/user/dep 到 _vendor/src/github.com/user/dep. 然后,编写一个所谓的神圣的编译过程,它将_vendor加入到可能存在的GOPATH之中. (记住: GOPATH 实际是一个路径的列表,当go工具处理import时,会按顺序搜索这个列表.)例如,你可能拥有一个顶层的Makefile文件,如下所示:
GO ?= go
GOPATH := $(CURDIR)/_vendor:$(GOPATH)
all: build
build:
$(GO) build
如果你正在下载某个类库在你的根存储库上创建一个vendor子目录。处理这件事就像在包目录上加一个前缀。举例来说，拷贝来自于github.com/user/dep的项目放到vendor/user/dep。在这之后，重写你所有的引入（import），及其相互关系。此时是很痛苦的，当剩下的内容需要go get兼容的时候，看起来最有效的方式是确保事实上可重新构建（actually-reproducible build）。值得注意的是，我们在实践中很少去下载类库，因此这个办法虽然麻烦却很有效。
如何在实际中拷贝一个依赖关系到你自己的存储库是另外一个热门的话题。最简单的方法是从一个克隆（clone）中手动复制文件，如果你不关心上游部门的推送，这可能是最好的答案。有些人使用git子模块，但我们发现它们非常违反直觉并难以管理（对许多 人来说也是这样，这是有记录的）。我们对于git子目录（的管理）已经很成功，他工作起来就像是子模块。还有大量的工具是用来自动处理这项工作的。现在，它看起来就像godep发展非常积极，而且还很值得研究。
构建与部署