Інтерв’ю з директором розробки інженерних інструментів Ашишем Кумаром
Інтерв'ю з директором розробки інженерних інструментів Ашишем Кумаром
Інструменти – питання життя та смерті для Google. Ашиш Кумар – це людина, яка відповідає за розробку інструментів. У його зоні відповідальності знаходиться вся валіза внутрішніх інструментів Google: від IDE, в яких пишуть розробники, до систем код-рев'ю, від інструментів складання, контролю вихідного коду та статичного аналізу до загальної тестової інфраструктури – за все відповідає він. Навіть команди Selenium та WebDriver звітують перед Ашишем.
Ми зустрілися з Ашишем, щоб дізнатися про цю частину Google детальніше.
— Область автоматизації в Google здається чимось магічним, багато в чому завдяки GTAC, а ти — людина, яка за цим стоїть. Відкрий нам завісу таємниці, які можливості надає твій інструментарій інженерам Google?
Ашиш: Команда розробки інженерних інструментів, а саме так ми називаємося, відповідає за створення 90% інструментів, які щодня використовуються розробниками Google, коли вони пишуть, збирають та випускають якісні програми. Останні 10% ми охопимо, коли зможемо підтримувати всі команди, які працюють із відкритим кодом.
Google унікальний тим, що велика увага приділяється створенню потужної і масштабованої інфраструктури для розробників. Люди ззовні зазвичай знайомі з технологіями MapReduce та BigTable, які наші розробники постійно використовують. Але наша внутрішня інфраструктура для розробки — це також більшість нашої роботи.
— Можна конкретніше?
Ашиш: Гаразд, самі напросилися! Набір інструментів включає:
— Інструменти для роботи з вихідним кодом. Вони спрощують створення робочих просторів, заливання змін до коду та дотримання гайдлайнів. Ці інструментидопомагають переглядати сотні мільйонів рядків коду та дають зручний пошук для запобігання дублювання. Вони уможливлюють індексування та рефакторинг у хмарі.
— Інструменти розробки. Це плагіни для IDE, які пристосовують інструменти до коду Google і пов'язують їх із нашими хмарними сервісами. Ці інструменти допомагають швидко та якісно рецензувати код завдяки можливості вбудованих сигналів під час код-рев'ю.
- Інфраструктура складання. Ця система дозволяє нам розподілити складання мультимовного коду по десятках тисяч процесорів, використовуючи такі обсяги пам'яті та дискового простору, що мені навіть уявити страшно! Система складання працює як для інтерактивного, так і для автоматизованого використання. Вона формує результати за секунди, хоча та ж робота в іншому випадку займала б годинник.
- Інфраструктура тестування. Це масштабна безперервна інтеграція. Це означає щоденне виконання мільйонів тестових пакетів за кожною заливкою коду розробниками. Наша мета – надати миттєвий (або майже миттєвий) зворотний зв'язок для кожного розробника. Це має й іншу сторону: потрібно масштабувати веб-тестування. Для тестування продуктів Google щодня запускаються сотні тисяч браузерних сесій з різними поєднаннями браузерів та платформ.
— Інструменти локалізації. Їхнє завдання — постійно перекладати рядки, спеціально виділені розробниками, щоб локалізовані версії наших продуктів виходили одночасно з англомовними версіями.
— Метрики, графіки та звіти. Тут йдеться про управління багами по всіх продуктах Google, збирання та зберігання метрик розробки, тестування та випусків. Наше завдання — надавати командам зворотний зв'язок, щоб вони могли покращити свійроботу.
— Отже, ти одночасно працюєш на всіх фронтах. Щоб досягти такого успіху, ви, напевно, додали багато інновацій у робочий процес. Як вам вдається зберігати баланс між новими розробками та профільною роботою? Адже твоя команда не така вже й велика.
Ашиш: Все просто: ми не намагаємося звалити на себе всю роботу. Ми централізований відділ розробки інженерних інструментів. Команди часто розробляють спеціальні інструменти для своїх завдань. Якщо якийсь інструмент починають використовувати інші команди, ми оцінюємо, чи можна включити його в загальний інструментарій для всіх співробітників Google. Або буває, що мої інженери самі пропонують якусь круту штуку. Ми намагаємося підтримувати всі ініціативи, але, звичайно, ми маємо свої критерії для відбору інструментів перед тим, як зробити їх централізованими. Перший критерій — інструмент має потенційно сильно вплинути на продуктивність, другий — він має бути корисним для великої кількості розробників Google. Зрештою, ми працюємо із загальними інструментами, наше поле гри — це інструменти для широкої аудиторії, які багатьом корисні. Якщо інструмент корисний лише одній команді, вона сама ним і займається.
Деякі інструментальні проекти не самодостатні, тому складно виміряти їхній вплив, але всі вони повинні давати відчутний поштовх у бік збільшення продуктивності Google.
— А чи була ідея, яка здавалася тобі невдалою, але привела до успіху?
Ашиш: Так! Масштабна безперервна інтеграція. Вона здавалася недосяжною, бо вимагала величезного обсягу роботи. Тоді ми мали тисячі машин, які безперервно виконували цикли інтеграції для кожного проекту. Хтось запропонував створити інфраструктуру, яка зробила б цейпроцес централізований для всього Google. Така інфраструктура опитувала б системи управління кодом щодо змін, тримала б у пам'яті величезний граф мультимовних залежностей цих змін, та був автоматично збирала і запускала потрібні тести. Багато хто скептично ставився до проекту, оскільки ідея була надто масштабною і наші сервери могли не потягнути. Я теж був серед скептиків: рішення вимагало величезної кількості ресурсів. Але крок за кроком наші інженери потроху долали технічні труднощі доти, доки досягли успіху: система запущена і працює. Власне, це і є схема нашої роботи з проектами: починаємо з малого, а якщо практична користь та потенціал доведені, розвертаємось на повну.
— А чи є інструмент, який обіцяв бути успішним, але провалився?
Ашиш: Знову так! Віддалене парне програмування. У Google багато розподілених команд. Багато команд застосовують парне програмування та інші гнучкі методи розробки. Часто буває, що ви працюєте над кодом, який написав людина з іншого офісу, і якщо у вас виникають питання, виникає затримка, що впливає на продуктивність.
— Твоя порада компанії, яка хоче побудувати безперервний процес автоматизації? З яких інструментів варто почати?