Я підрядник, який нещодавно почав з фірмою.
Команда - це 3 розробники, що складаються з 2-х молодших і середніх рівнів, з іншим на тому ж рівні, що починається незабаром, і я (6 років xp). Для обох існуючих розробників це їх перша робота поза університетом / коледжем, і вони ніколи не мали старшого розробника, який наглядав за їх роботою.
Не існує чіткої політики контролю версій. Розробники роблять усі розробки на магістралі, а потім розгортаються до виробництва безпосередньо зі своїх розроблювальних машин. Існуюча команда не знайома з розгалуженням.
Я все це змінюю і ввожу сервери CI, TDD / тестування / виробництво тощо, а також політику управління версіями для компліменту.
Системою управління джерелами є TFS, якою я ніколи раніше не користувався. Він налаштований як одне гігантське сховище.
Я записав на них кілька покажчиків, але чи є ще щось, що я повинен додавати / виправляти, маючи на увазі досвід команди?
Політика управління версіями
Розробка робиться на багажнику
Якщо зміна, як вважається, триватиме більше тижня, тоді це слід робити на гілці, регулярно зливаючись зі стовбура у гілку, щоб зупинити їх синхронізацію.
Випуск гілок, створених для виробничого коду. Ця гілка повинна містити лише стабільний код. У нас може бути одна гілка випуску, яка оновлюється зі стовбура один раз за спринт, або ми можемо зробити окрему гілку випуску на кожен тиждень.
Якщо потрібно терміново виправити помилку, що впливає на виробничий код, тоді він буде зроблений на гілці випуску та об'єднаний назад у магістраль.
Якщо ми застосуємо стратегію однієї гілки випуску, тоді магістраль об'єднується в гілку випуску один раз за спринт до кінця спринту.
Якщо ми застосуємо окрему гілку за стратегією випуску, то магістраль НІКОЛИ не об'єднується у гілку Release
У деяких сценаріях може знадобитися виправити помилку двічі на різних гілках, якщо гілки розбіглися занадто багато. Якщо ми робимо короткі спринти, то це не повинно траплятися занадто часто.
Планую мати три сервери. Тестове середовище, у якому завжди працює останній код репо. Постановочне середовище, в якому працює найновіший кандидат випуску для постановки / тестування коду кандидата випуску та цілей UAT та виробничого середовища.
Причина, чому я планую це зробити, полягає в тому, що поки що клієнт робив лише внутрішнє програмне забезпечення. Найновіший проект - це для висококваліфікованого медіа-клієнта, і я відчуваю, що команді потрібно прийняти більш професійну модель розвитку, ніж те, що вони роблять на даний момент.
Наприклад, на даний момент користувач може телефонувати команді зі звітом про помилки. Розробники знаходять і виправляють помилку, роблять швидкий тест очного яблука на власних машинах, а потім розгортають прямо у виробництво. Ніякого автоматизованого тестування чи нічого.
Коли я заздалегідь думаю, я вважаю, що галузь функції - це крок занадто далеко, і я її вилучу.
Таким чином, це по суті зводиться до а) відсутності розгалуження взагалі) б) гілки вивільнення та магістралі та в) гілки випуску за випуском та магістралі.
Я схилявся до останнього. Моя початкова думка полягала б у тому, що я маю одночасно і кандидата на випуск, і випуск, який би можу працювати на окремих серверах (UAT / Production) одночасно, але фактично магістраль є кандидатом на реліз у будь-який момент часу, тому гілка в звільнення схиляється до божевільного. Моя єдина думка була б, якби ми не хотіли, щоб наші зацікавлені сторони бачили код розробки, тоді нам може знадобитися окрема гілка кандидата на випуск, але YAGNI і все це .....