Yesterday, I had attended the tech talk on Google about "Developing products at the Speed and Scale of Google". It was organized at Google Campus, Hyderabad. Me and Sethu (@
karthicksethu) reached Google around 5:30 PM for the talk which was scheduled to start at 6 PM. The first thing which surprised me was the count of Microsoft guys who have registered for the talk. We were escorted to the cafeteria where the talk was organized. The talk started on time. Ashish Kumar, who gave the talk, is an Engineering manager responsible for steering and managing the engineering Tools team that builds tools for most engineers at Google. The main focus of the talk was on the development environment at Google which enables its engineers to build products faster. Ashish talked about the different systems which are available for developers at Google to productize their ideas.
Highlights- For any company to be successful, it should have a good engineering hygiene. Good amount of investment on infrastructure is required.
- Google uses Perforce as its revision control system.
- Common code base for all the Google products. From kernel to a simple plug-in built by Google will reside inside the same repository. Single monolithic tree. Developers work on Head. No branches. Build everything from source.
- Google uses Eclipse and IntellijIDEA as its IDEs. Plug-ins are developed to do almost everything from within the IDE.
- Continuous Build system. Google has built its own robust build system. Build system makes use of the thousands of idle machines on the cloud. Cacheing mechanism has been built which will enable faster builds by cacheing the output binaries. 1 PB objects are cached for builds. Google uses FUSE virtual file system to bring back the output binaries of the build to the developer. Every Google office has a local site cache.
- Automated testing. Hundreds of millions of test cases are run every day. The aim of this system is to fail faster, report clearly, find the root cause. Most part of the test cases are written manually at Google. Ashish's team is working on data mining the results which can be can be used for Code analysis and predicting bugs from the code. There is a SQL interface for querying these test results - Google Sponge.
- Rollout. Releases happen based on the tags and the build configurations.
Google's view on single tree repository
- Single source code repository helps in maintaining strong coding practices.
- Code transparency at the development phase itself.
- Branching might lead to deviation from the standards.
- Merging and conflicts resolution are more painful than working on the head.
- Experimental features are controlled using build configurations.
Low Lights
Q & A Session
[Varun] How are the open projects like Chromium, Android, etc handled? Do they follow the same development procedure?
[Asish] Currently, Open source project development does not follow all the development procedures for closed source products. But, that is the ideal way to go and we are working on it.
[Varun] Is '
Mondrain' used as a code review tool for all the languages or only Python? Any plans of releasing Mondrain as a product?
[Asish] We use Mondrain (the code name for the code review tool) for all the code we write. No plans of releasing as a product. At least not in near future. Mondrain is being used in Google code.
[Q] Will this infrastructure setup be available as a service in future?
[Asish] May be. No plans as of now.
[Q] Do the developers accept these internal tools immediately?
[Asish] Our main goal is to improve the developers experience. If we are building anything better for them, they will accept it. Also, we dogfood all our products before going live.
Google's approach may not be suitable for all the companies but the idea should be to build a good engineering culture which will help the company to build products easily.
-- Varun