Контроль над джерелами: ролі та обов'язки - кращі практики

Я шукаю "Кращі практики" щодо ролей та обов'язків, зокрема, хто відповідає за злиття від галузей розвитку до магістральних (або основних). В основному я шукаю боєприпаси, щоб допомогти моїй справі.

Дозвольте описати, з чим я стикаюся. Я є головним розробником (власником) певної програми. Нещодавно наша компанія перейшла з VSS (де я була адміністратором бази даних VSS, в якій зберігався мій додаток), до TFS (де я маю лише дозволи на галузі розвитку, створені нашою командою "операції"). У попередніх робочих місцях я був адміністратором TFS, тому знаю, як обходився TFS та MSBuild.

У мене немає проблеми з використовуваною стратегією розгалуження та злиття (головна гілка, із необхідними створеними гілками помилок / проектів, об'єднана назад до основної, а потім просунута до гілки випуску). У мене є такі питання:

1. Я не можу створити власні гілки. Я повинен створити завдання TFS, щоб член команди "операції" створив для мене гілку.

2. Я не можу об'єднатися від Main до своєї галузі розвитку. Я повинен створити завдання TFS, щоб змусити члена команди "операції" здійснити злиття, а потім сподіваюся, що він не "наступає" на зміни будь-якої з моїх команд, оскільки "ops guy" може бути, а може і не бути розробником, і, звичайно, має мало що не знає код, який він зливає.

3. Я не можу злитися від розробки до Main. Знову я повинен створити завдання TFS, щоб змусити "хлопця-оператора" виконати злиття, сподіваючись, що він це зробить правильно. Тоді мені доведеться створити ще одне завдання TFS, щоб об'єднатись назад до своєї гілки, щоб я міг вирішити будь-які проблеми, які виникли, зробивши об'єднання не розробника з Main.

4. Я не можу створювати або редагувати сценарії MSBuild. Знову мені доведеться співпрацювати з командою "ops", яка є новою для MSBuild, тому можна виконувати лише найосновніші завдання зі зборки. (Забудьте про що-небудь складне або не забороняйте на замовлення завдання).

5. Я не можу виконати сценарій MSBuild. Знову це може зробити лише команда "опс".

6. На додаток до всього цього, як правило, це "офшорний" ресурс, який виконує запитувані завдання, тому навіть якщо я створюю завдання (гілка / об'єднання / збірка) рано вранці, воно, ймовірно, не буде завершено до того вечора.

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

На мою думку, технічні напрямки (такі як я) повинні відповідати за підтримку магістралі ("Головна") та будь-яке злиття в / з галузей розвитку. Команда команди також повинна мати можливість генерувати сценарії MS Build для складання та розгортання в тестовому середовищі інтеграції.

Чи може хтось направити мене на документ «Кращі практики», який допоможе мені довести свою справу? Усі мої пошуки виявили лише кращі практики щодо технік розгалуження та злиття, і жодна згадка про ВООЗ не повинна виконувати зазначені розгалуження / злиття.

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

На жаль, це не схоже на підхід, який вони тут взяли. Для того, щоб перемогти це, я думаю, вам потрібно прикрити кілька кутів:

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

b) Подружитися в Ops - можливо, в цій політиці є причина. Можливо, це міркування можна було б вирішити більш ефективно.

Сподіваюсь, це допомагає.

Я бачив такі практики:

1. Будь-хто може створити робочі гілки за змістом свого серця. Розробник повинен бути в змозі створити гілку функцій, коли вони виявлять, що є сенс зберігати поточну роботу. Оскільки вони хочуть / повинні створити резервну копію в кінці дня, хочуть поділитися цим вмістом з іншим членом команди, їх слід захищати від змін в основному чи будь-якому іншому.

2. Будь-хто може зробити абсолютно все для галузей розвитку. Розробник повинен бути в змозі злитися з основної хвилини, коли інший розробник скаже їм, що їм потрібно було інтегруватись у головне.

3. Для злиття з основним (інтеграція) є три варіанти:

   • Розробники роблять це самі. Вони просто обговорюють ризики з провідним розробником і тестують функції належним чином. Це означає, що хтось має дозволи; якщо хтось порушує правила, вони просто лаяться і неправильна зміна повертається.
   • Інший розробник робить це після перегляду змін. Це все ще вимагає, щоб усі мали дозволи на це; правила досі виконуються провідним розробником.
   • Там призначений інтегратор, який переглядає і об'єднується в основний. Але інтегратор є частиною команди і повинен розуміти код. У меншій команді це була б така сама людина, як архітектор, у більшій вони були б окремими, але їм потрібно було б тісно співпрацювати.

4. Хто готує функцію, повинен адаптувати сценарій збірки. Але я не впевнений, як це працює з TFS; в системах, які я використовував сценарій збирання, завжди був просто розробленим файлом, тому розробники редагували його так само, як і будь-який інший, і він був інтегрований разом із усім іншим.

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

6. Ні в якому разі не слід вимагати операторів поза командою. Оператор потрібен лише для налаштування дозволів, створення реплік тощо.

Не забувайте про "кращі практики" (майте на собі) це проблема управління - принципово, ви не в змозі виконати належну роботу через обмеження, поставлені перед вами.

Насправді не важливо, що таке «найкраща практика» - це простий, демонстраційний випуск, який вплине на продуктивність роботи вас і вашої команди, і вам потрібно на цій основі приймати рішення щодо управління лінійкою.

Я бачу, що розробка документа з найкращої практики може бути (але лише може ) допомогти в спробах їх переконати, але набагато краще - це думка, що вам доведеться мати членів команди розробників, сидячи на руках, поки чекати когось в іншому часовому поясі зібрати свої дії, якщо процеси не будуть покращені / раціоналізовані.

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