源代码库
谷歌的大部分代码都存储在一个统一的源代码存储库中，谷歌的所有软件工程师都可以访问。使用这个单一的、可广泛访问的存储库有一些值得注意的例外，特别是两个大型开源项目 Chrome 和 Android，它们使用单独的开源存储库，以及一些高价值或安全关键的代码片段，其中读取 访问权限被更严格地锁定。
几乎所有开发都发生在存储库的“头部”，而不是分支上。这有助于及早发现集成问题并最大限度地减少所需的合并工作量。它还使得推出安全修复变得更加容易和快捷。
自动化系统经常运行测试，通常是在每次更改测试传递依赖项中的任何文件之后，尽管这并不总是可行。
代码所有权。存储库的每个子树都可以有一个文件，列出该子树“所有者”的用户 ID。
编译系统
Google 使用名为 Blaze 的分布式构建系统，该系统负责编译和链接软件以及运行测试。它提供了用于构建和测试的标准命令。这些标准命令和高度优化的实现意味着任何 Google 工程师通常都可以非常简单快速地构建和测试存储库中的任何软件。 这种一致性是一个关键的推动因素，有助于工程师跨项目边界进行更改变得切实可行。
程序员编写“BUILD”文件，Blaze 使用这些文件来确定如何构建他们的软件。 诸如库、程序和测试之类的构建实体是使用相当高级的声明性构建规范来声明的，该规范为每个实体指定其名称、源文件以及它所依赖的库或其他构建实体。 这些构建规范由称为“构建规则”的声明组成，每个声明都指定高级概念，例如“这是一个包含这些源文件的 C++ 库，这些源文件依赖于这些其他库”，并且由构建系统来映射每个构建规则一组构建步骤，例如编译每个源文件的步骤和链接的步骤，以及确定要使用的编译器和编译标志的步骤。
代码审查
谷歌已经构建了优秀的基于网络的代码审查工具，与电子邮件集成，允许作者请求审查，并允许审查者查看并排差异（带有漂亮的颜色编码）并对其进行评论。 当更改的作者发起代码审查时，审查者会收到电子邮件通知，其中包含指向该更改的 Web 审查工具页面的链接。 当审稿人提交审稿意见时，系统会发送电子邮件通知。 此外，自动化工具可以发送通知，例如包含自动化测试的结果或静态分析工具的发现结果。
对主源代码存储库的所有更改必须由至少一名其他工程师进行审核。此外，如果更改的作者不是所修改文件的所有者之一，则至少有一位所有者必须审核并批准该更改。
测试：
Google 大力鼓励并广泛实践单元测试。 产品中使用的所有代码都应该有单元测试，如果添加源文件而没有相应的测试，代码审查工具将突出显示。代码审查者通常要求任何添加新功能的更改也应该添加新测试以覆盖新功能。 集成测试和回归测试也被广泛实践。
谷歌还拥有用于测量测试覆盖率的自动化工具。部署之前进行负载测试也是 Google 的惯例。 团队需要制作一个表格或图表来显示关键指标，特别是延迟和错误率
错误追踪
Google 使用名为 Buganizer 的错误跟踪系统来跟踪问题：错误、功能请求、客户问题和流程（例如发布或清理工作）。Bug 已分类分成分层组件，每个组件都可以有一个默认受让人和默认抄送电子邮件列表。 当发送源更改以供审核时，系统会提示工程师将更改与特定问题编号相关联。
Google 团队定期扫描其组件中的未解决问题是很常见的（尽管不是普遍的），对它们进行优先级排序，并在适当的情况下将它们分配给特定的工程师。 有些团队有一个特定的人员负责错误分类，其他团队则在定期团队会议中进行错误分类。 Google 的许多团队都使用错误标签来指示错误是否已被分类，以及每个错误的目标是修复哪个版本。
调试和分析工具
Google 服务器与提供许多用于调试正在运行的服务器的工具的库链接。 如果服务器崩溃，信号处理程序将自动将堆栈跟踪转储到日志文件，并保存核心文件。 如果崩溃是由于堆内存耗尽造成的，服务器将转储活动堆对象的采样子集的分配站点的堆栈跟踪。
还有用于调试的 Web 界面，允许检查传入和传出 RPC（包括计时、错误率、速率限制等）、更改命令行标志值（例如，增加特定模块的日志记录详细程度）、资源消耗、分析 。
这些工具极大地提高了调试的整体易用性，以至于很少需要启动传统的调试器（例如 gdb）
