Щось не так у тому, як ми робимо контроль версій?

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

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

Це здається доволі викривленим - чи є кращий спосіб впоратися з таким типом сценарію? Ми використовуємо сервер Team Foundation Server і Visual Studio 2010.

V2.0 повинен був мати те, що ми використовували для виклику "стаціонарна гілка" (ми використовували Perforce, а не TFS), зроблену для цього, як тільки він був випущений. Будь-які виправлення v2 були б зроблені до цієї гілки та потім перенесені назад у гілку розвитку v3, тоді як над функціями v3 також працювали, тобто дефект v2 призведе до дефекту також і v3.

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

Ну є кілька способів вирішення таких питань, як правило, охоплених тегом "розгалуження" , кожен з яких має власний набір переваг та недоліків.

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

код ... зберігатиметься на локальних машинах розробника, поки вони не будуть виконані ...

... спосіб, як вище, мабуть, єдиний, який абсолютно, абсолютно не так!

Що для мене є кордоном кримінального, це те, що для TFS існує чудовий, простий для розуміння, керівництво відділеннями Microsoft Team Foundation Server Branching - величезний і детальний документ із рекомендаціями щодо стратегій розгалуження, ретельно розроблених та пояснених для всіх видів різних проектів ( HTML версія тут ).

1. Ваші розробники мають принципове непорозуміння, як використовувати контроль версій.
2. Не вступайте в дискусію щодо "правильного" програмного забезпечення для контролю версій. Це не проблема.
3. Кожен виправлення коду ускладнює виправлення проблеми.
4. Коли ви вирішите зробити правильно, ви не можете продовжувати зміни коду, коли ви виправляєте речі. Ви ОБОВ'ЯЗКОВО зупините всю розробку і отримаєте код у контролі версій.
5. Диявол повинен відчувати біль досить, щоб принаймні сісти і поговорити про це.
6. Все програмне забезпечення для управління версіями підтримує основні поняття:
   • ВСІЙ код переходить у сховище контролю версій.
   • Усі файли коду мають номери версій. Збільшення цих чисел автоматично, як код буде повторно зареєстровано.
   • TAG позначає всі файли коду конкретної версії (і в а). Таким чином, ми можемо TAG програмного забезпечення версії 1, наприклад.
   • BRANCH - це "відворот" від основного магістралі .
     • Будь-які зміни, внесені до гілки, не впливають на стовбур.
     • Ви можете необов'язково об'єднати зміни гілки назад в основний стовбур в якийсь момент.
     • Таким чином, ми можемо експериментувати, не побоюючись зіпсувати "хороші речі".
7. Ви повинні отримати контроль над версією "стрибок віри", як я це називаю. ДОВІРУЙТЕ, що дотримання основних правил дозволить все зрозуміти. Досвід змушує нас думати інакше, довіртесь.
8. Ось гідний підручник. Це досить загально і повно, що вам не потрібно шукати багато інших джерел
   • Контроль версій, краще пояснено

редагувати

• Покладіть контроль версій на робочий комп'ютер.
  • Ви можете це зробити прямо зараз без координації команди
  • Навіть при командному контролі версій я дуже рекомендую це
  • Якщо ваша команда використовує Git або Mercurial, ви використовуєте незалежне місцеве сховище. Ось так працює розподілений контроль версій.
  • Ви можете використовувати різні програми програмного забезпечення для своєї команди. Наша команда використовує Subversion, я використовую Mercurial локально. Метафайли програмного забезпечення VC (".svn", ".mg", приховані папки) не конфліктують.

Ви не виступаєте як сховище де-факто команди. Це для управління власною роботою, рефакторинг зусиль тощо та CYAing себе, коли команда продовжує формувати базу кодів.

завершити редагування

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

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

Швидкий відповідь: Команда розробників повинна мати окрему галузь виробництва, щоб тримати розгорнуту кодову базу V2.0 окремо від основної магістралі.

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

У вашому проекті також повинно бути кілька середовищ, for health developmentтаких як Prod, Staging, QA та Dev (іноді UAT). Ці середовища слід створити перед переходом до випуску Production.

Загалом, бути готовим до помилок та модифікацій - це спосіб підтримати випущений додаток.

Оскільки TFS був згаданий як контроль версій, я також склав список статей, які будуть корисні для встановлення умов для розвитку здоров'я:

• Впровадження Team Foundation Server із невеликою командою розвитку
• Ласкаво просимо до інтеграційної платформи TFS!
• Розробка команди за допомогою керівництва з TFS
• Налаштування середовища розвитку

Ні, оскільки, використовуючи VCS, ви не здійснюєте контроль версій.

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

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

Я розробник, і нам надають різний код філії та db для виправлень поточної версії та різних для вдосконалень та для наступної наступної версії.

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

Більше того, ми дотримуємось такої практики, як якщо у мене є 10 виправлень для моєї поточної версії

Я пишу як

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

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

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+Fкоманда та тип //Start Iteration 2, Fix No-1, Branch No-"ABC" для пошуку у всьому рішенні дуже допомагають з’ясувати точні місця, файли, де змінюється код, і приймати свіжий код, лише для того, щоб використовувати цю частину.