Developing Gmail’s new look
Editor's note: This post is more technical than most posts here, but we thought some of you might find it interesting to look inside how development on the Gmail team works.
Let’s start with the first one: conditional features. This is our ability to make changes to the Gmail code that get deployed, but not executed. You can think of it as a lot of if-statements around the new code that get enabled when the conditional feature is on. The conditional feature flag itself is set outside of the deployed code. These flags can be set in various ways: as a percentage of overall users (if we want to rollout a feature slowly), for Googlers only (if we want to use a new feature internally), for individuals (if we want to give users early access to a features) and in many other ways. In short, conditional features allow us to update our production systems separately from releasing new features. This way, Gmail developers can make changes, but don’t have to worry about their unfinished changes being released before they are ready.
Using these technologies, we can make sweeping changes in Gmail without those changes going “live” before they are ready. Plus, since we can turn pieces of code on or off, we can enable new features in specific environments, such as Google, or for specific users, like the Gmail team, without changing the code itself.