Чи незвично для невеликої компанії (15 розробників) не використовувати керований контроль джерела / версій? [зачинено]

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

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

Я деякий час намагався наполегливо керувати деяким керованим керуванням джерелами, але, здається, не можу отримати достатню підтримку для цього всередині компанії. Мої основні аргументи:

• Наразі ми вразливі; в будь-який момент хтось може забути зробити одну з багатьох дій з випуску, які ми маємо зробити, що може означати, що цілі версії не зберігаються правильно. Це може зайняти години або навіть дні, щоб скласти версію разом, якщо це необхідно
• Ми розробляємо нові функції разом із виправленнями помилок, і часто доводиться затримувати випуск одного чи іншого, оскільки певна робота ще не завершена. Ми також повинні змусити клієнтів приймати версії, які містять нові функції, навіть якщо вони просто хочуть виправити помилку, тому що є лише одна версія, над якою ми працюємо.
• У нас виникають проблеми з Visual Studio, оскільки декілька розробників одночасно використовують одні і ті ж проекти (не одні й ті самі файли, але це все ще викликає проблеми)
• Є лише 15 розробників, але всі ми робимо речі по-різному; чи не було б краще мати стандартний підхід для всієї компанії, якого ми всі повинні дотримуватися?

Мої запитання:

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

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

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

Спасибі заздалегідь

1. Це може бути не нормально , але, як каже Треб , це, мабуть, не так незвично

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

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

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

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

3. В інших відповідях є достатньо причин для контролю джерел. Моя порада полягає в тому, щоб вибрати основні 2 або 3, які могли б дійсно змінити вашу компанію, відполірувати їх та представити їх на зустрічі якомога більше ваших колег. Спробуйте спровокувати дискусію: навіть якщо ви не одразу переконаєте їх, ви отримаєте уявлення про те, якими можуть бути точки стику.

(Ви читали / чули про функцію зміни ?)

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

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

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

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

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

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

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

Дивіться це питання на SO для гарного обговорення. У прийнятій відповіді сказано:
"Немає вагомих причин не використовувати контроль версій. Не одну".

Чи є ще причини для контролю джерел, які я можу додати до свого арсеналу?

Консенсус між усіма розробниками та керівниками проектів, яких я зустрічав, і, звичайно, тут, з Програмістами та ТА, полягає в тому, що контроль над джерелами є обов'язковим. Це прийнята найкраща практика . Якщо хтось вирішить його ігнорувати, йому потрібно мати дуже сильні та переконливі аргументи, чому це правильне рішення для нього (тобто трохи більше, ніж «нам це ніколи не було потрібно, так навіщо нам це потрібно в майбутньому»). Аргументи, які ви наводили до цього часу, зосереджені на конкретних питаннях, можливо, вам слід спробувати ширший підхід за принципом «всі так роблять, то чому б нам не так?

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

Просто знайдіть інструмент, який вам допоможе. Розмір скрізь не має значення. Якість має значення скрізь.

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

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

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

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

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

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

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

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

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

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

• Уникає ворожих захоплень. Хто б хотів придбати спорядження для розробки програмного забезпечення, яке керується таким чином?

Чи є ще причини для контролю джерел, які я можу додати до свого арсеналу?

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

• Економить місце на диску. Більшість систем управління версіями зберігають лише дельти між файлами. Наразі ви зберігаєте цілу копію кожної версії кожного файлу. (Резервне копіювання всіх цих копій повинно зайняти багато часу та місця!)

• Кілька розробників можуть працювати над одним файлом одночасно та погоджувати відмінності без зайвих проблем. Об’єднання змін, звичайно, можливо без VCS, але майже неможливо відстежити, хто змінив, що, коли і чому в такому випадку.

• Надає розробникам свободу спробувати нові ідеї, знаючи, що вони можуть відновити будь-яку версію в будь-який час.

• Кращий процес полегшує працевлаштування та утримання талановитих розробників.

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

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

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

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

Чи є ще причини для контролю джерел, які я можу додати до свого арсеналу?

Так, причин дуже багато.

1. Розгалуження дає можливість розвивати нові функціональні можливості, не втручаючись в інші розробки.
2. Кожен комітет дає вам інформацію про те, що саме було змінено, хто це змінив, і коли це було внесено.
3. Ви можете легко робити виправлення помилок і розгортати їх для клієнтів, а також залишати незакінчені нові функції.
4. Ви можете підтримувати різні версії, якщо клієнти бояться перейти на нову версію.
5. Ви можете легко працювати з одним і тим же проектом (навіть з тими ж вихідними файлами!)
6. Ви можете легко відновити помилку, зберігаючи зміни після цієї помилки.

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

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

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

Моя компанія використовує GIT для контролю версій. Компанія - один розробник, один генеральний директор, один охоронець, одна прибиральниця та одна ресепціоністка. Усі вони - я. Контроль версій джерела ОБОВ'ЯЗКОВО щоразу.

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

Існує причина, що це №1 у тесті Joel: http://www.joelonsoftware.com/articles/fog0000000043.html

Крім того, це робить №2 та №3 у списку можливим.

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

Кожен наслідував цей приклад, і не задовго ми застосували CI ( CruiseControl ) та здійснили революцію в процесі складання та випуску, щоб включити автоматизацію та перевірку якості.

WTF ?! Це може бути найсмішнішим питанням, що я коли-небудь бачив. Вам потрібно знайти нову роботу. 15 розробників ?! Ви думаєте, що це невелика команда? Це божевільно. Менеджера слід негайно припинити. Чесно кажучи, у мене будуть кошмари, прочитавши це питання. Скажіть, будь ласка, товар, який ви продаєте, щоб ми всі знали, що не купувати його! Я не знаю, що страшніше, це питання чи відповіді, які говорять, що це не є незвичайним!

Я не уявляю, як 15 розробників можуть працювати без контролю над джерелами. Однак із:

(...) використовує мережеву частку для розміщення свого вихідного коду (...)

Я припускаю, що ви створили власний керування версіями бідолахи, як VSS (також на основі спільної папки). Це ризиковано і не ефективно.

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

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

Я колись працював у компанії з двома розробниками (мені + довгошерстим адміністратором), ще в 1998 році. Вже тоді ми використовували svn. Це просто так зручно.

Кілька разів у своїй кар’єрі я втрачав дні роботи, тому що робив щось на кшталт mv замість cp, а потім rm -rf. Змусив мене плакати і блукати по вулицях міста у відчаї.

Я працював у 5 компаніях протягом своїх 13 років перебування в СЕ, був на деяких конференціях і ніколи не стикався з компанією, яка не використовувала контроль версій.

Однак моя улюблена компанія з дизайну інтер’єрів, 20 співробітників, використовують білу дошку для управління проектами + співпраця. Вони неправильно знають, але, схоже, не знаходять часу на оновлення. Хоч якось це працює. Не питайте мене, як.

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

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

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

Гаразд, флешбеки мені дістаються. Підписання. Удачі.

1. Отримайте секундомір,
   • Порахуйте час, який ви витратили в електронній таблиці лише на синхронізацію версій
   • Порахуйте час, який ви витратили на ремонт зламаних версій
   • підрахуйте кількість людей, які кричать у передпокої " я редагую main.c !, просто для того, щоб переконатися, що більше нікого зараз немає!" .
   • підрахуйте кількість скарг, які ви отримуєте від клієнтів, оскільки їх помилка містила інші зміни
   • порахуйте затримку випуску через те, що ви не змогли синхронізувати версії
2. Зробіть Powerpoint з цими даними, порівняйте з тим, як працюватимуть vcs.
3. Шоу-менеджмент

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

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

Подумайте і про зберігання за межами сайтів. Повень чи пожежа насправді не так вже й незвично. Що було б, якби в будівлі сталася пожежа через години. Скільки місяців роботи було б втрачено. Для цього було б корисно кероване сховище коду, наприклад github. Навіть використання простого SVN-сервера для розміщеної послуги було б кроком в цій області.

LordScree, я перебуваю в майже однаковому становищі, як і ви, моя найближча команда - близько 15 розробників. Я з недовірою (майже жах), що управління джерелами не використовується. Моя початкова відповідь на "ми повинні використовувати управління джерелом" була "у нас немає часу на реалізацію". Для мене, як і носіння нижньої білизни, контроль джерел не є обов'язковим. Через декілька місяців я теж маю згоду на впровадження TFS, обраного органом, оскільки це МС та постачається з 90-денним випробуванням. Підсумок, дуже важко переконати організацію в необхідності контролю над джерелами, коли вони без неї перебираються. Я кажу розробникам, що в будь-який час ви виявляєте, що ви створюєте резервну копію файлів, особливо з датою в резервному копії імені файлу чи каталогу, є прикладом того, коли ви хочете щось поставити в керування джерелом. Я не ' у вас немає будь-яких блискучих відповідей, але я вважаю, що це рідкість. Я веду той самий бій і буду інформувати вас про прогрес. І, сподіваюся, буде прогрес ще, я, можливо, шукаю в іншому місці, тому що я не можу працювати в хаосі!

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

Найпростіший спосіб переконати управління? Менш ризик для загального продукту, і це збільшить продуктивність розробників у довгостроковій перспективі. І те й інше вірно, і обидва звертаються до менеджерів.

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

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

Просто скажіть їм, як здорово знайти те, що було додаток 1 січня цього року

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

Нічого, ця помилка 154256 була виправлена ​​в цій комісії.

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

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

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

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

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

Існує багато причин використовувати систему версій. По крайней мере, перестань рухати речі. Робота з патчами. Системи версій можуть робити саме те, що ви говорите.

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

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

На своїй першій серйозній роботі в 1990 році я був єдиним розробником, який працював у моєму відділі і не знав використовувати управління джерелами.

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

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

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

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

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

Таким чином, розгалуження / злиття та рівномірний код обміну вважаються непотрібними. Крім того, ці компанії, мабуть, є ISO9000, тому процес, як не дивно, є, мабуть, документованим.

У будь-якому випадку я / інші розробники тільки почали користуватися SCM особисто.

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

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

Найбільші причини, про які я чув, що я не використовую викопні або інші VCS:

1. Багато хто з "програмістів" є дітьми сценарію, і не розуміють, як ним користуватися
2. Ті, хто міг навчитися, вважають, що користуватися неприємністю
3. Ці люди - стара охорона, зручна з мережевими папками, тому всі повинні бути
4. Ніхто не встигає його правильно налаштувати або навчитися ним користуватися
5. Хоча функції можуть бути чудовими, жодна з них не потрібна

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

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

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

Тепер, коли інструменти DVCS, такі як Git та Mercurial, доступні та неймовірно прості в налаштуванні та використанні, насправді немає жодного приводу навіть команді з 1 (!) Не використовувати керування джерелами. Йдеться не про розмір команди, а про те, щоб коментувати історію змін та можливість підтримувати робочі процеси, такі як виправлення виробничих проблем під час роботи над новим випуском та відстеження стану вихідного коду для різних версій.

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

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

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

Наприклад, ми працювали над соціальною мережею класу ab, написаною на PHP, і клієнт хотів, щоб функціонал міг підписатися на профіль користувача. В основному функціональність була загорнута в такий чек, якщо (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {тоді виконати код}

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

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

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

Інформацію ви можете знайти тут: http://www.internetcontact.be/scm/?page_id=358

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