Коли доцільно почати використовувати наступну редакцію інструменту під час виведення собаки?

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

Моє запитання: в процесі випуску в стилі scrum за допомогою розгалужуваного робочого процесу я починаю використовувати новішу версію інструменту в циклі розробки інструменту?

Я шукаю процес для створення балансу між:

• постійно використовую developверсію інструменту: я вважаю, що я порушую власну розробку, коли зміни включаються.

• постійно використовуйте masterверсію інструменту: будь-які проблеми, які я розкриваю через dogfooding, - це вже випущені проблеми.

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

По-друге, вам потрібен мертвий простий спосіб повернутися до попередньої робочої версії для проблем, які не піддаються вашим автоматизованим тестам.

Наприклад, моє Linux ядро ​​певний час було виправлено. Я б виправити і компілювати своє ядро ​​на тому самому комп’ютері, на якому я мав намір використовувати його, що означало, що я можу втратити середовище розробки, якщо створити несправне ядро. Тому я переконався, що завжди зберігати відоме добре ядро ​​в своєму меню GRUB, тому якщо я помилився, я повернувся до хорошого середовища розробки за допомогою простої перезавантаження.

Координувати це з командою досить складно, але я вважаю, що це, головним чином, питання дозволити будь-кому ініціювати відступ та повідомити про причини. У контролі версій один із способів позначити те, що було б як-то, як last_known_goodгалузь, десь між вашим робочим процесом developі masterв ньому. Нічого не підштовхують до тих пір, поки ви успішно не приготували їжу.

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

Якщо вам доведеться дочекатися, коли головна версія матиме такий рівень впевненості, то так і буде.

Git також є таким інструментом, і, очевидно, також займається догфодингом. Але це робить це в різній мірі в різних середовищах. На загальнодоступних серверах працює лише реліз, тоді як розробники зазвичай працюють з будь-яким next(це назва git-проекту для "розвивати") або pu(навіть більше, ніж розвиватися). Будь-який розробник, який заблокований якоюсь проблемою, може повернутися до nextабо masterостаннього випуску кожного разу, коли їх щось заблокує, а основне сховище не вплине, тому проблеми можна усунути, посилаючись на нього.

Модель розгалуження подібна до вищезгаданої з дещо різними назвами. masterце те, з чого зроблені великі релізи, maintце відділення випуску для наступного випуску точки, nextсхоже на розробку з невеликою різницею, що функції можуть бути об'єднані для управління окремо після того, як у наступному вже замість того, щоб цілий наступний був об'єднаний.

Існує додаткова гілка pu. Це створюється шляхом об'єднання всіх функціональних гілок, які розглядаються для інтеграції разом next(гілка щоразу відкидається та відтворюється). IIRC він публікується лише в тому випадку, якщо він проходить тестовий набір. Востаннє я дивився, що Хуніо, обслуговуючий, запускав сценарії, щоб регулярно створювати його вручну, але такі сценарії можна було виконувати безперервною інтеграцією щоночі, і я вважаю, що Герріт навіть створює його автоматично.

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

Виходячи з прийнятої відповіді , я збираюся розширити робочий процес розгалуження, щоб підтримувати гілки, подібні до наступного:

• master: зливається з release-*після закриття
• dogfood: гілки з master; включає виправлення, ідентифіковані під час вигулу собак зливається з тих пір, developколи програмне забезпечення вважається "стабільним" для внутрішнього використання; голову цієї гілки можна при необхідності перемістити назад у часі
• develop: гілки з master; включає в себе постійні зміни, виправлення, злиття dogfoodта feature-*гілки
• feature-*: гілки з develop; включає зміни для певної нової функції
• release-*: гілки, dogfoodколи програмне забезпечення вважається "стабільним" для зовнішнього використання; включає оновлення документації та незначні виправлення помилок до об'єднання зmaster