Субверсія / контроль джерела лише для виробничого коду?

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

Це нормальна практика? Мені здається, ми втрачаємо багато переваг контролю джерел, включаючи:

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

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

Якщо проекти завершуються в їх очікувані строки, чи можна припустити, що клієнти є щасливими клієнтами? :)

Схоже, що компанія починає також брати на себе нові проекти, і переживає певні сильні болі або якісь "перехідні болі". Багато припущень тут відбувається ... Будь ласка, нехай мене!

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

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

Будьте з повагою, і, можливо, вас почують.

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

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

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

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

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

Відкладаючи питання про те, чи правильно Джо чи не так (він, до речі, помиляється), мені здається, що компромісу можна було б досягти, якщо ви використовували розподілену систему управління версіями на зразок Git чи Mercurial .

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

Немає сенсу з тих перелічених вами причин. Це як використання контролю версій без переваг використання контролю версій.

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

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

Я б також запропонував використовувати більш потужний інструмент, ніж SVN. Ви можете побачити хороший вступ про можливості на http://hginit.com/ Джоел Споельський.

Він використовує меркурій, і в наші дні є кілька претендентів. Git вважається дуже потужним, а https://github.com/ має кілька дуже, дуже корисних інструментів та забезпечує безкоштовні стартові акаунти, щоб ви могли спробувати це реально.

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

Ніколи не використовував SVN, тому я не знаю, якими були б процедури для цього. Ми використовуємо ClearCase, і практика тут полягає в тому, щоб кожен розробник мав власну гілку розвитку, потім галузь інтеграції, до якої ми об'єднуємось, коли ми готові розпочати тестування, і одну або кілька гілок випуску для інтегрованого і перевіреного коду .

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

Мені здається, ваша організація має інвестиції в SVN, і це було б обмеженням кар'єри, щоб ви кидали виклик Джо та визнали недійсними інвестиції в долар на SVN-сервері. Налаштуйте репортаж GIT і використовуйте інтерфейс git svn, щоб працювати так, як ви хочете (це все вільне програмне забезпечення, і на його налаштування знадобиться година до дня, все на вашій робочій станції). Соціалізуйте свій робочий процес з Джо - він може зберегти свою систему незабруднених переконань у SVN repo та зберегти свою довіру до дорогого білого слона в кутку (та его).

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

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

Я збираюся відлунювати тут @ Carson63000 і кажу, що я бачив таке ставлення раніше, і це значною мірою спричинене жахливими можливостями розгалуження / об'єднання VCS. Наявність гілки, яка збирає та проходить тести, з тегами для кожного випуску - чудовий підхід, але не слід дотримуватися того, що жоден інший код не вчиняється. DVCS в цілому, і git зокрема, роблять розгалуження простою та звичайною операцією, і це зменшує багато труднощів із цим робочим процесом.

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

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

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