Як ми почали керувати delivery-процесами BSA на GitHub

Привіт усім! Я Владислав. На початку 2022 року мені запропонували посаду Керівника Delivery в BSA (Binary Studio Academy). Binary Studio Academy — це безплатний міжнародний курс, який перетворює людей з базовими знаннями мов програмування на справжніх початківців-інженерів.

З точки зору delivery, кожна Академія складається з кількох конкретних етапів, кожен з яких містить різну кількість контрольних списків. Їх потрібно виконати, щоб етап вважався успішно закінченим. Крім того, в Академії існує велика кількість документації для різних ролей, а також багато контенту, зокрема конспекти лекцій та автоматизовані тести, які оцінюють виконання домашніх завдань із цих лекцій.

Попри два роки досвіду в Академії (на той час, коли мені було запропоновано цю посаду), я все ще відчував потребу в більшій кількості прикладів та контрольних списків для всіх дій, які мені потрібно було виконати на кожному етапі Академії. Документація не завжди була корисною, оскільки ми всі знаємо, що вона має властивість втрачати актуальність або губитись, коли зберігається в різних місцях. Запровадження процесу, в якому кожен розуміє, що йому потрібно робити, мати єдине джерело правди та підтримку історії минулих Академій, стало моєю головною ціллю для змін, яку я для себе встановив, опинившись на новій ролі.

Як це працювало раніше

Перш ніж перейти до процесу, який ми використовуємо зараз, я б хотів розпочати з того, що ми мали раніше. У нас була значна кількість інструментів. Ось основні з них:

🟣 Trello. Був нашим інструментом для управління дошками. Залежно від того, хто обіймав посаду Керівника Delivery в BSA, дошки створювалися різними особами, іноді навіть не в межах організації, а на особистих облікових записах. Виникла проблема: історії минулих академій губились. Зрештою нам часто доводилося пригадувати кількість завдань, які потрібно виконати на кожному етапі. Хоча всі зазвичай розуміли, що потрібно робити, без чіткого списку завдань іноді речі забувались.

🟣 Google Docs. Цей інструмент використовувався і для зберігання загальної інформації, як-от документація та контент лекцій, і для збору статистичної інформації, необхідної для кожної Академії. Попри використання Google Drive та збереження переважної кількості інформації в одному місці, бувало виникала ситуація, коли документи створювалися на льоту для тестування чогось або для надання чернетки. Але деякі такі документи врешті-решт могли набути великої цінності. Іноді вони робилися не в BSA Google Drive, а в особистих облікових записах, що час від часу призводило до їхньої втрати.

🟣 Google Sheets. Головно потрібні були для збору статистики, але створювали подібні проблеми як Google Docs, оскільки документи були розкидані різними обліковими записами та втрачали певного рівня організації та доступності. Ще одна серйозна проблема пов’язана з історією версій документів. Іноді було простіше створити новий документ, ніж підтримувати його для кожної Академії. Зрештою вигляд певних етапів або лекцій (та те, як вони виглядали в минулому) часто губився.

Ще один виклик: хоча весь контент зберігався в Google Docs, його часто писали, використовуючи Markdown. Попри те, що Google Docs має часткову підтримку Markdown, цього було недостатньо для наших потреб, і доводилося зберігати сирі дані Markdown в Google Docs. Цей досвід не завжди був приємним, оскільки речі часто ламались або не відображалися так, як задумано, через відсутність повної підтримки Markdown.

Хоча Google Docs / Sheets у поєднанні з Google Drive є хорошими інструментами для зберігання інформації в одному місці, їхня функціональність іноді була недостатньою для зручного управління. Наприклад, процес перегляду змін, особливо коли в ньому беруть участь кілька осіб, стає досить складним. Що більше людей працюють над одним документом, то важче контролювати процес у цілому.

Також ми використовували інші інструменти, як-от Miro. Головно цей інструмент був потрібний для візуалізації певних дій, як-от схвалення змін документів. Або ж ми розглядали можливість використання дощок у Asana, оскільки не delivery-процеси керувалися в цьому інструменті. Проте коли ми розглядали можливість переходу до Asana, я вирішив дослідити інші потенційні інструменти. Після читання багатьох статей і пошуків мою увагу привернуло щось незвичайне.

Як це працює зараз

Моєю метою не було використовувати лише один інструмент, хоча це зазвичай найзручніший варіант. Надавати доступ до одного інструменту набагато легше, ніж до кількох, особливо з урахуванням кількості людей, залучених до кожної Академії. Після обмірковування, який інструмент відповідав б усім нашим потребам, та після ознайомлення з досвідом інших продуктів, я обрав GitHub. Мені здавалося, що це ідеальний варіант за можливостями, які він міг нам надати — історія версій, дошки та чіткий процес прийняття змін.

Важливим чинником у виборі було спостереження за розвитком вебсервісу протягом останніх шести місяців. Я був впевнений, що, хоча не всі функції виглядали ідеально на той момент, команда GitHub продовжуватиме вдосконалювати їх. Дорожні карти (roadmaps) функцій, як-от GitHub Actions, були дуже корисні для мене. Я фанат GitHub Actions і завжди стежу за тим, який функціонал найближчим часом зʼявлятиметься у них. Деякі інші функції, наприклад GitHub Projects, також мають відкриті дорожні карти, які надають інформацію про появу оновлень у цих функціях.

Тепер обговоримо основні можливості GitHub, які ми використовуємо для управління delivery-процесами в Академії.

🟣 Git. Оскільки GitHub передусім стосується контролю версій, ми одразу вирішили проблему втрати будь-якого файлу. Крім того, у нас тепер є чітка історія версій для кожного файлу, до якої легко отримати доступ через знайомий усім інтерфейс.

Звісно, історія версій — це не єдина перевага Git. Загалом він надає нам потужний інструментарій, яким ми користуємося. Наприклад, можливість швидко повернутися до певної версії, чи функціонал щодо вирішення конфліктів, коли кілька людей починають редагувати один і той самий файл. GitHub у поєднанні з Git виявився дуже зручним інструментом для управління текстовим контентом.

🟣 Markdown. Оскільки суттєва частина контенту, яку ми використовуємо в Академії, написана з використанням синтаксису Markdown, нам не довелося придумувати різноманітні обходи, як це було у випадку з Google Docs. Під час використання GitHub ми змогли послуговуватися файлами з розширенням .md, які є стандартним форматом для синтаксису Markdown. Нам більше не потрібно було перейматися тим, що інформація для студентів виглядає інакше, як в нас це було з Google Docs, оскільки весь контент зберігався в файлах з відповідним розширенням.

🟣 Issues & Projects. Ми розпочали використовувати GitHub Projects як нашу основну дошку для кожної Академії. GitHub Projects тісно пов’язані з GitHub Issues, які служать завданнями на дошці. Крім того, GitHub Projects надає багато корисних функцій, наприклад, різні види дощок та фільтри, які дозволяють легко та зручно відображати інформацію на основі конкретних критеріїв.

Напочатку, коли ми тільки почали використовувати GitHub Projects як нашу основну дошку, не всі, зокрема і я, були прям у захваті. Нам не вистачало деяких зручних функцій, які надавав Trello, як-от дати кінцевого терміну виконання (due dates) або простий спосіб налаштування сповіщень у Slack для змін на дошці. Це було під час нашої першої Академії, коли ми почали використовувати GitHub як основний інструмент для управління delivery-процесами.

З того часу GitHub створив багато корисної документації, наприклад тепер можна додавати автоматизацію за допомогою GitHub Actions, також зʼявилось багато нових функцій, як-от користувацькі поля (custom fields) для GitHub Issues, які можуть бути використані різними способами. Ми почали послуговуватися ними, аби зберігати дати кінцевих термінів виконання завдань. Коли ми дійшли до другої Академії, де ми використовували GitHub як наш основний інструмент, він вже мав усе, що нам було потрібно, і навіть більше.

Знову ж таки, оскільки GitHub ґрунтується на системі контролю версій, GitHub Projects мають для нас просту, але критично важливу функцію — архівування проєктів. Здається, що це маленька дрібниця, але питання втрати дошок, яку ми мали, використовуючи Trello, час від часу могло бути критично важливим. Зберігаючи все в межах одного сховища GitHub, від дошок до контенту, ми мінімізували ризик втрати будь-чого.

Усі наші контрольні списки перейшли до GitHub Issues. З усіма відомостями для статистики, зокрема те, скільки залишилося до завершення задачі та швидким переходом до відповідних лекцій та pull requests (запити на внесення змін), GitHub Issues виявилися набагато зручнішими, ніж задачі в Trello. Перш за все, це сталося через те, що раніше ми використовували два окремих інструменти: Trello — для задач та Google Docs / Sheets — для контенту. Ці два інструменти не інтегрувалися між собою, тому кожного разу та для кожної задачі нам потрібно було налаштовувати взаємодії між ними.

Оскільки GitHub Issues також спрямовані на комунікацію, ми домовилися з командою, що значна частина спілкування, пов’язана з Академією, буде відбуватися саме в них. Перш за все з метою збереження історії, а також тому, що використання GitHub Issues для цього виявилося дуже зручним. Усі внутрішні посилання, наприклад, на pull requests, GitHub перетворює на лаконічний текст. Крім того, це обʼєднує GitHub Issues та pull requests, роблячи історію змін та процесу ухвалення рішень більш зрозумілим та естетично приємним, ніж будь-коли.

🟣 Issues Templates. Для стандартизації всіх GitHub Issues і нагадування про необхідні контрольні списки, які треба було виконати, ми використовуємо функцію шаблонів. Однією з важливих переваг є те, що шаблон — це лише текстовий файл, як і всі інші файли, що є в репозиторії. Це означає, що він користується всіма потужними можливостями Git — має власну історію змін, та в разі виникнення проблем, його можна легко повернути до певної версії.

🟣 Pull Requests. За допомогою Google Docs / Sheets процес прийняття змін в контенті лекцій і документації, а також створення нових документів, був не дуже зручним. Основною проблемою було призначення дозволів користувачам. Оскільки власники лекцій та контенту часто змінюються в нашій Академії, важко відстежувати всі ці зміни. Особливо це було проблематично, коли процес змін залежав від декількох людей. На жаль, Google Docs / Sheets не пропонували зручний спосіб реалізації.

Знайомий процес подання змін через pull requests був добре сприйнятий усією командою. Ніхто не потребував докладних пояснень щодо його функціонування, оскільки всі вже мали досвід користування ним. Налаштування власників контенту через власників коду (code owners) вирішило питання авторства контенту та затвердження змін, необхідних для внесення змін в Академію.

🟣 GitHub Actions. З цією функцією GitHub ми зрозуміли важливість автоматизації. Ми почали з лінтерів, які працюють для кожного pull requests. Наші лінтери допомагають нам підтримувати єдність стилю в усьому нашому контенті та виступають в ролі першої лінії «оборони», яку кожен повинен пройти, коли хтось хоче внести зміни в Академію.

Ось список наших основних лінтерів:

• remark. Перш за все, це лінтер для Markdown. Крім того, завдяки його безлічі плагінів, він дозволяє нам виконувати додаткові перевірки на граматичні помилки в контенті. Перед використанням цього лінтера наш контент ніколи не проходив такої детальної перевірки.
• prettier. Форматер та лінтер для форматування коду. Він гарантує, що всі наші файли мають єдиний зовнішній стиль.
• ls-lint. Лінтер для імен файлів та папок. Знову ж таки, ми прагнемо єдиного стилю і в цьому аспекті.
• editorconfigchecker. Лінтер, який перевіряє файли на відповідність правилам editorconfig. Ще один лінтер, який допомагає зберігати єдиний стиль в форматі всіх файлів.
• commitlint & dangerjs. Лінтери, які допомагають підтримувати ідентичність в усій інформації, яку надають користувачі, та яка стосується Git та GitHub (комміт повідомлення, назви гілок, заголовків PR і т. д.).

Оскільки ми прагнули зменшити нашу залежність від Google Docs / Sheets, де це було можливо, особливо в тих випадках, коли ми могли отримати інформацію з наявних даних. Наприклад, замість проведення ручних аудитів лекцій в Google Sheets для кожної Академії, ми вирішили написати скрипт, який автоматично збирає цю статистику на основі інформації, яка вже є в репозиторії. Цей скрипт був підключений до GitHub Action, який запускається та оновлює статистику кожного разу, коли нові зміни потрапляють до головної гілки.

🟣 Teams. GitHub має дуже круту систему команд та дозволів, яка продовжує розвиватися. Найзручніше полягає в тому, що додавши учасника Академії до однієї з команд, учасник автоматично отримував доступ до всіх необхідних репозиторіїв та проєктів, яких у нас досить багато, водночас маючи тільки ті дозволи, які йому потрібні.

Оскільки деякі з наших матеріалів, як-от стартові файли для домашніх завдань на лекціях або тести для автоматичних перевірок лекцій, вже були в репозиторіях GitHub, налаштування команд та дозволів зайняло мінімальний час.

У наведеному переліку були описані основні функції GitHub, які ми використовуємо для управління delivery-процесами в Академії. Можливо, я міг щось пропустити, оскільки деякі з функцій стали настільки звичними, що іноді важко згадати, як ми керували процесами без них в минулому.

GitHub стає кращим

Щиро кажучи, я хотів написати цю статтю ще після першої Академії, коли ми активно почали використовувати GitHub як основний інструмент. Однак я це відкладав. Одна з причин цього: я не був повністю задоволений тим, як ми працювали з деякими обмеженнями, які існували тоді. Наприклад, як уже згадувалося раніше, зараз ми використовуємо користувацькі поля для встановлення дат кінцевих термінів виконання задачі. До цієї функції нам доводилося встановлювати такі дати безпосередньо в описі задачі.

Хоча цей підхід працював, він не виглядав так елегантно, як дати кінцевих термінів виконання в Trello. Проте навіть із цими рішеннями на той момент нам більше подобалася робота з GitHub. Крім того, ми знали, що ці обмеження будуть виправлені, та GitHub, разом з усіма своїми функціями, стане ще кращими. Наразі нам не здається, що чогось бракує зі старого набору інструментів, якими ми користувалися.

GitHub постійно розвивається, і однією з останніх інновацій, яку ми плануємо спробувати в наступній Академії, є «Project Templates» (шаблони проєкту). Думаю, що назва сама собою розкриває, що означає ця функція. Зараз для кожної Академії потрібно створити набір задач, який завжди повторюється. Хоча ми ніколи не втрачаємо зміст цих задач завдяки шаблонам, їх створення це все ще повторна робота, яку потрібно робити для кожної Академії. Ніхто не любить робити однакові речі знову і знову, і саме для автоматизації цієї задачі створено функцію шаблонів проєкту.

Ця функція — це лише один з прикладів. Як було зазначено раніше, оскільки GitHub розвиває функції з відкритим доступом до розробки, будь-хто, хто цікавиться, може слідкувати за їхніми майбутніми оновленнями.

Підсумки

GitHub давно перестав бути інструментом винятково для розробників. Усі інструменти, які з’являються в GitHub, дозволяють використовувати його не тільки для зберігання історії коду. Різні компанії знаходять для нього різноманітні застосування: від управління відкритим блогом і до розміщення вебсайту подкасту (до речі, всі записи вони зберігають саме в репозиторіях).

Деякі читачі можуть зауважити, що подібну поведінку можна досягти, продовжуючи використовувати Trello та Google Docs / Sheets, додавши строгі вимоги та обмеження. Я частково погоджуюся із цим, але цей підхід не працював для нас. Саме тому, що в GitHub усе інтегроване, взаємопов’язане і добре доповнюється одне одним, немає бажання створювати щось на особистому обліковому записі, як це було з нашими старими інструментами. Це не кажучи вже про додаткову автоматизацію, від лінтування помилок у граматиці й до автоматичного збору статистики, яку дає змогу зробити GitHub.

Безсумнівно, ми задоволені тим, що тепер ми управляємо delivery-процесами в GitHub, і статистика, яку ми збираємо від учасників Академії, свідчить про ефективність вибору.

До того, як GitHub став нашим основним інструментом

Після того, як GitHub став нашим основним інструментом

Хоча ми не повністю позбулись Google Docs / Sheets (попри те, що ми зараз використовуємо Notion більше для схожих цілей. Так-так, ще один інструмент...), дуже часто легше швидко створити новий MVP для статистики саме в Google Sheets, ніж відразу розпочинати впровадження якоїсь логіки в GitHub. Однак ми прагнемо зберігати всі основні функції в GitHub, який є нашим основним інструментом для управління всіма delivery-процесами Академії.

Хоча на початку мого шляху в ролі Delivery-керівника в BSA мені не було поставлено завдання встановити процес, у якому кожен учасник розумів би, що йому потрібно робити. Попри те, що в той момент у мене не було точного контрольного списку, в якому було б докладно описано, що має робити кожен учасник на кожному етапі, думаю, що після 1-2 Академії я б створив схожий список для себе і почувався б впевнено. Проте проблема в тому, що, найімовірніше, я був би єдиним, хто відчув би себе впевнено у цьому процесі. Можливо, для наступних людей, які підтримуватимуть Академію в майбутньому, це однаково було б не зовсім зрозуміло, так само як це було для мене на початку.

Я згадую слова Джиммі Картера, 39-го президента США, з мого улюбленого фільму «Диво»: «Ми завжди мали віру в те, що дні наших дітей будуть кращими, ніж наші власні». Упроваджуючи інструменти, як-от GitHub, та всі інші інновації в Академію, які я реалізував і продовжую реалізовувати, я хотів би полегшити досвід участі в Академії як для поточного покоління, так і для всіх, хто прийде після нас.

Як для мене виглядає ідеальне завершення Академії