Шаблони для постійної інтеграції та DVCS


12

Зараз ми використовуємо Subversion та TeamCity, ми перейдемо до використання Mercurial (зокрема Kiln, оскільки ми користувачі FogBugz).

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

Завдяки SVN ми надаємо обмежену кількість центральних сховищ - фактично по одному на проект (більш-менш одне рішення Visual Studio), тому його легко запустити збірку та отримати впевненість у тому, що всі файли були зафіксовані та що таких немає бродячі залежності тощо, і т. д. Але якщо ми візьмемо належний просування ртутних даних, ми хочемо мати більше екземплярів сховища - там, де я б очікував, що зміни в цілому перейдуть до остаточного "живого" репо. Проблема, з якою я стикаюся, полягає в тому, що, як мені здається, реальна репо-формація є занадто пізньою, щоб викликати побудову CI OTOH, одна збірка ІС на проект на розробника, ймовірно, є надмірною (і викликає інші проблеми).

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


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


Чому, на вашу думку, занадто пізно запускати побудови з центрального / "живого" репо?
c_maker

Якщо ви там ще не були, я пропоную вам перейти на сайт обміну стеками Kiln ( kiln.stackexchange.com ). У них є досить багато вмісту щодо того, як це налаштувати (ось один: kiln.stackexchange.com/questions/29/… . Особисто ми використовуємо гілку на особливості та вказуємо сервер збирання на нашу "головну" гілку. )
Кріс Філіпс

@Chris - У мене, насправді, не вирішується питання CI ...
Мерф

Відповіді:


2

По-перше, наявність декількох збірок на проект в TeamCity - це справді шлях. Характер платформи робить це дуже просто - кнопка копіювання є там не просто так.

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

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


На мій погляд, Вайетт, натискання має відбуватися, коли у вас є завершена одиниця роботи (ish) - одна з переваг DVCS полягає в тому, що ми можемо ввести місцевий код, який порушено. Мені дуже не подобається поняття робити що-небудь за розкладом, оскільки це кінець дня. Існує окрема проблема "резервного копіювання", яка - для мене - полягає у встановленні правила для просування в бік - на фіксацію - до іншого клону, який існує лише для резервного копіювання.
Мерф

2
Хитрість є, що таке визначення одиниці роботи? Це "ця особливість завершена" чи це "ця цегла успішно покладена". Ми прагнемо до останнього, особливо з тією моделлю розгалуження, де чітко розмежована галузь розвитку. Розбивати речі найкраще, щоб розмістити гілки. Довготривалі з них можуть також отримати збірки CI, якщо це можливо. Особливо, якщо на кухні є кілька кулінарів.
Wyatt Barnett

Я погоджуюся з вашим визначенням "одиниця роботи", тому я трохи бореться зі своєю загальною моделлю (яка вже має декілька складання на проект по різному для розміщення як "CI", так і "розгортання" збірок). Ви маєте рацію, відповідь полягає в тому, щоб викласти багато складових, так що врешті-решт моїм справжнім питанням стане отримання чека підписаним! Модель розгалуження, на яку посилається, виглядає і правильно - теж. Тим НЕ менше , враховуючи загальну картину (і допустити, що отримає уточнено , щоб врахувати специфіку kilnhg)
Murph

2

Ми використовуємо Kiln вже близько року і спробували кілька різних речей. Де ми закінчилися - це використовувати названі гілки (на відміну від клонів гілок) із наступною стратегією розгалуження:

  • трек за замовчуванням "завершено" розробкою
  • функціонують гілки відстежують роботу, яка зараз триває
  • випустити точки гілок, де ми звільнені за замовчуванням

Отже, робота починається зі створення гілки функцій з поточної підказки за замовчуванням . Коли гілка функції виконана *, гілка закривається і об'єднується назад у замовчування .

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

Щодо постійної інтеграції, ми робимо дві речі:

  • Інтеграція "увімкнено", яка відстежує стан за замовчуванням
  • Нові інтеграції для кожної галузі випуску

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

* Наше визначення поняття "зроблено" полягає в тому, що функція оновлена ​​злиттями за замовчуванням і була затверджена в огляді коду.


1

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

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

Шаблон "гілка на завдання" не новий (перегляньте книгу Берчука), але напевно потрібно щось спробувати.

Я детально пояснив це тут , і плюси та мінуси ІП проти "контрольованих" тут .


Я б сказав "краще", а не "добре", оскільки я щасливо, з ентузіазмом та успіхом зробив розгалуження та підтримку функцій та обслуговування та злиття з підривною роботою (-:
Murph
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.