2 роки в Twitter

Я був інженером у команді Build/Bazel Migration у Twitter. Після двох дивовижних років 17 листопада стало моїм останнім днем ​​(я прийняв пропозицію про розлучення за власним бажанням і звільнився, що завгодно). Twitter був особливим місцем для роботи через його культуру досконалості, його різноманітність і його вилив турботи про всіх людей, які зробили Flock the Flock. Я вдячний, що мав можливість відчути це з перших вуст і бути частиною цього.

Ось невелика ретроспектива моїх останніх двох років. Наведена тут інформація базується на дискусіях і загальнодоступних даних. Тільки з нашої команди понад 10 членів покинули Twitter після поглинання. Тож я розсипав цю публікацію посиланнями на їхні поточні та колишні профілі LinkedIn.

По-перше, мені, ймовірно, потрібно розпакувати те, що зробила команда створення. Якщо процитувати загальнодоступні дані, у 2020 році у нас було близько 2000 інженерів із 20 мільйонами рядків рукописного коду (в 10 разів більше, включаючи згенерований код) лише в репозиторії, переважно Scala, але Python, Java тощо. Залиште осторонь фактичний розмір коду, через кількість команд швидкість змін, які відбуваються щодня, також дуже висока. Twitter, звичайно, не унікальний за розміром своєї кодової бази, але в такому масштабі вам потрібен відділ інженерів + менеджерів, щоб дати можливість іншим інженерам кодувати за допомогою спеціалізованих JVM, спеціального git, інструментів збірки, CI тощо. Цей відділ був інженерною ефективністю.< /p>

Команда EE Build мала продукт monorepo, який ми назвали Source. До 2020 року команда розробила власний інструмент збірки під назвою Pants, частково натхненний внутрішньою системою збирання Google, Blaze, але додавши багато відсутніх функцій, наприклад підтримку Scala з початку 2010-х років, призначену для розробки та швидкості Twitter.

У 2015 році Google створив версію Blaze з відкритим вихідним кодом під назвою Bazel, яка ставала цікавим інструментом для збирання, який активно розроблявся разом із багатьма компаніями, які робили внесок у навколишню екосистему плагінів та інструментів. У квітні 2020 року команда Build оголосила, що прийняла рішення перейти з Pants на Bazel.

Чому вам знадобиться команда інженерів, щоб запровадити інструмент для створення, може бути неочевидним, якщо ви ніколи не мали справу з великомасштабною кодовою базою, але спосіб подумати про це полягає в тому, що приблизно у 2020 році Bazel більше нагадував ящик для будівельних інструментів, а не будівельний інструмент. Це частково тому, що в Google є інші інструменти, які керують розгортанням, а також тому, що ми маємо справу з 20 мільйонами рядків коду, який розвивався разом із багатим набором функцій Pants. Тож команда Build стала командою міграції Bazel, щоб перезапровадити багатий набір функцій, не втрачаючи збільшення продуктивності, яку ми сподівалися отримати, перейшовши на Bazel, і фактично перенести служби та завдання даних, які забезпечують Twitter.

Щоб уникнути руйнівної міграції Big Bang, команда застосувала унікальний підхід до створення шару емуляції Pants на макрорівні, тож файли BUILD обслуговували як Pants, так і Bazel. Це дозволило поступове впровадження без втрати продуктивності.

Я приєднався до команди Build/Bazel Migration у серпні 2020 року, у розпал пандемії COVID-19 до вакцинації. Світ схвально сприйняв ідею працювати вдома, для мене це було старою проблемою, оскільки я працював вдома з 2011 року. Першим тижнем була Flight School, тиждень внутрішнього навчання, яке проводили штатні інструктори. та інженери високого рівня з різних тем, включаючи технологічний пакет і корпоративну культуру.

Команда розробників складалася з 12 осіб, які постійно змінювалися, кількох додаткових консультантів і деяких членів, запозичених із сестринських команд. Оскільки я працював з відносно невеликими командами, спочатку це було приголомшливо. Тому я пам’ятаю, що в перші кілька тижнів Ї Ченг зробив мене частиною команди. Ї був опорою команди й знав відповіді на будь-які запитання про Pants, завжди допомагав і спілкувався з різними командами від верху до низу.

На той час у мене було приблизно 10 років досвіду кодування Scala, що було дивно для нового найняти. У перші кілька тижнів я модернізував підтримку Bazel внутрішньої служби віддаленого кешування для Pants під назвою buildcache (додаткову інформацію про buildcache див. у Scala 2015 у Twitter). Це не найоптимізованіше рішення для Bazel, але й непоганий початок.

Потім я поговорив з Іті Каулом, який був технічним керівником команди Build, яка на той час перебувала в Лондоні. Як найстарша та найвища особа, вона була зайнята організацією робочих процесів і відстеженням...