“Ми не боїмося деплоїти по п’ятницях та добре підсмажуємо усі без винятку продукти у вогні продакшну”
Один з найкращих технологічних євангелістів та командних лідерів у Microsoft, Абель Ван присвятив своє життя написанню коду та деплою. Йому належать титули Certified Scrum Master, ALM Ranger, а серед користувачів Twitter, друзів та колег він був відомий як рок-зірка.
На жаль, цей талановитий розробник помер від раку у липні 2021 року. Однак його безмежна жага самовдосконалення та надзвичайно світла вдача житимуть у серцях його друзів та фанатів вічно.
Запрошуємо вас із задоволенням зануритись у розповідь Абеля про трансформацію департаменту DevOps у Microsoft, а також про особливості побудови внутрішніх процесів всередині технологічного гіганта.
Хто такі DevOps?
“Якщо ви запитаєте про це 10 людей - отримаєте 20 різних відповідей. В Microsoft, DevOps - це єдність людей, процесів та продуктів, яка уможливлює безперервне донесення ключової цінності компанії до кінцевого користувача.
Майте на увазі, я не сказав “безперервне донесення коду”. Бо що це мало б означати? Чи несуть в собі цінність нескінчені рядки коду, що простираються на чорному екрані?
Також зазначте, що я не сказав “безперервне донесення функцій продуктів”. Так, наша команда девопсів може доносити одну функцію за іншою, спринт за спринтом, однак, це не дуже цікавить користувача”.
Чому важить саме “цінність”?
“Сучасний бізнес - настільки швидкий, що єдиним шляхом для більшості технічних команд є втілення найкращих DevOps практик. Якщо ці практики не використовуються командою, втриматися на ногах - надвзичайно складно.
Завжди пам’ятайте, що у спину вам дихають конкуренти, які вправно застосують ці практики. І чим краще їм це вдасться, тим більш інноваційний продукт вони зарелізять.
І все, в очах користувачів ваші сервіси та продукти будуть застарілими і ви втратите продажі. Ніхто не хоче, щоб його називали застарілим.
Так було і з компанією Microsoft: наші конкуренти розвивалися більш швидко, а ми втрачали клієнтів. Наша команда розуміла - треба прийняти виклик та вдосконалити DevOps департамент. Однак, зробити це було дуже складно”.
Ми відтягували деплой на тиждень, або ж на місяці, щоб не мати головного болю
“Кожного разу, коли девопси Microsoft натискали кнопку деплою, світ перекидався догори дригом - уся інфраструктура руйнувалася. Це означало, що треба сідати та переглядати код, а це такий головний біль, я думаю, ви можете собі уявити. І ми собі гадали: чому б мені не деплоїти наприкінці тижня, або ж наприкінці місяця? А може - через шість місяців, чи вже за рік?
І те, що було спочатку 50-тьма рядками коду перетворювалося на тисячі рядків, які слід було перевірити. Увесь наш продакшн виявився під серйозною загрозою.
Згодом ми виявили одну закономірність та зробили її своєю силою - якщо якісь дії боляче б’ють по тобі, роби це регулярніше, і кожного разу вдосконалюйся. Для нас деплой був дійсно складним процесом, однак, ми переоцінювали результати під час кожного спринту та не зупинялися.
Є один вираз в нашій сфері - не починай деплоїти по п’ятницях! Бо якщо ти так зробиш - сплюндруєш усі свої вихідні, аж поки пофіксиш усе. У Microsoft девопси не лякаються п’ятниць. Ми настільки вдосконалили наші DevOps конвеєри, що можемо натиснути кнопку деплою навіть в останній день робочого тижня і усе буде працювати”.
У Microsoft ми загартовували наші продукти у битвах ще до релізу
“Microsoft домінував у 90-ті та нульові. Ми деплоїли кожні три чи чотири роки. Компанія регулярно випускала нові продукти - нова версія Windows, Office чи Sharepoint. Моя команда займалася деплоєм нової версії Team Foundation Server (TFS).
Тоді ми застосовували методологію waterfall у нашій команді, однак, світ змінювався так швидко (особливо у 2010-му), що ми теж мали адаптуватися. І перш за все це стосувалося організації робочих процесів. Пізніше ми перейшли на Agile.
На цьому зображенні ви можете побачити, як побудовані процеси у Microsoft - усі ці три острівці:
Кожен острівець для нас символізує окремий продукт - Windows, Office, Sharepoint, чи Azure DevOps. Та найцікавіше на цьому зображенні те, що острівці спрямували одне на одного пістолети. У Microsoft ми дійсно гіпер-конкурентні проти один одного.
Ми умисно створили цю культуру. Це просто. Якщо між нами є конкуренція, якщо ми боремося між собою ще до релізу продукту чи сервісу - у день презентації наші продукти вже загартований у вогні, у сутичках, або ж у справжніх битвах.
Однак, був і мінус у цій культурі. Ми створили надто токсичну атмосферу, а також учасники наших команд не були в змозі працювати швидко, постійно змагаючись з іншими. Зазначу, що найефективніших результатів досягає та DevOps-команда, члени якої постійно взаємодіють як зі своїми колегами всередині департаменту, так і з учасниками інших відділів”.
Ранньою версією DevOps-системи ніхто не користувався
“Новий CEO Microsoft, Сатья Наделла, врешті зруйнував цей блок і рішуче виступив проти токсичної атмосфери в компанії. Наделла спромігся переформатувати культуру Microsoft та донести кожному, що ми - одна команда та разом працюємо над нашими завданнями, разом досягаємо успіху та пересилюємо невдачі.
“Саме тоді перед девопсами Microsoft виникла проблема. Я працював над Team Foundation Server, однак ніхто в компанії, навіть мій відділ, не користувався цією платформою. Сатья Наделла виснував, що ми маємо розробити власну інженерну систему - DevOps-сервіс - найбільш професійну та якісну за всі системи, які будь-коли існували.
Сатья Наделла впровадив єдину інженерну систему - для розробки, для релізів, для усіх інструментів. За допомогою такої системи, учасники різних команд спілкуються єдиною мовою один з одним, і це значно покращує взаємодію команд”.
Народження Azure DevOps Services
“У 2018 році Microsoft зробив остаточний ребрендинг. Тепер платформа TFS стала називатися Azure DevOps. Щоб ще більш прискорити процеси, ми перемістили нашу систему у хмару.
Тепер кожні три тижні нові функції, ніби за помахом чарівної палички, з’являються в Azure DevOps. Тут ви знайдете все, що необхідно для розбудови програмного забезпечення.
Користувач може трекати розвиток своїх проєктів, може використовувати CI/CD систему для безперервної інтеграції та безперервного розгортання ПЗ, користуватися репозиторієм вихідного коду та кайфувати від багатьох інших зручностей. За даними Microsoft, завдяки Azure DevOps було реалізовано вже 163+ тис. деплоїв.
Для нас, девопсів в Azure, немає ніякого “зроблено”, якщо продукт добре не підсмажився у вогні продакшну. І саме завдяки переходу “на хмару” ми запускаємо це виробництво кожного дня.
Мистецтво девопса - це безперервна мандрівка від однієї ітерації до іншої, аж доки продукт не буде готовий до остаточного релізу. Пам’ятайте, щойно ви відчуєте, ніби щось боляче гатить вас по голові, не тікайте від цієї палиці, а працюйте з болісними відчуттями, аж доки самостійно не змусите біль відступити””.
На цьому розповідь Абеля Вана про Azure DevOps добігає кінця, однак він має ще багато цікавого для вас у продовженні розмови. Отут ви зможете продовжити слухати, як Абель розповідає про структуру департаментів в Microsoft, про те, чим скінчилися сварки між QA-тестувальниками та розробниками, а також про те, чому якість - перша цінність на яку орієнтуються в компанії.
Друзі, зверніть вашу увагу: незважаючи на свою лідерську позицію в Microsoft Azure, Абель не закликає усіх обов’язково користуватися платформою та її продуктом Azure DevOps. Чому? Тому що, м’яко кажучи, Azure від цього - не холодно й не гаряче, це відкрита система та платформа, тож ви можете інтегрувати будь-який інструмент з Azure.
Однак, щоб оцінити усі переваги Microsoft Azure, слід все ж таки ознайомитися з її функціоналом на практиці. Платформа стане могутнім інструментом, що допоможе розбудувати сильний DevOps департамент в вашій компанії, і ваші продукти стануть більш інноваційними, технічно-досконалими та конкурентоспроможними.
Якщо ви все ж таки вирішили скористатися Microsoft Azure - пишіть на email hello@partner-way.com. Ми подаруємо вам круту знижку.
І не затягуйте зі своїм деплоєм, звісно, якщо це не п’ятниця 😁