Непарний цикл випуску компанії: перейти до управління розподіленими джерелами?

Вибачте за цей довгий пост, але я думаю, що воно того варте.

Я тільки почав з невеликого магазину .NET, який працює зовсім інакше в інших місцях, де я працював. На відміну від будь-яких моїх попередніх позицій, програмне забезпечення, написане тут, орієнтоване на декількох клієнтів, і не кожен клієнт отримує останню версію програмного забезпечення одночасно. Таким чином, немає "поточної виробничої версії". Коли клієнт отримує оновлення, він також отримує всі функції, додані до програмного забезпечення з моменту останнього оновлення, що може бути давно. Програмне забезпечення можна налаштувати і включати та вимикати функції: так звані "функції перемикання". Цикли випуску тут дуже тісні, адже вони не в розкладі: коли функція завершена, програмне забезпечення розгортається до відповідного клієнта.

Команда лише минулого року перейшла з Visual Source Safe на Team Foundation Server. Проблема полягає в тому, що вони все ще використовують TFS так, ніби це VSS та застосовують замовлення Checkout на одній гілці коду. Щоразу, коли виправлення помилок виводиться на поле (навіть для одного клієнта), вони просто будують все, що є у TFS, перевіряйте помилку та виправляйте її до клієнта! (Я сам походжу з програмного забезпечення аптеки та медичних пристроїв, це неймовірно!). У результаті виходить, що напівфабрикатний код розробника вводиться у виробництво, навіть не пройшовши тестування. Помилки завжди ковзають у версії версій, але часто клієнт, який щойно отримав збірку, не побачить цих помилок, якщо він не використовує функцію, в якій є помилка. Директор знає, що це проблема, оскільки компанія починає рости все раптово, коли на борту приходять декілька великих клієнтів та більш дрібні клієнти.

Мене попросили переглянути варіанти керування джерелами, щоб уникнути розгортання баггі чи незакінченого коду, але не принести в жертву дещо асинхронний характер випусків команд. Я використовував VSS, TFS, SVN та Bazaar у своїй кар’єрі, але TFS - це те, де більшість мого досвіду було.

Раніше більшість команд, з якими я працював, використовують два-три розгалужувальні рішення Dev-Test-Prod, де протягом місяця розробники працюють безпосередньо в Dev, а потім зміни об’єднуються в Test, потім Prod, або просуваються "коли це зроблено", а не на фіксований цикл. Автоматизовані побудови використовувались за допомогою круїз-контролю або збірки команди. У моїй попередній роботі Bazaar використовувався, сидячи на вершині SVN: розробки працювали у власних невеликих філіях функцій, потім підштовхували свої зміни до SVN (який був прив’язаний до TeamCity). Це було приємно тим, що було легко виділити зміни та поділитися ними з гілками інших народів.

З обома цими моделями була центральна розробка і розробка (а іноді і тестова) гілка, через яку проштовхували код (і мітки використовувались для позначення збірок в продукті, з яких були зроблені релізи ... і вони були зроблені у гілки для виправлення помилок до випусків та злиття назад до dev). Однак це не дуже відповідає способу роботи тут: немає наказу, коли будуть випущені різні функції, коли вони завершаться.

З цією вимогою "безперервна інтеграція" підходить, як я бачу, вона руйнується. Щоб вивести нову функцію при постійній інтеграції, її потрібно перенести через dev-test-prod, і це дозволить зафіксувати будь-яку незакінчену роботу в розробника.

Я думаю, що для того, щоб подолати це, нам слід спуститися на дуже розгалужену модель з НІ розгалуженими тестами, але джерело повинно існувати як серія функціональних гілок, які після завершення роботи над розробкою блокуються, перевіряються, фіксуються, фіксуються , випробуваний, а потім звільнений. Інші гілки функцій можуть захоплювати зміни від інших гілок, коли вони потребують / хочуть, тому зрештою всі зміни поглинаються у всіх інших. Це дуже підходить для чистої моделі Bazaar від того, що я відчував на своїй останній роботі.

Настільки ж гнучко, як це звучить, просто дивно не мати де-небудь стовбура розробника чи гілки prod, і я переживаю за те, щоб гілки змушували ніколи не повторно інтегруватися, або невеликі запізнілі зміни, які ніколи не перетягуються на інші гілки, а розробники скаржаться на злиття катастроф ...

Що з цього приводу думають народи?

Друге остаточне запитання: я дещо заплутаний у точному визначенні розподіленого керування джерелами: начебто деякі люди припускають, що мова йде про те, що він не має центрального сховища типу TFS або SVN, деякі кажуть, що про відключення (SVN на 90% відключений) а TFS має ідеально функціональний режим в режимі офлайн), а інші кажуть, що мова йде про функціональне розгалуження та простота злиття між гілками, які не мають стосунків батько-дитина (TFS також має безпідставне злиття!). Можливо, це вже друге питання!

Що визначає DVCS?

У розподіленому ГНКРЕ означає , що кожен клон сховища має всю інформацію , необхідні для здійснення, поновлення, філії, злиття або пошуку будь-якої зміни в цьому сховищі, не торкаючись до сервера . Єдине, що можна робити в режимі офлайн svn- це насправді редагувати файли - вам потрібен доступ до сервера майже для всіх svnкоманд, у тому числі робити щось таке просто, як прив’язання svn log, тому насправді це ближче до 0%, ніж до 90%!

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

Яка модель розгалуження підходить?

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

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

Деякі ресурси, які ви можете розглянути, включають такі речі, як підмодулі git, які дозволять різним випускам клієнтів визначати різні комбінації конфігурації клієнта, модулів додатків та бібліотек. Іншим варіантом було б використання системи управління патчем для застосування черг для виправлення клієнтів / продуктів.

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

Для отримання додаткової інформації про ці параметри див. Мої відповіді на стратегію використання управління версіями в модульній системі , як використовувати сховище Subversion Inside Git? та управління джерелами / версіями для додатків, які використовуються багатьма компаніями .

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

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

По-перше, DVCS - це червона оселедець для ваших проблем - інструмент контролю версій, який використовується, не є коренем проблем, які потрібно вирішити. Можливо, є аспекти рішень DVCS, які "кращі", ніж TFS, але це не те, що потрібно виправити на цьому етапі.

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

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

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

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

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

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

Друге питання простіше і коротше, тому я спробую почати з нього

DVCS - система, де немає жодного "авторитетного" джерела коду (крім "за згодою", коли використовується) та P2P-обмін даними можливий без додаткових рівнів (особисте, неканонічне визначення)

По темі перше питання

Боюся, компанії доведеться реконструювати робочий процес і переосмислити стиль, щоб отримати "якось керований і передбачуваний код". Я не можу сказати про TFS (за винятком особистої думки та почуття, що це слабка система в розділі Control Control / безпідставне злиття є злом /), але для будь-якої VCS у вашій ситуації ("Продукт" встановлений незалежними "Модулями", кожен "Клієнт" отримує різні "Продукти" - чи це припущення правильне?) Я віддаю перевагу розбитковій розробці модулів на окремі гілки, продукт має "Супермодуль" (також галузь?), там кожен модуль прив'язаний до конкретного перегляду модуля- відділення, розробка модуля використовує парадигму відгалуження до завдання (а модуль-гілка складається лише з об'єднань).

Таким чином, ви завжди можете знати, що "Колекція" (тобто набір модулів та відповідні їх редакції) формує кожен "Продукт", мають можливість робити CI (для готових і об'єднаних гілок завдань), Unit-testing та Builds

Основне питання оголошення: я вважаю, що саме ви говорите саме про те, про що йдеться про успішну модель розгалуження git (і допоміжний потік git flow для її підтримки). Майте головну гілку, яка завжди знаходиться у стані розгортання та виконайте всю роботу над функціональними гілками.

Ви також можете скористатися самим процесом git, який походить від того самого основного принципу. У розробці git-core вся робота відбувається на галузевих галузях. Гілки функцій передаються інтегратору, який виконує сценарій для об'єднання всіх для створення гілки з назвою pu(запропоновані оновлення). Різні люди беруть цю галузь і працюють з нею, щоб перевірити її.

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

У git гілка функції, ніж переходить до next, masterабо maintзалежно від того, на який випуск він орієнтований (maint призначений для виправлення поточного випуску, master для поточного випуску в процесі підготовки та наступного для одного після цього), але у вас не буде такої кількості.

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

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

Друге запитання оголошення: Мене вчили, що "розповсюджений", як правило, означає, що ви можете переміщати об'єкти навколо, і вони зберігають свою особу. Саме це і робить контроль розподілених версій: ви клонуєте сховище, і воно містить ті самі коміти та дозволяє робити ті ж самі дії з ними. Легкість розгалуження та відключена операція - це основні функції на рівні користувача, які випливають із принципу переміщення комітетів та спрямованого компонування графіків, що це дозволяє.

На жаль, невідоме рішення помилок у коді :)

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

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

Не надто приємно, але це може спрацювати надзвичайно добре. Ви тримаєте код організованим та добре розділеним. Це також легко зрозуміти для інших розробників - невеликі виправлення безпосередньо на «коді», що-небудь більше, ніж пара рядків, робиться на спеціальній гілці, де вони можуть зайняти стільки, скільки їм захочеться виконати. (вам доведеться розібратися з проблемами злиття та переконати їх у тому, що це нормально, якщо 2 розробники працюють над двома функціями одночасно !!)

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

DVCS:

в основному DVCS - це те, де кожен має власну копію репо-сервера. Він має деякі переваги (особливо в розподілених командах з обмеженою комунікацією), але має і деякі недоліки, тому перевірте їх перед тим, як перейти до DVCS. Якщо ви магазин Windows, то, ймовірно, ви знайдете, що Mercurial є найкращим для вас DVCS.